1025095 - OpenTrust: add new root CA certificates

Status: RESOLVED FIXED

(CA Program :: CA Certificate Root Program, task)

Description

[Remi Pifaut]

Attachment: Mozilla file to add CAs.zip

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release)
Build ID: 20140605174243

Steps to reproduce:

Sir, Madam,
I write this note to inform you that we have new root CA certificates to include within your browser and/or OS.

All elements below are provided for CA inclusion within Mozilla/Firefox and are based on information available about Mozilla CA certificate inclusion policy (version 2.2) on https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/.

In addition, you will find:
-	Our certificate policy to the following url: https://www.opentrust.com/images/stories/DMS_RCA_Program_OpenTrust_CP_v_1_0-s.pdf
-	Our existing audit covering our current CA used for EV certificate issuance (https://www.opentrust.com/ca-certificate-program-opentrust/Ind_Aud_rep_LSTI_S.pdf). This audit will include new CAs in its next version to be done by January 2015.

I also attach:
-	The audit report related to our key ceremony when new CAs were created
-	The root CA certificates themselves
 
To give you more information about us and this CA inclusion request:
-	Our company is known as Keynectis, with a new branding OpenTrust
-	We also own Certplus brand for which the “Certplus Class 2 CA” is already included within your software environment. As this CA is going to expire mid-2019, we have prepared new root CA certificates to renew/replace it.
-	We prepared five different CA certificates for the next 24 years based upon different characteristics:
o	Two brandings: existing one “Certplus” and the new one “OpenTrust”
o	Different technologies about keys and algorithms: RSA/ECC, SHA 256 / 512 / ECC
-	We are currently in an inclusion request phase of these root CA certificates with other major browsers and OS editors.

2.1	Name
OpenTrust
Address: 11-13 rue René Jacques  / 92131 Issy Les Moulineaux Cedex / France

2.2	Website URL
www.opentrust.com

2.3	Organizational type
Private corporation.

2.4	Primary market / customer base
Any type of customer (public or private corporations, associations,…).
Focus is mainly in EMEA even if certificates can be used worldwide. This may be different in the future depending on sales representatives that can be geographically based in other regions.

2.5	Impact to Mozilla Users
◦ Why does the CA need to have their root certificate directly included in Mozilla’s products, rather than being signed by another CA’s root certificate that is already included in NSS?
We “renew” our already registered CA (Certplus Class 2 expiring in 2019) with newer CAs.

◦ Does this CA have root certificates included in any other major browsers? If yes, which? If no, why not? 
We are in the process of registering our CAs by other major browsers as it is the case for our existing CA.

◦ Describe the types of Mozilla users who are likely to encounter your root certificate as relying parties while web browsing (HTTPS servers doing SSL), sending/receiving email to their own MTA (SMTPS, IMAPS servers doing SSL), sending/receiving S/MIME email (S/MIME email certs), etc.
Signature and authentication for users (S/MIME, signature of documents, SSL authentication…), SSL certificates for servers, VPN certificate, OCSP certificate, timestamping certificate, code signing cert… See § 1.4.1.4 of the CP.

2.6	CA Primary Point of Contact (POC)
POCs are the following:
Erwann Abalea – [e-mail] - [phone]
Remi Pifaut – [e-mail] - [phone]
RC program – [e-mail] (CA Email Alias)
CA phone number:
-	Switchboard : [phone]
-	Customers service: [phone]
Title / Department: ask for the customers service.


2.7	Technical information about each root certificate
2.7.1	OpenTrust Root CA G1
Certificate Name: "OpenTrust Root CA G1"
Certificate Issuer Field: C=FR, O=OpenTrust, CN=OpenTrust Root CA G1
Certificate Summary: this root certificate will replace the already included "Certplus Class 2", with our new company name, and different crypto parameters (SHA256, RSA4096); certificates to be produced are TLS, Email, Code Signing.
Root Certificate URL: 
https://www.opentrust.com/images/stories/OpenTrust-G1-G2-G3.zip
SHA1 fingerprint: 7991e834f7e2eedd08950152e9552d14e958d57e
Valid from (YYYY-MM-DD): 2014-05-26
Valid to (YYYY-MM-DD): 2038-01-15
Certificate Version (should be 3): 3
Certificate Signature Algorithm: sha256WithRSAEncryption
Signing key parameters: RSA 4096 bits
Test website URL: https://opentrustrootcag1-test.opentrust.com/
Certificate Revocation Lists (CRLs): 
http://get-crl.certificat.com/public/opentrustrootcag1.crl
OCSP: http://get-ocsp.certificat.com/opentrustrootcag1
Requested Trust Bits: Websites, Email, Code Signing
SSL Validation Type: DV, OV, EV (EV OID: 1.3.6.1.4.1.22234.2.5.2.3.1)

2.7.2	OpenTrust Root CA G2
Certificate Name: "OpenTrust Root CA G2"
Certificate Issuer Field: C=FR, O=OpenTrust, CN=OpenTrust Root CA G2
Certificate Summary: this root certificate will replace the already included "Certplus Class 2", with our new company name, and different crypto parameters (SHA512, RSA4096); certificates to be produced are TLS, Email, Code Signing.
Root Certificate URL: 
https://www.opentrust.com/images/stories/OpenTrust-G1-G2-G3.zip
SHA1 fingerprint: 795f8860c5ab7c3d92e6cbf48de145cd11ef600b
Valid from (YYYY-MM-DD): 2014-05-26
Valid to (YYYY-MM-DD): 2038-01-15
Certificate Version (should be 3): 3
Certificate Signature Algorithm: sha512WithRSAEncryption
Signing key parameters: RSA 4096 bits
Test website URL: https://opentrustrootcag2-test.opentrust.com/
Certificate Revocation Lists (CRLs): 
http://get-crl.certificat.com/public/opentrustrootcag2.crl
OCSP: http://get-ocsp.certificat.com/opentrustrootcag2
Requested Trust Bits: Websites, Email, Code Signing
SSL Validation Type: DV, OV, EV (EV OID: 1.3.6.1.4.1.22234.2.5.2.3.1)

2.7.3	OpenTrust Root CA G3
Certificate Name: "OpenTrust Root CA G3"
Certificate Issuer Field: C=FR, O=OpenTrust, CN=OpenTrust Root CA G3
Certificate Summary: this root certificate will replace the already included "Certplus Class 2", with our new company name, and different crypto parameters (SHA384, ECC); certificates to be produced are TLS, Email, Code Signing.
Root Certificate URL: 
https://www.opentrust.com/images/stories/OpenTrust-G1-G2-G3.zip
SHA1 fingerprint: 6e2664f356bf3455bfd1933f7c01ded813da8aa6
Valid from (YYYY-MM-DD): 2014-05-26
Valid to (YYYY-MM-DD): 2038-01-15
Certificate Version (should be 3): 3
Certificate Signature Algorithm: ecdsa-with-SHA384
Signing key parameters: ECC, NIST P-384
Test website URL: https://opentrustrootcag3-test.opentrust.com/
Certificate Revocation Lists (CRLs): 
http://get-crl.certificat.com/public/opentrustrootcag3.crl
OCSP: http://get-ocsp.certificat.com/opentrustrootcag3
Requested Trust Bits: Websites, Email, Code Signing
SSL Validation Type: DV, OV, EV (EV OID: 1.3.6.1.4.1.22234.2.5.2.3.1)

2.7.4	Certplus Root CA G1
Certificate Name: "Certplus Root CA G1"
Certificate Issuer Field: C=FR, O=Certplus, CN=Certplus Root CA G1
Certificate Summary: this root certificate will replace the already included "Certplus Class 2", with our old brand name, and different crypto parameters (SHA512, RSA4096); certificates to be produced are TLS, Email, Code Signing.
Root Certificate URL: 
https://www.opentrust.com/images/stories/Certplus-G1-G2.zip
SHA1 fingerprint: 22fdd0b7fda24e0dac492ca0aca67b6a1fe3f766
Valid from (YYYY-MM-DD): 2014-05-26
Valid to (YYYY-MM-DD): 2038-01-15
Certificate Version (should be 3): 3
Certificate Signature Algorithm: sha512WithRSAEncryption
Signing key parameters: RSA 4096 bits
Test website URL: https://certplusrootcag1-test.opentrust.com/
Certificate Revocation Lists (CRLs): 
http://get-crl.certificat.com/public/certplusrootcag1.crl
OCSP: http://get-ocsp.certificat.com/certplusrootcag1
Requested Trust Bits: Websites, Email, Code Signing
SSL Validation Type: DV, OV, EV (EV OID: 1.3.6.1.4.1.22234.2.5.2.3.1)

2.7.5	Certplus Root CA G2
Certificate Name: "Certplus Root CA G2"
Certificate Issuer Field: C=FR, O=Certplus, CN=Certplus Root CA G2
Certificate Summary: this root certificate will replace the already included "Certplus Class 2", with our old brand name, and different crypto parameters (SHA384, ECC); certificates to be produced are TLS, Email, Code Signing.
Root Certificate URL: 
https://www.opentrust.com/images/stories/Certplus-G1-G2.zip
SHA1 fingerprint: 4f658e1fe906d82802e9544741c954255d69cc1a
Valid from (YYYY-MM-DD): 2014-05-26
Valid to (YYYY-MM-DD): 2038-01-15
Certificate Version (should be 3): 3
Certificate Signature Algorithm: ecdsa-with-SHA384
Signing key parameters: ECC, NIST P-384
Test website URL: https://certplusrootcag2-test.opentrust.com/
Certificate Revocation Lists (CRLs): 
http://get-crl.certificat.com/public/certplusrootcag2.crl
OCSP: http://get-ocsp.certificat.com/certplusrootcag2
Requested Trust Bits: Websites, Email, Code Signing
SSL Validation Type: DV, OV, EV (EV OID: 1.3.6.1.4.1.22234.2.5.2.3.1)

2.8	CA Hierarchy information for each root certificate
1. CA Hierarchy
For each root CA, there have been one or two CAs created during key ceremony dated 26th of May 2014:
•	One existing EV SSL CA that has been cross certified with this new root CA (for EV SSL issuance). This CA is the one used to issue EV SSL certificates under the Certplus Class 2 already included within major browsers and OS
•	For some of the root CAs, one CA dedicated to Adobe AATL program (for Adobe compliant PDF signing certificates)

OpenTrust Root CA G1 issued:
•	EV CA: KEYNECTIS Extended Validation CA
•	AATL CA: OpenTrust CA for AATL G1

OpenTrust Root CA G2 issued:
•	EV CA: KEYNECTIS Extended Validation CA
•	AATL CA: OpenTrust CA for AATL G2

OpenTrust Root CA G3 issued:
•	EV CA: KEYNECTIS Extended Validation CA
•	AATL CA: OpenTrust CA for AATL G3

Certplus Root CA G1 issued:
•	EV CA: KEYNECTIS Extended Validation CA

Certplus Root CA G2 issued:
•	EV CA: KEYNECTIS Extended Validation CA


2. Sub CAs Operated by 3rd Parties
N/A.

3. Cross-Signing
One existing EV SSL CA that has been cross certified with this new root CA (for EV SSL issuance). This CA is the one used to issue EV SSL certificates under the Certplus Class 2 already included within major browsers and OS.

4. Technical Constraints or Audits of Third-Party Issuers
N/A.

2.9	Verification Policies and Practices
2.9.1	Documentation: CP, CPS, and Relying Party Agreements
CP can be found on the following url:
http://www.opentrust.com/images/stories/DMS_RCA_Program_OpenTrust_CP_v_1_0-s.pdf

The section number(s) where the "Commitment to Comply" with the CA/Browser Forum Baseline Requirements may be found, as per BR #8.3 are the following within the CP:
•	1.3.1
•	1.3.4
•	1.3.9.1
•	1.3.9.2
•	1.4.1.2
•	1.4.1.3
•	3.2.6
•	4.1.2.3
•	4.1.2.3
•	4.2.2.2
•	5.1.1
•	6.1.1.1
•	6.1.1.3
•	8.1
•	8.2
•	9.6.1
•	9.10.2
•	9.12.1

2.9.2	Audits
As these root certificates are renewed CAs to replace existing one, these root CAs will be included in the next audit that should be done by January 2015.

2.9.3	SSL Verification Procedures
 ◦ If you are requesting to enable the Websites (SSL/TLS) trust bit...

◾ Confirm that you have automatic blocks in place for high-profile domain names (including those targeted in the DigiNotar and Comodo attacks in 2011).
◾ Specify the procedure for additional verification of a certificate request that is blocked. 
As described in RCA CP section; 1.4, 4.1.2.3 and 8.1, CA signed under ICA or RCA SHALL be compliant [ETSI 102 042 DVCP] and all “CA:Information checklist” as described in [Mozilla, https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ and https://wiki.mozilla.org/CA:Information_checklist]. PMA has a established an audit program as described in section 8.1 in order to chek the compliance of CA against [ETSI 102 042 DVCP] and all “CA:Information checklist” as described in [Mozilla]. These CA will be checked by PMA as compliant in its CP and CPS and practice for the requirements mentioned above.

◾ If OV verification is performed, then provide URLs and section/page number information pointing directly to the sections of the CP/CPS documents that describe the procedures for verifying the identity, existence, and authority of the organization to request the certificate.
◾ There should be a description of the types of resources that are used to confirm the authenticity of the information provided by the certificate subscriber, what data is retrieved from public resources, and how that data is used for verification of the entity referenced in the certificate. 
As described in RCA CP section; 1.4, 4.1.2.3 and 8.1, CA signed under ICA or RCA SHALL be compliant [ETSI 102 042 OVCP] and all “CA:Information checklist” as described in [Mozilla, https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ and https://wiki.mozilla.org/CA:Information_checklist]. PMA has a established an audit program as described in section 8.1 in order to chek the compliance of CA against [ETSI 102 042 OVCP] and all “CA:Information checklist” as described in [Mozilla]. These CA will be checked by PMA as compliant in its CP and CPS and practice for the requirements mentioned above.

◾ If EV verification is performed, then provide URLs and section/page number information pointing directly to the sections of the CP/CPS documents that pertain to EV and describe the procedures for verifying the ownership/control of the domain name, and the verification of identity, existence, and authority of the organization to request the EV certificate.
◾ The EV verification documentation must meet the requirements of the CA/Browser Forum's EV Guidelines, and must also provide information specific to the CA's operations. 
As described in RCA CP section; 1.4, 4.1.2.3 and 8.1, CA signed under ICA or RCA SHALL be compliant [ETSI 102 042 EVCP] and all “CA:Information checklist” as described in [Mozilla, https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ and https://wiki.mozilla.org/CA:Information_checklist]. PMA has a established an audit program as described in section 8.1 in order to chek the compliance of CA against [ETSI 102 042 EVCP] and all “CA:Information checklist” as described in [Mozilla]. These CA will be checked by PMA as compliant in its CP and CPS and practice for the requirements mentioned above.

2.9.4	Email Address Verification Procedures
 ◦ If you are requesting to enable the Email (S/MIME) trust bit...
As described in RCA CP section; 1.4, 4.1.2.3 and 8.1, CA signed under ICA or RCA SHALL be compliant [ETSI 102 042] or [101 456] and all “CA:Information checklist” as described in [Mozilla, https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ and https://wiki.mozilla.org/CA:Information_checklist]. PMA has a established an audit program as described in section 8.1 in order to chek the compliance of CA against [ETSI 102 042] or [ETSI 101 456] and all “CA:Information checklist” as described in [Mozilla]. These CA will be checked by PMA as compliant in its CP and CPS and practice for the requirements mentioned above.


2.9.5	Code Signing Subscriber Verification Procedures
 ◦If you are requesting to enable the Code Signing trust bit...
◾ URLs and section/page number information pointing directly to the sections of the CP/CPS documents that describe the procedures for verifying the certificate subscriber's identity and authority, and the organization's identity and existence.
◾  Recommended Practices for Verifying Identity of Code Signing Certificate Subscriber 
As described in RCA CP section; 1.4, 4.1.2.3 and 8.1, CA signed under ICA or RCA SHALL be compliant [ETSI 102 042] or [101 456] and all “CA:Information checklist” as described in [Mozilla, https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ and https://wiki.mozilla.org/CA:Information_checklist]. PMA has a established an audit program as described in section 8.1 in order to chek the compliance of CA against [ETSI 102 042] or [ETSI 101 456] and all “CA:Information checklist” as described in [Mozilla]. These CA will be checked by PMA as compliant in its CP and CPS and practice for the requirements mentioned above.

2.9.6	Multi-factor Authentication
RCA is totally off-line and used in a dedicated physical room (key ceremony room as dedscribed in section 5.1 of RCA CP).

As described in RCA CP section; 1.4, 6.5, 6.7 and 8.1, CA signed under ICA or RCA SHALL be compliant [ETSI 102 042] or [101 456] and all “CA:Information checklist” as described in [Mozilla, https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ and https://wiki.mozilla.org/CA:Information_checklist]. PMA has a established an audit program as described in section 8.1 in order to chek the compliance of CA against [ETSI 102 042] or [ETSI 101 456] and all “CA:Information checklist” as described in [Mozilla]. These CA will be checked by PMA as compliant in its CP and CPS and practice for the requirements mentioned above.


2.9.7	Network Security
RCA is totally off-line and used in a dedicated physical room (key ceremony room as dedscribed in section 5.1 of RCA CP).

As described in RCA CP section; 1.4, 6.5, 6.7 and 8.1, CA signed under ICA or RCA SHALL be compliant [ETSI 102 042] or [101 456] and all “CA:Information checklist” as described in [Mozilla, https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ and https://wiki.mozilla.org/CA:Information_checklist]. PMA has a established an audit program as described in section 8.1 in order to chek the compliance of CA against [ETSI 102 042] or [ETSI 101 456] and all “CA:Information checklist” as described in [Mozilla]. These CA will be checked by PMA as compliant in its CP and CPS and practice for the requirements mentioned above.

If you need any additional information or if there is a specific process to follow, just contact us and we will come back to you.
 
Looking forward to reading from you soon,

Best regards.
Remi Pifaut

Comment 1

[Kathleen Wilson]

I am accepting this bug, and will work on it as soon as possible, but I have a large backlog.
https://wiki.mozilla.org/CA:Schedule#Requests_in_the_Information_Gathering_and_Verification_Phase

I will update this bug when I begin the Information Verification phase.
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification

Comment 2

[Kathleen Wilson]

Attachment: Certplus_Root_CA-G1.crt

Comment 3

[Kathleen Wilson]

Attachment: Certplus_Root_CA-G2.crt

Comment 4

[Kathleen Wilson]

Attachment: OpenTrust_Root_CA-G1.crt

Comment 5

[Kathleen Wilson]

Attachment: OpenTrust_Root_CA-G2.crt

Comment 6

[Kathleen Wilson]

Attachment: OpenTrust_Root_CA-G3.crt

Comment 7

[Kathleen Wilson]

Attachment: Aud_KC_RCA_S.pdf

Comment 8

[Kathleen Wilson]

Attachment: Initial CA Information Document

The attached document summarizes the information that has been verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness, and provide the necessary information in this bug.

Comment 9

[Remi Pifaut]

(In reply to Kathleen Wilson from comment #8)
Katherine,
Here are answers to some of your questions. For other questions, we will keep you updated when we have more information for you.
BR
Remi.
*****

Technical information about each root certificate – OpenTrust Brand
“Non-­‐sequential serial numbers and entropy in cert”
Answer: all certiticate serial numbers for Subscriber issued by CA shall have a random number on 16 bytes longs.

SSL Verification Procedures:
First of all, our context has to be explained and understood. You are right they are so many ways to meet requirement and OpenTrust can’t imagine in advance what our future customer will do to deliver SSL/TLS certificate with a CA signed by RCA OpenTrust. But we can’t know in advance which rules that our future customer will have to respect. It means, that we can’t describe in advance all acceptable methods used to register and generate a DV SSL certificate. But each time a new customer will want to be signed by one of our RCA, we will first audit its procedures against ETSI and CAB Forum requirements for SSL certificate issuance. So it means, that all CA signed by our RCA will have to be compliant with rules defined by CAB Forum and ETSI. But we don’t know in advance by which means or procedures. But we know our own procedure to deliver SSL certificate.
These explanations shall not be contained in the CP provided to Mozilla because it is CP for RCA, ICA and CA key pair and certificate life cycle only. These explanations are contained in CP defined to manage Subscriber key pair and certificate life cycle. 
Therefore as an example, please find below a very short synthesis on our main requirements for our procedures used to manage final SSL certificates.
For DV certificate:
We use only information found in a WHOIS database to contact and authenticate the Applicant’s ownership or control of all requested Domain Name(s). We can also use email address like; [e-mail], [e-mail], [e-mail] , [e-mail] or [e-mail].
We control the existence and content of domain name using WHOIS database.
In addition to that, the Applicant shall transmit a legible copy of a valid government issued national identity document or photo ID (driver’s licence, national ID or equivalent) to the RA.
Applicant shall sign a certificate request using its email with a challenge (OTP code).
All information is contained in the CP defined to manage DV certificate published by OpenTrust. OpenTrust manages certificate according ETSI 102 042 DVCP. OpenTrust’s CP used to manage SSL/TLS certificates named: “DMS_PC Certificates OpenTrust SSL RGS et ETSI V1.1”.

For OV certificate:
We use only information found in a WHOIS databe to contact and authenticate the Applicant’s ownership or control of all requested Domain Name(s). We can also use email address like; [e-mail], [e-mail], [e-mail] , [e-mail] or [e-mail].
In addition to that, the Applicant shall provide a legible copy of a valid government issued national identity document or photo ID (driver’s licence, national ID or equivalent) to the RA.
Applicant shall sign a certificate request using its email with a challenge (OTP code).
In addition to DV verification, the legal existence, legal name, legal form and requested address of the organization is verified using one of the following:
	A government agency in the jurisdiction of the Applicant;
	A third party database that is periodically updated and trusted by OpenTrust has being reasonably accurate and reliable; or
	An attestation letter confirming that orgnaisation identity is correct written by an accountant, lawyer, government official, or other reliable third party trusted by OpenTrust has being reasonably accurate and reliable.
In addition to DV verification, RA authenticates the Applicant is authorized to represent the organization, for certificate request, wishing to be named as the Subject in the Certificate by performing a telephone challenge/response to the Applicant’s organization using a telephone number from a reliable source.
All information is contained in the CP defined to manage OV certificate published by OpenTrust. OpenTrust manages certificate according ETSI 102 042 OVCP.
For RGS certificate (French requirements):
CA follows the requirement of ETSI 102 042 OVCP and CAB Forum requirements and applies the verification method defined for OV above. OpenTrust’s CP used to manage SSL/TLS certificates named: “DMS_PC Certificates OpenTrust SSL RGS et ETSI V1.1”.
For EV certificate:
The EV Guidelines are followed. OpenTrust is certified against EV Guidelines.
OpenTrust’s CP used to manage EV certificates named: “DSQ_NT_KEYNECTIS_EV_SSL_CA_CPS_20090504s.pdf”.

For Organization Verification Procedures:
Please refer to section “SSL Verification Procedures” above.

For Email Address Verification Procedures:
Please refer to section “SSL Verification Procedures” above.

For Code Signing Subscriber Verification Procedures:
Please refer to section “SSL Verification Procedures” above.
OpenTrust follow the EV code signing baseline requirements.

For Response to Mozilla's CA Recommended Practices:
Document Handling of IDNs in CP/CPS
IDN not currently supported.

Verifying Domain Name Ownership
Yes, please refer to section “SSL Verification Procedures” above.

Verifying Email Address Control
Yes, please refer to section “SSL Verification Procedures” above.

Verifying Identity of Code Signing Certificate Subscriber
Yes, please refer to section “SSL Verification Procedures” above.
In addition to that Code Signing certificate will be managed like EV SSL certificate.

DNS names go in SAN
Yes, please refer to section “SSL Verification Procedures” above.

Domain owned by a Natural Person
Yes, please refer to section “SSL Verification Procedures” above.
In addition to that, domain owned by natural person is only possible for DV certificate (not authorized for OV, French RGS and EV SSL). SAN shall be filled with at least one entry and one of the entries shall be placed in the CN of the DN of the subject. These rules is mentioned in the section “7.1.1.4	Extension du certificate” of OpenTrust’s CP used to manage SSL/TLS certificates named: “DMS_PC Certificates OpenTrust SSL RGS et ETSI V1.1”. It will be controlled in CA’s CP of our customer who will be signed by our RCA.

For Response to Mozilla's list of Potentially Problematic Practices:
Long-­‐lived DV certificates
OpenTrust meets the needs of Mozilla recommendation on Certificate duration. DV certificate can’t have a life time longer than 3 years.

Wildcard DV SSL certificates
OpenTrust issues Wildcard certificate but follow all verification required by CAB Forum only for DV and OV. Wildcard is not authorized for EV and French RGS certificate.
DV and OV Certificates include a wildcard asterisk character.
Before issuing a Wildcard certificate, RA verifies that rules given in section “11.1.3 Wildcard Domain Validation” from CAB Forum requirements for SSL/TLS certificate are respected.

Email Address Prefixes for DV Certs
Please refer to section “SSL Verification Procedures” above.

Delegation of Domain / Email validation to third parties
Please refer to section “SSL Verification Procedures” above.
In addition to that and as already explained in this section and in the RCA’s CP, OpenTrust’s PMA audits and approves all procedures from external entities signed by RCA. This control covers all PKI component of the PKI whom CA is signed by OpenTrust’s RCA or ICA (refer to section 8 of RCA’s CP). Additionally to that, when external entity is only RA for OpenTrust’s CA, a contract shall be established between OpenTrust and external entity and the contract reference the procedure approved by PMA and that have to be used by RA. A contract is also required when a CA wants to get signed by OpenTrust.

Issuing end entity certificates directly from roots
All RCA and ICA of OpenTrust shall be off-line CA has mentioned in RCA’s CP. RCA can only issue certificate for OCSP responder as mentioned in RCA’s CP. RCAs are not authorized to issue others kind of Subscriber certificate.

Allowing external entities to operate subordinate CAs
Please refer to section “SSL Verification Procedures” above.
As explained, RCA’s CP describes clearly how Root CA, ICA and all CA (OpenTrust’s CA and Customer’s CA) are audited. Please refer to section 1.4, 4.1, 4.2 and 8 of the RCA’s CP.

Distributing generated private keys in PKCS#12 files
CAs may be authorized by OpenTrust to issue such key pair and associated certificate. OpenTrust’s has a CA who provides Pkcs#12 key pair and the process is audited each year by external entity (LSTI) according RGS and ETSI rules (102 042) and uses a HSM certified EAL4+ or FIPS 140-2 level 3. But for SSL/TLS certificate, OpenTrust doesn’t generate the key for Subscriber.

Certificates referencing hostnames or private IP addresses
This practice is not authorized by OpenTrust. A CA can’t be signed by RCA or ICA of OpenTrust if it delivers such kind of certificate.

Issuing SSL Certificates for Internal Domains
This practice is not authorized by OpenTrust. A CA can’t be signed by RCA or ICA of OpenTrust if it delivers such kind of certificate.

CRL with critical CIDP Extension
Not applicable as OpenTrust uses only full CRLs.

Generic names for CAs
Not applicable as mentioned in RCA’s CP (section 3.1.1). RCA, ICA and CA certificates shall contain at least the name of the legal entity which owns the CA.

Lack of Communication with End Users
OpenTrust and its Customer communicate in case of incident about identity towards Subscriber and Relying Party and software platform providers (where RCA is referenced) if the incident may have an effect on entity that relies on the issued certificate under RCA trust certification path.

Backdating the notBefore date
All new certificates are always issued with starting date in the future (means a starting date that is later than the date of the operation to issue the certificate). OpenTrust can issue ICA or CA certificate with a starting date beginning in the past: this operation may only occur sfor ICA and CA certificate renewal operation with the same key pair and same DN than it was used in the previous ICA or CA certificate (refer to section 4.6 and 4.8).

Comment 10

[Kathleen Wilson]

(In reply to Remi Pifaut from comment #9)
> Technical information about each root certificate – OpenTrust Brand
> “Non-­‐sequential serial numbers and entropy in cert”
> Answer: all certiticate serial numbers for Subscriber issued by CA shall
> have a random number on 16 bytes longs.

Which document (CP/CPS) states this?

Note Baseline Requirements section 9.6: CAs SHOULD generate non-sequential Certificate serial numbers that exhibit at least 20 bits of entropy.

> 
> SSL Verification Procedures:
...
> These explanations are contained in CP defined to manage Subscriber
> key pair and certificate life cycle. 

Please provide the URL to that document or set of documents.


> All information is contained in the CP defined to manage DV certificate
> published by OpenTrust. 

Please provide the URL to this specific document.



> OpenTrust’s CP used to manage SSL/TLS certificates named: “DMS_PC
> Certificates OpenTrust SSL RGS et ETSI V1.1”.

Please provide the URL to this specific document.


> All information is contained in the CP defined to manage OV certificate
> published by OpenTrust. 

Please provide the URL to this specific document.


> OpenTrust’s CP
> used to manage SSL/TLS certificates named: “DMS_PC Certificates OpenTrust
> SSL RGS et ETSI V1.1”.

Please provide the URL to this specific document.


> For EV certificate:
> The EV Guidelines are followed. OpenTrust is certified against EV Guidelines.
> OpenTrust’s CP used to manage EV certificates named:
> “DSQ_NT_KEYNECTIS_EV_SSL_CA_CPS_20090504s.pdf”.


This document?
 http://www.opentrust.com/PDF/FR/PC/DSQ_PC_PC_AC_KEYNECTIS_SSL_1.2s.pdf



> 
> Delegation of Domain / Email validation to third parties
> Please refer to section “SSL Verification Procedures” above.
> In addition to that and as already explained in this section and in the
> RCA’s CP, OpenTrust’s PMA audits and approves all procedures from external
> entities signed by RCA. This control covers all PKI component of the PKI
> whom CA is signed by OpenTrust’s RCA or ICA (refer to section 8 of RCA’s
> CP). Additionally to that, when external entity is only RA for OpenTrust’s
> CA, a contract shall be established between OpenTrust and external entity
> and the contract reference the procedure approved by PMA and that have to be
> used by RA. A contract is also required when a CA wants to get signed by
> OpenTrust.


Please provide more information about the CA hierarchy. 
What external entities are allowed? Externally-operated CAs? External RAs? etc.
How are the external entities constrained?
Please explain in relation to the CA/Browser Forum's Baseline Requirements sections 9.7 and 17.


> Allowing external entities to operate subordinate CAs
> Please refer to section “SSL Verification Procedures” above.
> As explained, RCA’s CP describes clearly how Root CA, ICA and all CA
> (OpenTrust’s CA and Customer’s CA) are audited. Please refer to section 1.4,
> 4.1, 4.2 and 8 of the RCA’s CP.


Please provide the URL to the RCA's CP.

Comment 11

[Kathleen Wilson]

It looks like this may also be applicable/needed:
https://wiki.mozilla.org/CA:SubordinateCA_checklist

Comment 12

[Remi Pifaut]

(In reply to Kathleen Wilson from comment #10)
> (In reply to Remi Pifaut from comment #9)
> > Technical information about each root certificate – OpenTrust Brand
> > “Non-­‐sequential serial numbers and entropy in cert”
> > Answer: all certiticate serial numbers for Subscriber issued by CA shall
> > have a random number on 16 bytes longs.
> 
> Which document (CP/CPS) states this?
> 
> Note Baseline Requirements section 9.6: CAs SHOULD generate non-sequential
> Certificate serial numbers that exhibit at least 20 bits of entropy.
>

We will add this specific information in the existing CP. We will inform you when the update is done.

> > 
> > SSL Verification Procedures:
> ...
> > These explanations are contained in CP defined to manage Subscriber
> > key pair and certificate life cycle. 
> 
> Please provide the URL to that document or set of documents.

URLs are the following:
- EV CP: https://www.opentrust.com/PDF/FR/PC/DSQ_NT_KEYNECTIS_EV_SSL_CA_CPS_20090504s.pdf
- for other SSL types, see French CP document (§ 3.2, 3.3, from 4.1 till 4.8):
https://www.opentrust.com/images/stories/OpenTrust_DMS_PC_Certificats_OpenTrust_SSL_RGS_et_ETSI_V1_1s.pdf

> 
> 
> > All information is contained in the CP defined to manage DV certificate
> > published by OpenTrust. 
> 
> Please provide the URL to this specific document.

URL is the following:
- see French CP document (§ 3.2, 3.3, from 4.1 till 4.8):
https://www.opentrust.com/images/stories/OpenTrust_DMS_PC_Certificats_OpenTrust_SSL_RGS_et_ETSI_V1_1s.pdf

> 
> 
> > OpenTrust’s CP used to manage SSL/TLS certificates named: “DMS_PC
> > Certificates OpenTrust SSL RGS et ETSI V1.1”.
> 
> Please provide the URL to this specific document.

https://www.opentrust.com/images/stories/OpenTrust_DMS_PC_Certificats_OpenTrust_SSL_RGS_et_ETSI_V1_1s.pdf

> 
> > All information is contained in the CP defined to manage OV certificate
> > published by OpenTrust. 
> 
> Please provide the URL to this specific document.

URL is the following:
- see French CP document (§ 3.2, 3.3, from 4.1 till 4.8):
https://www.opentrust.com/images/stories/OpenTrust_DMS_PC_Certificats_OpenTrust_SSL_RGS_et_ETSI_V1_1s.pdf

> 
> 
> > OpenTrust’s CP
> > used to manage SSL/TLS certificates named: “DMS_PC Certificates OpenTrust
> > SSL RGS et ETSI V1.1”.
> 
> Please provide the URL to this specific document.

URL is the following:
- see French CP document (§ 3.2, 3.3, from 4.1 till 4.8):
https://www.opentrust.com/images/stories/OpenTrust_DMS_PC_Certificats_OpenTrust_SSL_RGS_et_ETSI_V1_1s.pdf

> 
> > For EV certificate:
> > The EV Guidelines are followed. OpenTrust is certified against EV Guidelines.
> > OpenTrust’s CP used to manage EV certificates named:
> > “DSQ_NT_KEYNECTIS_EV_SSL_CA_CPS_20090504s.pdf”.
> 
> 
> This document?
>  http://www.opentrust.com/PDF/FR/PC/DSQ_PC_PC_AC_KEYNECTIS_SSL_1.2s.pdf
> 

EV CP url is: https://www.opentrust.com/PDF/FR/PC/DSQ_NT_KEYNECTIS_EV_SSL_CA_CPS_20090504s.pdf

> 
> > 
> > Delegation of Domain / Email validation to third parties
> > Please refer to section “SSL Verification Procedures” above.
> > In addition to that and as already explained in this section and in the
> > RCA’s CP, OpenTrust’s PMA audits and approves all procedures from external
> > entities signed by RCA. This control covers all PKI component of the PKI
> > whom CA is signed by OpenTrust’s RCA or ICA (refer to section 8 of RCA’s
> > CP). Additionally to that, when external entity is only RA for OpenTrust’s
> > CA, a contract shall be established between OpenTrust and external entity
> > and the contract reference the procedure approved by PMA and that have to be
> > used by RA. A contract is also required when a CA wants to get signed by
> > OpenTrust.
> 
> 
> Please provide more information about the CA hierarchy. 
> What external entities are allowed? Externally-operated CAs? External RAs?
> etc.
> How are the external entities constrained?
> Please explain in relation to the CA/Browser Forum's Baseline Requirements
> sections 9.7 and 17.
> 

Please have a look to document https://www.opentrust.com/images/stories/DMS_RCA_Program_OpenTrust_CP_v_1_0s.pdf:
- For CA hierarchy, see § 1.1 (introduction) + from 1.3.2 until 1.3.5 + 1.4.1
- For questions related to external entities, see: 4.1.2.3 and 4.2.2.2
- For external entities constrained, see: 4.1.2.3
- For question related to CA/Browser Forum's Baseline Requirements sections 9.7: see 4.1.2.3 and 10.3
- For question related to CA/Browser Forum's Baseline Requirements sections 17: see 6.1.1 and 8

> 
> > Allowing external entities to operate subordinate CAs
> > Please refer to section “SSL Verification Procedures” above.
> > As explained, RCA’s CP describes clearly how Root CA, ICA and all CA
> > (OpenTrust’s CA and Customer’s CA) are audited. Please refer to section 1.4,
> > 4.1, 4.2 and 8 of the RCA’s CP.
> 
> 
> Please provide the URL to the RCA's CP.

RCA CP is: https://www.opentrust.com/images/stories/DMS_RCA_Program_OpenTrust_CP_v_1_0s.pdf

Comment 13

[Kathleen Wilson]

So, for the new Certplus and OpenTrust roots, the following three CP documents apply. Correct?

RCA CP (English): http://www.opentrust.com/images/stories/DMS_RCA_Program_OpenTrust_CP_v_1_0s.pdf
Last Updated: 12/05/2014

EV CP (English): https://www.opentrust.com/PDF/FR/PC/DSQ_NT_KEYNECTIS_EV_SSL_CA_CPS_20090504s.pdf
Last Updated: 05/05/2009

SSL CP (French): https://www.opentrust.com/images/stories/OpenTrust_DMS_PC_Certificats_OpenTrust_SSL_RGS_et_ETSI_V1_1s.pdf
Last Updated: 24/06/2014 


When I look at http://www.opentrust.com/en/certification-policy 
it seems like only the RCA CP applies to the new roots.
And I don't see where the SSL CP is -- which section is it in?

Comment 14

[Remi Pifaut]

(In reply to Kathleen Wilson from comment #13)
> So, for the new Certplus and OpenTrust roots, the following three CP
> documents apply. Correct?

Yes that is correct.

> 
> RCA CP (English):
> http://www.opentrust.com/images/stories/DMS_RCA_Program_OpenTrust_CP_v_1_0s.
> pdf
> Last Updated: 12/05/2014

This CP applies to Root CA, ICA and CA life cycle management.

> EV CP (English):
> https://www.opentrust.com/PDF/FR/PC/DSQ_NT_KEYNECTIS_EV_SSL_CA_CPS_20090504s.
> pdf
> Last Updated: 05/05/2009

This CP applies to management of Subscriber EV SSL certificate issued by the new Certplus and OpenTrust roots.

> SSL CP (French):
> https://www.opentrust.com/images/stories/
> OpenTrust_DMS_PC_Certificats_OpenTrust_SSL_RGS_et_ETSI_V1_1s.pdf
> Last Updated: 24/06/2014 

This CP applies to management of Subscriber EV SSL (fulfilling French "RGS" requirements, ie for certificates to be used in relation with French government), OV SSL and DV SSL certificate issued by the new Certplus and OpenTrust roots.

> 
> When I look at http://www.opentrust.com/en/certification-policy 
> it seems like only the RCA CP applies to the new roots.
> And I don't see where the SSL CP is -- which section is it in?

The SSL CP is present in general paragraph for SSL (named K.SSL / Club SSL / ISP SSL): the PC is named "SSL Extended Validation CA certificate policy version" and is associated to https://www.opentrust.com/PDF/FR/PC/DSQ_NT_KEYNECTIS_EV_SSL_CA_CPS_20090504s.pdf.

Comment 15

[Kathleen Wilson]

We recently created a new wiki page:
https://wiki.mozilla.org/CA:BaselineRequirements

Please review it with your auditor, and update this bug when that has happened.

Comment 16

[Remi Pifaut]

What type of delivery do you expect: a new comment with answers to BRs as indicated in your wiki or a document signed by the auditor?

Comment 17

[Kathleen Wilson]

(In reply to Remi Pifaut from comment #16)
> What type of delivery do you expect: a new comment with answers to BRs as
> indicated in your wiki or a document signed by the auditor?

Just an acknowledgement (comment in this bug) that you have reviewed the wiki page with your auditor.

Comment 18

[Kathleen Wilson]

Testing with the provided test URLs:
https://certplusrootcag1-test.opentrust.com
https://certplusrootcag2-test.opentrust.com
https://opentrustrootcag1-test.opentrust.com
https://opentrustrootcag2-test.opentrust.com
https://opentrustrootcag3-test.opentrust.com

The "KEYNECTIS Extended Validation CA" intermediate cert is cross-signed with all 5 of these root certs. So, to test I have to create a new Firefox profile, import only the root cert I'm testing, then browse to the test site and check the cert chain. Then I see that the ssl cert chains to the root I'm testing. However, if I don't create a new profile, the resulting cert chains will be different due to the cross-signing.

Comment 19

[Remi Pifaut]

Currently this the expected behaviour. We have processed the test certs this way to allow you to check these certs without delay.
When we issue "production" certificates (once the roots will be added to main browsers), we will create other sub-CAs for that purpose (like the "KEYNECTIS Extended Validation CA" but with a new name, certainly with OpenTrust inside!).
So there is no worry on that topic for production certificates to come.

Comment 20

[Kathleen Wilson]

To proceed with the EV-enablement part of this request, the testing described on this wiki page needs to be performed: https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version

However, I think that the cross-signing is going to present a problem. You might have to download the code for the test and compile it. Then, before running each test, restore the default certificate settings (or create/use a new profile).
Code for the test: https://github.com/mozkeeler/ev-checker
https://wiki.mozilla.org/CA:UserCertDB#How_To_Restore_Default_Root_Certificate_Settings
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

Comment 21

[Kathleen Wilson]

Attachment: Updated CA Information Document

Within the document, the items highlighted in yellow indicate where further information or clarification is needed.

Comment 22

[Remi Pifaut]

Kathleen,
We are currently reviewing your document containing your yellow highlighted remarks.
I also have a question regarding a green highlighted text "Our existing audit covering our current CA used for EV certificat issuance. This audit will include new CAs in its next version to be done by January 2015."
We passed successfuly our last audit in October 2014 for current issuing CAs (OV and DV ones) and in January 2014 for EV CA (i.e. CAs that are the ones issuing the SSL final certs). This audit does not include new root CAs that are concerned by this bugzilla case. Nevertheless, creation of these root CA certificates has been done with our auditors as witnesses during the key ceremony.
When I read the § CA's first audit from page https://wiki.mozilla.org/CA:BaselineRequirements#A_CA.27s_First_BR_Audit, then I see that a PITRA may be used for new CAs to be included in root programs. Can your confirm a PITRA may be used for all five new CAs to be included in your CA root program? When will you need an official audit regarding these new root CAs? I understood within one year after inclusion but need confirmation.
Last question: where can we find a Template for the PITRA?

Comment 23

[Kathleen Wilson]

(In reply to Remi Pifaut from comment #22)
> Kathleen,
> We are currently reviewing your document containing your yellow highlighted
> remarks.
> I also have a question regarding a green highlighted text "Our existing
> audit covering our current CA used for EV certificat issuance. This audit
> will include new CAs in its next version to be done by January 2015."
> We passed successfuly our last audit in October 2014 for current issuing CAs
> (OV and DV ones) and in January 2014 for EV CA (i.e. CAs that are the ones
> issuing the SSL final certs). This audit does not include new root CAs that
> are concerned by this bugzilla case. Nevertheless, creation of these root CA
> certificates has been done with our auditors as witnesses during the key
> ceremony.

OK. Green just means I have to remember to check it later. In this case, I need to remember to check the new audit statements in January.

> When I read the § CA's first audit from page
> https://wiki.mozilla.org/CA:BaselineRequirements#A_CA.27s_First_BR_Audit,
> then I see that a PITRA may be used for new CAs to be included in root
> programs. Can your confirm a PITRA may be used for all five new CAs to be
> included in your CA root program? 

Correct. These new roots fall into scenario #1 of when a BR PITRA may be used:
"1. An organization is standing up a CA for the first time, wants to issue public SSL certs, so the first audit would be point in time, with all subsequent audits being period of time. "

> When will you need an official audit
> regarding these new root CAs? I understood within one year after inclusion
> but need confirmation.

Correct.


> Last question: where can we find a Template for the PITRA?

I don't know if there's a template, your auditor should be able to find out. It's basically a pre-issuance readiness audit against either the ETSI 102 042 PTC-BR criteria or the WebTrust for BR criteria.

Comment 24

[Remi Pifaut]

(In reply to Kathleen Wilson from comment #21)
> Created attachment 8497854 [details]
> Updated CA Information Document
> 
> Within the document, the items highlighted in yellow indicate where further
> information or clarification is needed.

It's been a long time since the last post.

Regarding the items you highlighted in yellow, you will find below our answers. First I indicate the type of item (as it is named in the first column of your document) and them our answer.

“OCSP URL”
“What is the maximum expiration time of OCSP responses?”:
OpenTrust's answer: OCSP response for CA has a maximum expiration time of ten days (refer to CP section 4.10.1). This answer is valid for all new root CAs to be included.

“EV Policy OID”
"Please do EV testing as described here"

OpenTrust's answer: we currently work on that topic for testing purposes.
Nevertheless; Policy OID associated to EV SSL certificates issued within a specific hierarchy (thus to a specific Root CA) may be:
-	The existing one (the one used for existing root CA)
-	Another one for each new root CA
In this case, up to 3 or 4 different OIDs would be associated to the root CA in your browser. We have some questions:
- How would this be feasible on your side?
- What types of tests would you perform? 
- If we don't provide you with all the OIDs, how long will it last (once our roots are included in your browser) to add new OID to an included root CA?


 “Policy Documentation”
"I still cannot figure out how to get to the following document from a link in http://www.opentrust.com/en/certification-­‐policySSLCP(French)"

OpenTrust's answer:
Go to the web page https://www.opentrust.com/fr/ressources/PC-politique-certification
In § « Certificats OpenTrust SSL RGS et ETSI », you will find the CP for French RGS and European ETSI SSL certs
•	Politique de certification des AC SSL RGS et/ou ETSI (authentification serveur seulement) that points out to : https://www.opentrust.com/ressources/publications/OpenTrust_DMS_PC%20Certificats%20OpenTrust%20SSL%20RGS%20et%20ETSI%20V1.4s.pdf

In § “K.SSL / Club SSL / ISP SSL”, you will find the EV SSL CPS:
•	Politique de Certification SSL Extended Validation (Version anglaise)» that points out to https://www.opentrust.com/images/stories/OpenTrust_DMS_EV_SSL_CA_Certification_Practice_Statement_2014_12_18s.pdf 


“Audits:”
"Would you please ask LSTI to add an indicator for when the BR audit criteria is also used? E.g. PTC-­‐BR or such?"

OpenTrust's answer: 
We are currently waiting for new audit attestation (certification) to be provided by our auditor by end of March/early beginning of April 2015. We will add it to this case once we have received it.
Auditor attestation indicates the ETSI and its version and the level EVCP.


“Baseline Requirements (SSL)”
"It’s not clear to me if this means the BRs the EV guidelines or both"

OpenTrust's answer: 
All these 3 documents shall be used to certify CA, under OpenTrust’s RCA, which issues SSL Certificate plus ETSI 102 042:
https://cabforum.org/wp-content/uploads/BRv1.2.3-redlined.pdf 
https://cabforum.org/wp-content/uploads/EV-V1_5_2Libre.pdf 
https://cabforum.org/wp-content/uploads/Network_Security_Controls_V1.pdf 
Thus it covers both BR and EV guidelines.


“SSL Verification Procedures”
"Please translate into English SSL CP sections: 4.1.2.1, 4.1.2.2, 4.1.2.3, 4.2, 4.3"

OpenTrust's answer:
Please find below translation of sections 4.1 to 4.3 of document published at: https://www.opentrust.com/ressources/publications/OpenTrust_DMS_PC%20Certificats%20OpenTrust%20SSL%20RGS%20et%20ETSI%20V1.4s.pdf

“4.1	Certificate Application
Sections 4.1, 4.2, 4.3 and 4.4 specify the requirements for an initial application for certificate issuance. Sections 4.6, 4.7 and 4.8 specify the requirements for certificate renewal. 
4.1.1	Who Can Submit a Certificate Application
A certificate request is addressed by TC (Technical Contact) or an SSL Administrator to RA.

4.1.2	Enrollment Process and Responsibilities
The complete application form, signed and dated, shall be addressed to RA by CT or SSL Administrator.

4.1.2.1 Certificate non RGS: DV (Domain Validated Certificate)
The following information must be included in the SSL certificate request:

	The certificate request is signed by the TC (depending on the origin of the request), and dated less than 3 months.
	The information requested to be set in the DN of the SSL certificate (refer to section 3.1 above).
	An official valid identity document with photo of the TC (depending on the source of the request), with signature of the person concerned on the photocopy of his ID preceded by the words "certified copy the original "(for paper records only and not for electronic record). RA shall keep a record of it.
	The information required by RA to contact the TC and the domain owner (phone, email, etc.). At a minimum, an electronic mail address as entered in the WHOIS must be used. If this is not the case, then the e-mail address must be confirmed from the email address contained in the WHOIS or be of the form "admin", "administrator", "webmaster", "hostmaster "or" postmaster "@ <domain name requested by TB>.
	The General Terms and Conditions (GTU) signed by TC.
	The CSR of the public key to be certified.

The certificate request is signed using a temporary password (OTP code), and OpenTrust signature Portal, transmitted to the email address contained in the certificate request described above in accordance with the signature policy [Form Signing]. This ensures the email address of the TC.

4.1.2.2 Certificate non RGS: OV (Organization Validated Certificate)
The following information must be included in the SSL certificate request:

	The certificate request is signed by the TC or the Administrator SSL (depending on the origin of the request), and dated less than 3 months.
	The information requested to be set in the DN and SAN of the SSL certificate (refer to section 3.1 above).
	An official valid identity document with photo of the TC or the Administrator SSL (depending on the source of the request), with signature of the person concerned on the photocopy of his ID preceded by the words "certified copy the original "(for paper records only and not for electronic record). RA shall keep a record of it.
	The information required by RA to contact the TC and the domain owner or the Administrator SSL (phone, email, etc.). At a minimum, an electronic mail address as entered in the WHOIS must be used. If this is not the case, then the e-mail address must be confirmed from the email address contained in the WHOIS or be of the form "admin", "administrator", "webmaster", "hostmaster "or" postmaster "@ <domain name requested by TB>.
	Name of the Legal Entity to be set in the certificate and which owns the CN and SAN requested.
	The General Terms and Conditions (GTU) signed by TC or SSL Administrator.
	The CSR of the public key to be certified.

The certificate request is signed using a temporary password (OTP code), and OpenTrust signature Portal, transmitted to the email address contained in the certificate request described above in accordance with the signature policy [Form Signing]. This ensures the email address of the TC or the Administrator SSL.

4.1.2.2 Certificate RGS: OV and EV
The following information must be included in the SSL certificate request:

	A mandate dated less than 3 months, indicating the future TC or SSL Administrator as authorized to be CT or SSL Administrator for the domain name (FQDN). This mandate must be signed by a legal representative (authorized to sing in the name of the legal entity, CEO for example) of the legal entity that owns the legal entity's domain name and co-signed for acceptance by TC or SSL Administrator.
	The certificate request is signed by the TC or the Administrator SSL (depending on the origin of the request), and dated less than 3 months. The mandate and the certificate request can be merged in one application form.
	The information requested to be set in the DN and SAN of the SSL certificate (refer to section 3.1 above).
	An official valid identity document with photo of the TC or the Administrator SSL (depending on the source of the request), with signature of the person concerned on the photocopy of his ID preceded by the words "certified copy the original "(for paper records only and not for electronic record). RA shall keep a record of it.
	The information required by RA to contact the TC and the domain owner or the Administrator SSL (phone, email, etc.). At a minimum, an electronic mail address as entered in the WHOIS must be used. If this is not the case, then the e-mail address must be confirmed from the email address contained in the WHOIS or be of the form "admin", "administrator", "webmaster", "hostmaster "or" postmaster "@ <domain name requested by TB>.
	Name of the Legal Entity to be set in the certificate and which owns the CN and SAN requested.
	The General Terms and Conditions (GTU) signed by TC or SSL Administrator and the Legal Representative of the legal entity which owns the CN and the SAN.
	The CSR of the public key to be certified.
	Any document attesting to the title of the TC or SSL Administrator. As the title of the TC or SSL Administrator is included in the certificate application form, then it is guaranteed by the legal entity as legal representative signs the certificate application.
	For non-government entity: Any document, valid during the certificate request (Kbis extract or Certificate of Identification from a National Directory of Legal Entity or entry in the trade directory, etc.), attesting to the existence of the legal entity which owns the domain name and bearing the national identification number of the latter, or, failing that, another document showing the unique identification of the legal entity which owns the domain name and whose name will be included in the certificate.
	For government entity: A document certifying the delegation or sub-delegation of authority from the administrative structure owner of the domain name.

The certificate request is signed using a temporary password (OTP code), and OpenTrust signature Portal, transmitted to the email address contained in the certificate request described above in accordance with the signature policy [Form Signing]. This ensures the email address of the TC or the Administrator SSL.

4.2	Certificate Application Processing
4.2.1	Performing Identification and Authentication Functions
RA authenticates the TC, SSL Administrator and Legal Entity (refer to sections 3.2 and 3.2.5 above).
RA ensures that the TC, SSL Administrator and Legal Entity, if needed, have signed the GTU.
RA stores all data (screen shot of web site used to control legal entity, ID card copy, signed GTU…) that composed the certificate application and used to validate the certificate request.

4.2.2	Approval or Rejection of Certificate Applications
Approval certificate is performed by RA. If the certificate request is correct and valid, then the RA transmits the certificate request to the Sub-CA. EV SSL certificate requires 2 distinct persons in the RA to be validated.
If the certificate is rejected by RA, then RA alerts the TC with justification.

4.2.3	Time to Process Applications
The RA shall be responsible for approving or rejecting certificate application promptly.

4.3	Certificate Issuance
4.3.1	CA Actions during Certificate Issuance
Sub-CA receives the certificate request from the RA.
Sub-CA authenticates the RA.
Sub-CA generates certificates.
RA collects the certificate from Sub-CA
The RA sends the certificate to the TC using the email of the TC.

When there is an SSL Administrator, then this is the SSL Administrator that directly emits a technical request to the RA. SSL Administrator is authenticated during an SSL session by RA, and the transmission initiates the SSL certificate generation by CA. SSL Administrator pickup its SSL certificate.
All communication between PKI entities are protected in integrity and confidentiality and authenticated.

4.3.2	Notification to Subscriber by the CA of Issuance of Certificate
SSL Certificate is transmitted by RA to TC or downloaded from RA interface by SSL Administrator.”


“SSL Verification Procedures”
"[I couldn’t find this. Which section is it in?]

OpenTrust's answer: 
This is in CP section 4.1.2


“SSL Verification Procedures”
"OTP Code [I couldn’t find this. Which section is it in?]

OpenTrust's answer: 
This is in CP section 4.1.2


“Email Address Verification Procedures”
"Which document describes the verification procédures for email (S/MIME) certificates?"

OpenTrust's answer:
As mentioned in CP, section 4.1.2: “The certificate request is signed using a temporary password (OTP code), and OpenTrust signature Portal, transmitted to the email address contained in the certificate request described above in accordance with the signature policy [Form Signing]. This ensures the email address of the TC or the Administrator SSL.”.


“Multi-­‐factor Authentication”
"I read through this section in the RCA CP, but I did not find anything about a second-­‐factor of Authentication (in addition to the password)."

OpenTrust's answer:
As mentioned in CP RCA, section 6.5.1.2: “Enforce strong authentication for administrator access to all PKI components.”. This mean that all account capable of directly issue certificate shall use a strong authentication (means 2 factors authentication) to connect to the PKI system.


“OCSP Responses signed by a certificate under a different root”
"???"

OpenTrust's answer:
No.
As mentioned in RCA CP; section 1.4.1.1 for RCA, section 1.4.1.2 for Intermediate CA (ICA) and section 1.4.1.3 for CA:

	RCA signs the OCSP responder for CA and ICA signed RCA.
	ICA signs the OCSP responder for CA signed by ICA.
	CA signs the OCSP responder for Subscriber signed by CA

We never use different CA between Subscriber and OCSP. OCSP is always signed by the CA that has issued Certificate to be validated with the OCSP.

Comment 25

[Kathleen Wilson]

Attachment: 1025095-CAInformation.pdf

I've entered the data for this request into SalesForce.

Please review the attached document to ensure it is correct and complete, and provide corrections by posting comments in this bug.

Comment 26

[Kathleen Wilson]

(In reply to Remi Pifaut from comment #24)
> 
> OpenTrust's answer: we currently work on that topic for testing purposes.
> Nevertheless; Policy OID associated to EV SSL certificates issued within a
> specific hierarchy (thus to a specific Root CA) may be:
> -	The existing one (the one used for existing root CA)
> -	Another one for each new root CA
> In this case, up to 3 or 4 different OIDs would be associated to the root CA
> in your browser. We have some questions:
> - How would this be feasible on your side?
> - What types of tests would you perform? 
> - If we don't provide you with all the OIDs, how long will it last (once our
> roots are included in your browser) to add new OID to an included root CA?
> 


The code for enabling EV treatment is in this file:
https://mxr.mozilla.org/mozilla-central/source/security/certverifier/ExtendedValidation.cpp

Usually CAs use the same EV Policy OID for all of their root certificates.

In the file, I see that there are a few CAs with an "...a" and "...b" EV Policy OID for different roots.

I am not finding any certificates in that file that have more than one EV Policy OID.

So, based on that, I would venture to guess that we don't currently support a root certificate having more than one EV Policy OID.

Comment 27

[Remi Pifaut]

We will review the attachment, but it takes a while to do it...

In the meantime, we just receives today the audit report from LSTI. I add it in attachment to this bug in order for you to be able to update the data into Salesforce.

(In reply to Kathleen Wilson from comment #25)
> Created attachment 8589380 [details]
> 1025095-CAInformation.pdf
> 
> I've entered the data for this request into SalesForce.
> 
> Please review the attached document to ensure it is correct and complete,
> and provide corrections by posting comments in this bug.

Comment 28

[Remi Pifaut]

Attachment: Audit report 20150409

Audit report from LSTI dated 9th of April 2015.

Comment 29

[Erwann Abalea]

(In reply to Kathleen Wilson from comment #26)
> (In reply to Remi Pifaut from comment #24)
> > 
> > OpenTrust's answer: we currently work on that topic for testing purposes.
> > Nevertheless; Policy OID associated to EV SSL certificates issued within a
> > specific hierarchy (thus to a specific Root CA) may be:
> > -	The existing one (the one used for existing root CA)
> > -	Another one for each new root CA
> > In this case, up to 3 or 4 different OIDs would be associated to the root CA
> > in your browser. We have some questions:
> > - How would this be feasible on your side?
> > - What types of tests would you perform? 
> > - If we don't provide you with all the OIDs, how long will it last (once our
> > roots are included in your browser) to add new OID to an included root CA?
> > 
> 
> 
> The code for enabling EV treatment is in this file:
> https://mxr.mozilla.org/mozilla-central/source/security/certverifier/
> ExtendedValidation.cpp
> 
> Usually CAs use the same EV Policy OID for all of their root certificates.
> 
> In the file, I see that there are a few CAs with an "...a" and "...b" EV
> Policy OID for different roots.
> 
> I am not finding any certificates in that file that have more than one EV
> Policy OID.
> 
> So, based on that, I would venture to guess that we don't currently support
> a root certificate having more than one EV Policy OID.

The code works, see for example "CN=Izenpe.com,O=IZENPE S.A.,C=ES", which has 2 OIDs declared "1.3.6.1.4.1.14777.6.1.1" and "1.3.6.1.4.1.14777.6.1.2".
The declaration block is just repeated, only the OID changes.

Comment 30

[Remi Pifaut]

(In reply to Kathleen Wilson from comment #25)
> Created attachment 8589380 [details]
> 1025095-CAInformation.pdf
> 
> I've entered the data for this request into SalesForce.
> 
> Please review the attached document to ensure it is correct and complete,
> and provide corrections by posting comments in this bug.

Following comment #25 and its attached document (https://bugzilla.mozilla.org/attachment.cgi?id=8589380), we have some comments/answers regarding the content:
-	In the document there is an item with “Root store included in” for which you are waiting for answer: what does this item mean? What do you expect from us?
-	Regarding all items in relation with the audits, please review audit report that I sent in the comment #28 (https://bugzilla.mozilla.org/attachment.cgi?id=8590352).
-	We have updated our web site. In consequence, some urls you pointed out have changed regarding CP and CPS. You will find below old urls and new urls to use instead to update your document):
o	Generic page for PCs (in French):
	Old: https://www.opentrust.com/fr/ressources/PC-politique-certification
	New: https://www.opentrust.com/pc/
o	Generic page for PCs (in English):
	Old: https://www.opentrust.com/en/certification-policy
	New: https://www.opentrust.com/security-policies/
o	RCA CP and CPS:
	Old: https://www.opentrust.com/ressources/publications/OpenTrust_DMS_RCA%20Program_OpenTrust_CP%20v%201.2s.pdf
	New: https://www.opentrust.com/wp-content/uploads/2015/03/OpenTrust_DMS_RCA-Program_OpenTrust_CP-v-1.2s2.pdf
o	EV CP and CPS:
	Old: https://www.opentrust.com/images/stories/OpenTrust_DMS_EV_SSL_CA_Certification_Practice_Statement_2014_12_18s.pdf
	New: https://www.opentrust.com/wp-content/uploads/2015/03/OpenTrust_DMS_EV_SSL_CA_Certification_Practice_Statement_2014_12_18s.pdf
o	RGS CP and CPS:
	Old: https://www.opentrust.com/ressources/publications/OpenTrust_DMS_PC%20Certificats%20OpenTrust%20SSL%20RGS%20et%20ETSI%20V1.4s.pdf
	New: https://www.opentrust.com/wp-content/uploads/2015/04/OpenTrust_DMS_PC-Certificats-OpenTrust-SSL-RGS-et-ETSI-V1.4s.pdf.
-	OID to be registered for each root CA certificate : as Erwann wrote in comment #29, you may associate different OIDs to one root CA certificate. Here is the list of OIDs to associate to each Root CA (cf. CP and CPS listing these OIDs) in order for you to update EV Policy OID(s) items:
o	Certplus Root CA G1: 1.3.6.1.4.1.22234.2.5.2.3.1 ; 1.3.6.1.4.1.22234.2.14.3.21 ; 1.3.6.1.4.1.22234.2.5.3.12; 1.3.6.1.4.1.22234.2.14.3.23
o	Certplus Root CA G2: 1.3.6.1.4.1.22234.2.5.2.3.1 ; 1.3.6.1.4.1.22234.2.14.3.22 ; 1.3.6.1.4.1.22234.2.5.3.12; 1.3.6.1.4.1.22234.2.14.3.24
o	OpenTrust Root CA G1: 1.3.6.1.4.1.22234.2.5.2.3.1 ; 1.3.6.1.4.1.22234.2.14.3.11 ; 1.3.6.1.4.1.22234.2.5.3.12; 1.3.6.1.4.1.22234.2.14.3.14
o	OpenTrust Root CA G2: 1.3.6.1.4.1.22234.2.5.2.3.1 ; 1.3.6.1.4.1.22234.2.14.3.12 ; 1.3.6.1.4.1.22234.2.5.3.12; 1.3.6.1.4.1.22234.2.14.3.15
o	OpenTrust Root CA G3: 1.3.6.1.4.1.22234.2.5.2.3.1 ; 1.3.6.1.4.1.22234.2.14.3.13 ; 1.3.6.1.4.1.22234.2.5.3.12; 1.3.6.1.4.1.22234.2.14.3.16
-	For last item for each root CA certificate called “Link to Publicly Disclosed and Audited subordinate CA Certificates”, what do you expect from us (section 10)?

Comment 31

[Kathleen Wilson]

(In reply to Remi Pifaut from comment #30)
> Following comment #25 and its attached document
> (https://bugzilla.mozilla.org/attachment.cgi?id=8589380), we have some
> comments/answers regarding the content:
> -	In the document there is an item with “Root store included in” for which
> you are waiting for answer: what does this item mean? What do you expect
> from us?

Which other root stores has each root been include in?
Choices: Apple, Google, Microsoft, Opera


> -	Regarding all items in relation with the audits, please review audit
> report that I sent in the comment #28
> (https://bugzilla.mozilla.org/attachment.cgi?id=8590352).
...
> -	OID to be registered for each root CA certificate : as Erwann wrote in
> comment #29, you may associate different OIDs to one root CA certificate.
> Here is the list of OIDs to associate to each Root CA (cf. CP and CPS
> listing these OIDs) in order for you to update EV Policy OID(s) items:
> o	Certplus Root CA G1: 1.3.6.1.4.1.22234.2.5.2.3.1 ;
> 1.3.6.1.4.1.22234.2.14.3.21 ; 1.3.6.1.4.1.22234.2.5.3.12;
> 1.3.6.1.4.1.22234.2.14.3.23
> o	Certplus Root CA G2: 1.3.6.1.4.1.22234.2.5.2.3.1 ;
> 1.3.6.1.4.1.22234.2.14.3.22 ; 1.3.6.1.4.1.22234.2.5.3.12;
> 1.3.6.1.4.1.22234.2.14.3.24
> o	OpenTrust Root CA G1: 1.3.6.1.4.1.22234.2.5.2.3.1 ;
> 1.3.6.1.4.1.22234.2.14.3.11 ; 1.3.6.1.4.1.22234.2.5.3.12;
> 1.3.6.1.4.1.22234.2.14.3.14
> o	OpenTrust Root CA G2: 1.3.6.1.4.1.22234.2.5.2.3.1 ;
> 1.3.6.1.4.1.22234.2.14.3.12 ; 1.3.6.1.4.1.22234.2.5.3.12;
> 1.3.6.1.4.1.22234.2.14.3.15
> o	OpenTrust Root CA G3: 1.3.6.1.4.1.22234.2.5.2.3.1 ;
> 1.3.6.1.4.1.22234.2.14.3.13 ; 1.3.6.1.4.1.22234.2.5.3.12;
> 1.3.6.1.4.1.22234.2.14.3.16


In https://bugzilla.mozilla.org/attachment.cgi?id=8590352 I only see ETSI TS 102 042 EVCP referenced for 
KEYNECTIS Extended Validation CA 1.3.6.1.4.1.22234.2.5.2.3.1
and
Keynectis SSL RGS 1.3.6.1.4.1.22234.2.5.3.12

Please explain how this relates to your list of 4 EV Policy OIDs for each of the 5 roots in this request.


> -	For last item for each root CA certificate called “Link to Publicly
> Disclosed and Audited subordinate CA Certificates”, what do you expect from
> us (section 10)?


See item #4 of
https://wiki.mozilla.org/CA:Information_checklist#CA_Hierarchy_information_for_each_root_certificate

Comment 32

[Kathleen Wilson]

Also, please fix all of the errors noted by http://certificate.revocationcheck.com/
for the test website that was provided for each root.

Comment 33

[Remi Pifaut]

(In reply to Kathleen Wilson from comment #25)
> Created attachment 8589380 [details]
> 1025095-CAInformation.pdf
> 
> I've entered the data for this request into SalesForce.
> 
> Please review the attached document to ensure it is correct and complete,
> and provide corrections by posting comments in this bug.

Regarding your item "EV Tested", here are the results of the online run checker tool for each root CA to include in Mozilla trust program:

// CN=Certplus Root CA G1,O=Certplus,C=FR
"1.3.6.1.4.1.22234.2.5.2.3.1",
"Test Certplus G1",
SEC_OID_UNKNOWN,
{ 0x15, 0x2A, 0x40, 0x2B, 0xFC, 0xDF, 0x2C, 0xD5, 0x48, 0x05, 0x4D, 
  0x22, 0x75, 0xB3, 0x9C, 0x7F, 0xCA, 0x3E, 0xC0, 0x97, 0x80, 0x78, 
  0xB0, 0xF0, 0xEA, 0x76, 0xE5, 0x61, 0xA6, 0xC7, 0x43, 0x3E },
"MD4xCzAJBgNVBAYTAkZSMREwDwYDVQQKDAhDZXJ0cGx1czEcMBoGA1UEAwwTQ2Vy"
"dHBsdXMgUm9vdCBDQSBHMQ==",
"ESBVg+QtPlRWhS2DN7cs3EYR",
Success!


// CN=Certplus Root CA G2,O=Certplus,C=FR
"1.3.6.1.4.1.22234.2.5.2.3.1",
"Test Certplus G2",
SEC_OID_UNKNOWN,
{ 0x6C, 0xC0, 0x50, 0x41, 0xE6, 0x44, 0x5E, 0x74, 0x69, 0x6C, 0x4C, 
  0xFB, 0xC9, 0xF8, 0x0F, 0x54, 0x3B, 0x7E, 0xAB, 0xBB, 0x44, 0xB4, 
  0xCE, 0x6F, 0x78, 0x7C, 0x6A, 0x99, 0x71, 0xC4, 0x2F, 0x17 },
"MD4xCzAJBgNVBAYTAkZSMREwDwYDVQQKDAhDZXJ0cGx1czEcMBoGA1UEAwwTQ2Vy"
"dHBsdXMgUm9vdCBDQSBHMg==",
"ESDZkc6uo+jF5//pAq/Pc7xV",
Success!


// CN=OpenTrust Root CA G1,O=OpenTrust,C=FR
"1.3.6.1.4.1.22234.2.5.2.3.1",
"Test Opentrust G1",
SEC_OID_UNKNOWN,
{ 0x56, 0xC7, 0x71, 0x28, 0xD9, 0x8C, 0x18, 0xD9, 0x1B, 0x4C, 0xFD, 
  0xFF, 0xBC, 0x25, 0xEE, 0x91, 0x03, 0xD4, 0x75, 0x8E, 0xA2, 0xAB, 
  0xAD, 0x82, 0x6A, 0x90, 0xF3, 0x45, 0x7D, 0x46, 0x0E, 0xB4 },
"MEAxCzAJBgNVBAYTAkZSMRIwEAYDVQQKDAlPcGVuVHJ1c3QxHTAbBgNVBAMMFE9w"
"ZW5UcnVzdCBSb290IENBIEcx",
"ESCzkFU5fX82bWTCp59rY45n",
Success!


// CN=OpenTrust Root CA G2,O=OpenTrust,C=FR
"1.3.6.1.4.1.22234.2.5.2.3.1",
"Test Opentrust G2",
SEC_OID_UNKNOWN,
{ 0x27, 0x99, 0x58, 0x29, 0xFE, 0x6A, 0x75, 0x15, 0xC1, 0xBF, 0xE8, 
  0x48, 0xF9, 0xC4, 0x76, 0x1D, 0xB1, 0x6C, 0x22, 0x59, 0x29, 0x25, 
  0x7B, 0xF4, 0x0D, 0x08, 0x94, 0xF2, 0x9E, 0xA8, 0xBA, 0xF2 },
"MEAxCzAJBgNVBAYTAkZSMRIwEAYDVQQKDAlPcGVuVHJ1c3QxHTAbBgNVBAMMFE9w"
"ZW5UcnVzdCBSb290IENBIEcy",
"ESChaRu/vbm9UpaPI+hIvyYR",
Success!


// CN=OpenTrust Root CA G3,O=OpenTrust,C=FR
"1.3.6.1.4.1.22234.2.5.2.3.1",
"Test Opentrust G3",
SEC_OID_UNKNOWN,
{ 0xB7, 0xC3, 0x62, 0x31, 0x70, 0x6E, 0x81, 0x07, 0x8C, 0x36, 0x7C, 
  0xB8, 0x96, 0x19, 0x8F, 0x1E, 0x32, 0x08, 0xDD, 0x92, 0x69, 0x49, 
  0xDD, 0x8F, 0x57, 0x09, 0xA4, 0x10, 0xF7, 0x5B, 0x62, 0x92 },
"MEAxCzAJBgNVBAYTAkZSMRIwEAYDVQQKDAlPcGVuVHJ1c3QxHTAbBgNVBAMMFE9w"
"ZW5UcnVzdCBSb290IENBIEcz",
"ESDm+Ez8JLC+BUCs2oMbNGA/",
Success!

Comment 34

[Remi Pifaut]

(In reply to Kathleen Wilson from comment #31)
> (In reply to Remi Pifaut from comment #30)
> > Following comment #25 and its attached document
> > (https://bugzilla.mozilla.org/attachment.cgi?id=8589380), we have some
> > comments/answers regarding the content:
> > -	In the document there is an item with “Root store included in” for which
> > you are waiting for answer: what does this item mean? What do you expect
> > from us?
> 
> Which other root stores has each root been include in?
> Choices: Apple, Google, Microsoft, Opera
> 
> 
> > -	Regarding all items in relation with the audits, please review audit
> > report that I sent in the comment #28
> > (https://bugzilla.mozilla.org/attachment.cgi?id=8590352).
> ...
> > -	OID to be registered for each root CA certificate : as Erwann wrote in
> > comment #29, you may associate different OIDs to one root CA certificate.
> > Here is the list of OIDs to associate to each Root CA (cf. CP and CPS
> > listing these OIDs) in order for you to update EV Policy OID(s) items:
> > o	Certplus Root CA G1: 1.3.6.1.4.1.22234.2.5.2.3.1 ;
> > 1.3.6.1.4.1.22234.2.14.3.21 ; 1.3.6.1.4.1.22234.2.5.3.12;
> > 1.3.6.1.4.1.22234.2.14.3.23
> > o	Certplus Root CA G2: 1.3.6.1.4.1.22234.2.5.2.3.1 ;
> > 1.3.6.1.4.1.22234.2.14.3.22 ; 1.3.6.1.4.1.22234.2.5.3.12;
> > 1.3.6.1.4.1.22234.2.14.3.24
> > o	OpenTrust Root CA G1: 1.3.6.1.4.1.22234.2.5.2.3.1 ;
> > 1.3.6.1.4.1.22234.2.14.3.11 ; 1.3.6.1.4.1.22234.2.5.3.12;
> > 1.3.6.1.4.1.22234.2.14.3.14
> > o	OpenTrust Root CA G2: 1.3.6.1.4.1.22234.2.5.2.3.1 ;
> > 1.3.6.1.4.1.22234.2.14.3.12 ; 1.3.6.1.4.1.22234.2.5.3.12;
> > 1.3.6.1.4.1.22234.2.14.3.15
> > o	OpenTrust Root CA G3: 1.3.6.1.4.1.22234.2.5.2.3.1 ;
> > 1.3.6.1.4.1.22234.2.14.3.13 ; 1.3.6.1.4.1.22234.2.5.3.12;
> > 1.3.6.1.4.1.22234.2.14.3.16
> 
> 
> In https://bugzilla.mozilla.org/attachment.cgi?id=8590352 I only see ETSI TS
> 102 042 EVCP referenced for 
> KEYNECTIS Extended Validation CA 1.3.6.1.4.1.22234.2.5.2.3.1
> and
> Keynectis SSL RGS 1.3.6.1.4.1.22234.2.5.3.12
> 
> Please explain how this relates to your list of 4 EV Policy OIDs for each of
> the 5 roots in this request.
> 
> 
> > -	For last item for each root CA certificate called “Link to Publicly
> > Disclosed and Audited subordinate CA Certificates”, what do you expect from
> > us (section 10)?
> 
> 
> See item #4 of
> https://wiki.mozilla.org/CA:
> Information_checklist#CA_Hierarchy_information_for_each_root_certificate


> Which other root stores has each root been include in?
> Choices: Apple, Google, Microsoft, Opera

We have been included in Microsoft root store. This has been confirmed by Jody. 5 new root CAs will be available in Microsoft June release, planned on the 23rd.
For Apple it is in progress (waiting for an answer from Apple since April 2015 when we applied with all required information).
And Google (Ryan) waits for Mozilla process to be finished.

> Please explain how this relates to your list of 4 EV Policy OIDs for each of
> the 5 roots in this request.

OIDs that are present in the letter from LSTI are the existing ones (1.3.6.1.4.1.22234.2.5.2.3.1 and 1.3.6.1.4.1.22234.2.5.3.12): these OIDs are currently used in production and therefore are effectively audited. Other OIDS (list of 4 EV policy OID for each root Ca) are "reserved" for future use and therefore not yet in production and cannot be audited as such. They will be the ones to be used when we set up into production the root CAs and online associated CAs to issue final EV SSL certs. That is why they need to be registered with the root CAs in order to be effectively trusted when we issue our first  EV certs. Nevertheless, procedures, requirements, way to manage SSL certificates will remain the same whatever the OID is used.

Comment 35

[Kathleen Wilson]

Please see https://mxr.mozilla.org/mozilla-central/source/security/certverifier/ExtendedValidation.cpp
and note that all of the other CAs have managed to work within the parameters of Firefox recognizing one or two EV OIDs per root. If we open this up for one CA, then we'll have to open it up for all the CAs, and it will turn into a problem for us.


(In reply to Remi Pifaut from comment #34)
> > Please explain how this relates to your list of 4 EV Policy OIDs for each of
> > the 5 roots in this request.
> 
> OIDs that are present in the letter from LSTI are the existing ones
> (1.3.6.1.4.1.22234.2.5.2.3.1 and 1.3.6.1.4.1.22234.2.5.3.12): these OIDs are
> currently used in production and therefore are effectively audited. Other
> OIDS (list of 4 EV policy OID for each root Ca) are "reserved" for future
> use and therefore not yet in production and cannot be audited as such. They
> will be the ones to be used when we set up into production the root CAs and
> online associated CAs to issue final EV SSL certs. That is why they need to
> be registered with the root CAs in order to be effectively trusted when we
> issue our first  EV certs. Nevertheless, procedures, requirements, way to
> manage SSL certificates will remain the same whatever the OID is used.

According to this, then these two OIDs won't be used in the new roots in production:
1.3.6.1.4.1.22234.2.5.2.3.1
1.3.6.1.4.1.22234.2.5.3.12

The other OIDs "will be the ones to be used when we set up into production the root CAs and online associated CAs to issue final EV SSL certs."

Certplus Root CA G1: 
1.3.6.1.4.1.22234.2.5.2.3.1 -- old
1.3.6.1.4.1.22234.2.14.3.21
1.3.6.1.4.1.22234.2.5.3.12 -- old
1.3.6.1.4.1.22234.2.14.3.23

Certplus Root CA G2: 
1.3.6.1.4.1.22234.2.5.2.3.1 -- old
1.3.6.1.4.1.22234.2.14.3.22
1.3.6.1.4.1.22234.2.5.3.12 -- old
1.3.6.1.4.1.22234.2.14.3.24

OpenTrust Root CA G1: 
1.3.6.1.4.1.22234.2.5.2.3.1 -- old
1.3.6.1.4.1.22234.2.14.3.11
1.3.6.1.4.1.22234.2.5.3.12 -- old
1.3.6.1.4.1.22234.2.14.3.14

OpenTrust Root CA G2: 
1.3.6.1.4.1.22234.2.5.2.3.1 -- old
1.3.6.1.4.1.22234.2.14.3.12
1.3.6.1.4.1.22234.2.5.3.12 -- old
1.3.6.1.4.1.22234.2.14.3.15

OpenTrust Root CA G3: 
1.3.6.1.4.1.22234.2.5.2.3.1 -- old
1.3.6.1.4.1.22234.2.14.3.13
1.3.6.1.4.1.22234.2.5.3.12 -- old
1.3.6.1.4.1.22234.2.14.3.16


So, then the EV OIDs that you intend to use with the new roots are as follows.

Certplus Root CA G1: 
1.3.6.1.4.1.22234.2.14.3.21
1.3.6.1.4.1.22234.2.14.3.23

Certplus Root CA G2: 
1.3.6.1.4.1.22234.2.14.3.22
1.3.6.1.4.1.22234.2.14.3.24

OpenTrust Root CA G1: 
1.3.6.1.4.1.22234.2.14.3.11
1.3.6.1.4.1.22234.2.14.3.14

OpenTrust Root CA G2: 
1.3.6.1.4.1.22234.2.14.3.12
1.3.6.1.4.1.22234.2.14.3.15

OpenTrust Root CA G3: 
1.3.6.1.4.1.22234.2.14.3.13
1.3.6.1.4.1.22234.2.14.3.16

That seems reasonable to me, so please provide a test website corresponding to each of these EV OIDs. And also provide the successful output for each of those websites using https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version

Comment 36

[Remi Pifaut]

(In reply to Kathleen Wilson from comment #31)
> 
> See item #4 of
> https://wiki.mozilla.org/CA:
> Information_checklist#CA_Hierarchy_information_for_each_root_certificate

We have added in our web site, information regarding sub CA attached to the 5 root CAs to be included in your program.
You will find information on the url https://www.opentrust.com/security-policies/?lang=en in the next paragraphs:
- « OPENTRUST ROOT CAS »
- « NEW CERTPLUS ROOT CAS » 
They contain the sub CAs certificates that have been issued by each root certificate.

Comment 37

[Remi Pifaut]

This will allow to complete your "00000033" case document with information regarding public information and also regarding audits (see comment 28 for audit report).

Comment 38

[Remi Pifaut]

This will allow to complete your "00000033" case document with information regarding public information and also regarding audits (see comment 28 for audit report).

Comment 39

[Remi Pifaut]

(In reply to Kathleen Wilson from comment #35)
> Please see
> https://mxr.mozilla.org/mozilla-central/source/security/certverifier/
> ExtendedValidation.cpp
> and note that all of the other CAs have managed to work within the
> parameters of Firefox recognizing one or two EV OIDs per root. If we open
> this up for one CA, then we'll have to open it up for all the CAs, and it
> will turn into a problem for us.
> 
> 
> (In reply to Remi Pifaut from comment #34)
> > > Please explain how this relates to your list of 4 EV Policy OIDs for each of
> > > the 5 roots in this request.
> > 
> > OIDs that are present in the letter from LSTI are the existing ones
> > (1.3.6.1.4.1.22234.2.5.2.3.1 and 1.3.6.1.4.1.22234.2.5.3.12): these OIDs are
> > currently used in production and therefore are effectively audited. Other
> > OIDS (list of 4 EV policy OID for each root Ca) are "reserved" for future
> > use and therefore not yet in production and cannot be audited as such. They
> > will be the ones to be used when we set up into production the root CAs and
> > online associated CAs to issue final EV SSL certs. That is why they need to
> > be registered with the root CAs in order to be effectively trusted when we
> > issue our first  EV certs. Nevertheless, procedures, requirements, way to
> > manage SSL certificates will remain the same whatever the OID is used.
> 
> According to this, then these two OIDs won't be used in the new roots in
> production:
> 1.3.6.1.4.1.22234.2.5.2.3.1
> 1.3.6.1.4.1.22234.2.5.3.12
> 
> The other OIDs "will be the ones to be used when we set up into production
> the root CAs and online associated CAs to issue final EV SSL certs."
> 
> Certplus Root CA G1: 
> 1.3.6.1.4.1.22234.2.5.2.3.1 -- old
> 1.3.6.1.4.1.22234.2.14.3.21
> 1.3.6.1.4.1.22234.2.5.3.12 -- old
> 1.3.6.1.4.1.22234.2.14.3.23
> 
> Certplus Root CA G2: 
> 1.3.6.1.4.1.22234.2.5.2.3.1 -- old
> 1.3.6.1.4.1.22234.2.14.3.22
> 1.3.6.1.4.1.22234.2.5.3.12 -- old
> 1.3.6.1.4.1.22234.2.14.3.24
> 
> OpenTrust Root CA G1: 
> 1.3.6.1.4.1.22234.2.5.2.3.1 -- old
> 1.3.6.1.4.1.22234.2.14.3.11
> 1.3.6.1.4.1.22234.2.5.3.12 -- old
> 1.3.6.1.4.1.22234.2.14.3.14
> 
> OpenTrust Root CA G2: 
> 1.3.6.1.4.1.22234.2.5.2.3.1 -- old
> 1.3.6.1.4.1.22234.2.14.3.12
> 1.3.6.1.4.1.22234.2.5.3.12 -- old
> 1.3.6.1.4.1.22234.2.14.3.15
> 
> OpenTrust Root CA G3: 
> 1.3.6.1.4.1.22234.2.5.2.3.1 -- old
> 1.3.6.1.4.1.22234.2.14.3.13
> 1.3.6.1.4.1.22234.2.5.3.12 -- old
> 1.3.6.1.4.1.22234.2.14.3.16
> 
> 
> So, then the EV OIDs that you intend to use with the new roots are as
> follows.
> 
> Certplus Root CA G1: 
> 1.3.6.1.4.1.22234.2.14.3.21
> 1.3.6.1.4.1.22234.2.14.3.23
> 
> Certplus Root CA G2: 
> 1.3.6.1.4.1.22234.2.14.3.22
> 1.3.6.1.4.1.22234.2.14.3.24
> 
> OpenTrust Root CA G1: 
> 1.3.6.1.4.1.22234.2.14.3.11
> 1.3.6.1.4.1.22234.2.14.3.14
> 
> OpenTrust Root CA G2: 
> 1.3.6.1.4.1.22234.2.14.3.12
> 1.3.6.1.4.1.22234.2.14.3.15
> 
> OpenTrust Root CA G3: 
> 1.3.6.1.4.1.22234.2.14.3.13
> 1.3.6.1.4.1.22234.2.14.3.16
> 
> That seems reasonable to me, so please provide a test website corresponding
> to each of these EV OIDs. And also provide the successful output for each of
> those websites using https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version

Regarding your comment #35, here is what we are going to do:
- use only one OID for OpenTrust Root CA G1, G2 and G3. This OID will be 1.3.6.1.4.1.22234.2.14.3.11 (same OID for the three root CAs)
- use one OID for Certplus Root CA G1. This OID will be 1.3.6.1.4.1.22234.3.5.3.1
- use one OID for Certplus Root CA G1. This OID will be 1.3.6.1.4.1.22234.3.5.3.2

I will let you know when we have new test certificates available for you and will provide results of tests based on https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version

Comment 40

[Remi Pifaut]

(In reply to Remi Pifaut from comment #39)
> (In reply to Kathleen Wilson from comment #35)
> > Please see
> > https://mxr.mozilla.org/mozilla-central/source/security/certverifier/
> > ExtendedValidation.cpp
> > and note that all of the other CAs have managed to work within the
> > parameters of Firefox recognizing one or two EV OIDs per root. If we open
> > this up for one CA, then we'll have to open it up for all the CAs, and it
> > will turn into a problem for us.
> > 
> > 
> > (In reply to Remi Pifaut from comment #34)
> > > > Please explain how this relates to your list of 4 EV Policy OIDs for each of
> > > > the 5 roots in this request.
> > > 
> > > OIDs that are present in the letter from LSTI are the existing ones
> > > (1.3.6.1.4.1.22234.2.5.2.3.1 and 1.3.6.1.4.1.22234.2.5.3.12): these OIDs are
> > > currently used in production and therefore are effectively audited. Other
> > > OIDS (list of 4 EV policy OID for each root Ca) are "reserved" for future
> > > use and therefore not yet in production and cannot be audited as such. They
> > > will be the ones to be used when we set up into production the root CAs and
> > > online associated CAs to issue final EV SSL certs. That is why they need to
> > > be registered with the root CAs in order to be effectively trusted when we
> > > issue our first  EV certs. Nevertheless, procedures, requirements, way to
> > > manage SSL certificates will remain the same whatever the OID is used.
> > 
> > According to this, then these two OIDs won't be used in the new roots in
> > production:
> > 1.3.6.1.4.1.22234.2.5.2.3.1
> > 1.3.6.1.4.1.22234.2.5.3.12
> > 
> > The other OIDs "will be the ones to be used when we set up into production
> > the root CAs and online associated CAs to issue final EV SSL certs."
> > 
> > Certplus Root CA G1: 
> > 1.3.6.1.4.1.22234.2.5.2.3.1 -- old
> > 1.3.6.1.4.1.22234.2.14.3.21
> > 1.3.6.1.4.1.22234.2.5.3.12 -- old
> > 1.3.6.1.4.1.22234.2.14.3.23
> > 
> > Certplus Root CA G2: 
> > 1.3.6.1.4.1.22234.2.5.2.3.1 -- old
> > 1.3.6.1.4.1.22234.2.14.3.22
> > 1.3.6.1.4.1.22234.2.5.3.12 -- old
> > 1.3.6.1.4.1.22234.2.14.3.24
> > 
> > OpenTrust Root CA G1: 
> > 1.3.6.1.4.1.22234.2.5.2.3.1 -- old
> > 1.3.6.1.4.1.22234.2.14.3.11
> > 1.3.6.1.4.1.22234.2.5.3.12 -- old
> > 1.3.6.1.4.1.22234.2.14.3.14
> > 
> > OpenTrust Root CA G2: 
> > 1.3.6.1.4.1.22234.2.5.2.3.1 -- old
> > 1.3.6.1.4.1.22234.2.14.3.12
> > 1.3.6.1.4.1.22234.2.5.3.12 -- old
> > 1.3.6.1.4.1.22234.2.14.3.15
> > 
> > OpenTrust Root CA G3: 
> > 1.3.6.1.4.1.22234.2.5.2.3.1 -- old
> > 1.3.6.1.4.1.22234.2.14.3.13
> > 1.3.6.1.4.1.22234.2.5.3.12 -- old
> > 1.3.6.1.4.1.22234.2.14.3.16
> > 
> > 
> > So, then the EV OIDs that you intend to use with the new roots are as
> > follows.
> > 
> > Certplus Root CA G1: 
> > 1.3.6.1.4.1.22234.2.14.3.21
> > 1.3.6.1.4.1.22234.2.14.3.23
> > 
> > Certplus Root CA G2: 
> > 1.3.6.1.4.1.22234.2.14.3.22
> > 1.3.6.1.4.1.22234.2.14.3.24
> > 
> > OpenTrust Root CA G1: 
> > 1.3.6.1.4.1.22234.2.14.3.11
> > 1.3.6.1.4.1.22234.2.14.3.14
> > 
> > OpenTrust Root CA G2: 
> > 1.3.6.1.4.1.22234.2.14.3.12
> > 1.3.6.1.4.1.22234.2.14.3.15
> > 
> > OpenTrust Root CA G3: 
> > 1.3.6.1.4.1.22234.2.14.3.13
> > 1.3.6.1.4.1.22234.2.14.3.16
> > 
> > That seems reasonable to me, so please provide a test website corresponding
> > to each of these EV OIDs. And also provide the successful output for each of
> > those websites using https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version
> 
> Regarding your comment #35, here is what we are going to do:
> - use only one OID for OpenTrust Root CA G1, G2 and G3. This OID will be
> 1.3.6.1.4.1.22234.2.14.3.11 (same OID for the three root CAs)
> - use one OID for Certplus Root CA G1. This OID will be
> 1.3.6.1.4.1.22234.3.5.3.1
> - use one OID for Certplus Root CA G1. This OID will be
> 1.3.6.1.4.1.22234.3.5.3.2
> 
> I will let you know when we have new test certificates available for you and
> will provide results of tests based on
> https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version

Sorry, there was an error for Certplus Root CA G2. I give you below the update of OIDs:
- use only one OID for OpenTrust Root CA G1, G2 and G3. This OID will be 1.3.6.1.4.1.22234.2.14.3.11 (same OID for the three root CAs)
- use one OID for Certplus Root CA G1. This OID will be 1.3.6.1.4.1.22234.3.5.3.1
- use one OID for Certplus Root CA G2. This OID will be 1.3.6.1.4.1.22234.3.5.3.2

Comment 41

[Kathleen Wilson]

(In reply to Remi Pifaut from comment #40)
> > I will let you know when we have new test certificates available for you and
> > will provide results of tests based on
> > https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version
> 
> Sorry, there was an error for Certplus Root CA G2. I give you below the
> update of OIDs:
> - use only one OID for OpenTrust Root CA G1, G2 and G3. This OID will be
> 1.3.6.1.4.1.22234.2.14.3.11 (same OID for the three root CAs)
> - use one OID for Certplus Root CA G1. This OID will be
> 1.3.6.1.4.1.22234.3.5.3.1
> - use one OID for Certplus Root CA G2. This OID will be
> 1.3.6.1.4.1.22234.3.5.3.2

OK.

Please update this bug to provide the corresponding test URLs (when the EV Test passes for each of them).

Comment 42

[Remi Pifaut]

(In reply to Kathleen Wilson from comment #41)
> (In reply to Remi Pifaut from comment #40)
> > > I will let you know when we have new test certificates available for you and
> > > will provide results of tests based on
> > > https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version
> > 
> > Sorry, there was an error for Certplus Root CA G2. I give you below the
> > update of OIDs:
> > - use only one OID for OpenTrust Root CA G1, G2 and G3. This OID will be
> > 1.3.6.1.4.1.22234.2.14.3.11 (same OID for the three root CAs)
> > - use one OID for Certplus Root CA G1. This OID will be
> > 1.3.6.1.4.1.22234.3.5.3.1
> > - use one OID for Certplus Root CA G2. This OID will be
> > 1.3.6.1.4.1.22234.3.5.3.2
> 
> OK.
> 
> Please update this bug to provide the corresponding test URLs (when the EV
> Test passes for each of them).

Regarding the EV Tests, here are the successful results of the online EV checker tool for each root CA to include in Mozilla trust program:

certplusrootcag1-test.opentrust.com
// CN=Certplus Root CA G1,O=Certplus,C=FR
"1.3.6.1.4.1.22234.3.5.3.1",
"certplusrootcag1 test opentrust",
SEC_OID_UNKNOWN,
{ 0x15, 0x2A, 0x40, 0x2B, 0xFC, 0xDF, 0x2C, 0xD5, 0x48, 0x05, 0x4D, 
  0x22, 0x75, 0xB3, 0x9C, 0x7F, 0xCA, 0x3E, 0xC0, 0x97, 0x80, 0x78, 
  0xB0, 0xF0, 0xEA, 0x76, 0xE5, 0x61, 0xA6, 0xC7, 0x43, 0x3E },
"MD4xCzAJBgNVBAYTAkZSMREwDwYDVQQKDAhDZXJ0cGx1czEcMBoGA1UEAwwTQ2Vy"
"dHBsdXMgUm9vdCBDQSBHMQ==",
"ESBVg+QtPlRWhS2DN7cs3EYR",
Success!

certplusrootcag2-test.opentrust.com
// CN=Certplus Root CA G2,O=Certplus,C=FR
"1.3.6.1.4.1.22234.3.5.3.2",
"certplusrootcag2 test opentrust",
SEC_OID_UNKNOWN,
{ 0x6C, 0xC0, 0x50, 0x41, 0xE6, 0x44, 0x5E, 0x74, 0x69, 0x6C, 0x4C, 
  0xFB, 0xC9, 0xF8, 0x0F, 0x54, 0x3B, 0x7E, 0xAB, 0xBB, 0x44, 0xB4, 
  0xCE, 0x6F, 0x78, 0x7C, 0x6A, 0x99, 0x71, 0xC4, 0x2F, 0x17 },
"MD4xCzAJBgNVBAYTAkZSMREwDwYDVQQKDAhDZXJ0cGx1czEcMBoGA1UEAwwTQ2Vy"
"dHBsdXMgUm9vdCBDQSBHMg==",
"ESDZkc6uo+jF5//pAq/Pc7xV",
Success!

opentrustrootcag1-test.opentrust.com
// CN=OpenTrust Root CA G1,O=OpenTrust,C=FR
"1.3.6.1.4.1.22234.2.14.3.11",
"opentrustrootcag1 test opentrust",
SEC_OID_UNKNOWN,
{ 0x56, 0xC7, 0x71, 0x28, 0xD9, 0x8C, 0x18, 0xD9, 0x1B, 0x4C, 0xFD, 
  0xFF, 0xBC, 0x25, 0xEE, 0x91, 0x03, 0xD4, 0x75, 0x8E, 0xA2, 0xAB, 
  0xAD, 0x82, 0x6A, 0x90, 0xF3, 0x45, 0x7D, 0x46, 0x0E, 0xB4 },
"MEAxCzAJBgNVBAYTAkZSMRIwEAYDVQQKDAlPcGVuVHJ1c3QxHTAbBgNVBAMMFE9w"
"ZW5UcnVzdCBSb290IENBIEcx",
"ESCzkFU5fX82bWTCp59rY45n",
Success!


opentrustrootcag2-test.opentrust.com
// CN=OpenTrust Root CA G2,O=OpenTrust,C=FR
"1.3.6.1.4.1.22234.2.14.3.11",
"opentrustrootcag2 test opentrust",
SEC_OID_UNKNOWN,
{ 0x27, 0x99, 0x58, 0x29, 0xFE, 0x6A, 0x75, 0x15, 0xC1, 0xBF, 0xE8, 
  0x48, 0xF9, 0xC4, 0x76, 0x1D, 0xB1, 0x6C, 0x22, 0x59, 0x29, 0x25, 
  0x7B, 0xF4, 0x0D, 0x08, 0x94, 0xF2, 0x9E, 0xA8, 0xBA, 0xF2 },
"MEAxCzAJBgNVBAYTAkZSMRIwEAYDVQQKDAlPcGVuVHJ1c3QxHTAbBgNVBAMMFE9w"
"ZW5UcnVzdCBSb290IENBIEcy",
"ESChaRu/vbm9UpaPI+hIvyYR",
Success!

opentrustrootcag3-test.opentrust.com
// CN=OpenTrust Root CA G3,O=OpenTrust,C=FR
"1.3.6.1.4.1.22234.2.14.3.11",
"opentrustrootcag3 test opentrust",
SEC_OID_UNKNOWN,
{ 0xB7, 0xC3, 0x62, 0x31, 0x70, 0x6E, 0x81, 0x07, 0x8C, 0x36, 0x7C, 
  0xB8, 0x96, 0x19, 0x8F, 0x1E, 0x32, 0x08, 0xDD, 0x92, 0x69, 0x49, 
  0xDD, 0x8F, 0x57, 0x09, 0xA4, 0x10, 0xF7, 0x5B, 0x62, 0x92 },
"MEAxCzAJBgNVBAYTAkZSMRIwEAYDVQQKDAlPcGVuVHJ1c3QxHTAbBgNVBAMMFE9w"
"ZW5UcnVzdCBSb290IENBIEcz",
"ESDm+Ez8JLC+BUCs2oMbNGA/",
Success!

Comment 43

[Kathleen Wilson]

Attachment: 1025095-CAInformation-Complete.pdf

Comment 44

[Kathleen Wilson]

This request has been added to the queue for public discussion.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
I will update this bug when I start the discussion.

Comment 45

[Kathleen Wilson]

Attachment: 1025095-CAInformation-Complete.pdf

Updated URLs from opentrust.com to opentrustdtm.com

Comment 46

[Kathleen Wilson]

I am now opening the public discussion period for this request from DocuSign (OpenTrust/Keynectis/Certplus) to include the Certplus Root CA G1, Certplus Root CA G2, OpenTrust Root CA G1, OpenTrust Root CA G2, and OpenTrust Root CA G3 root certificates, turn on the Websites and Email trust bits for all of them, and enable EV treatment for all of them. 

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy forum.
https://www.mozilla.org/en-US/about/forums/#dev-security-policy

The discussion thread is called "DocuSign (OpenTrust/Keynectis/Certplus) root renewal request".

Please actively review, respond, and contribute to the discussion.

A representative of this CA must promptly respond directly in the discussion thread to all questions that are posted.

Comment 47

[Kathleen Wilson]

The public comment period for this request is now over.

This request has been evaluated as per Mozilla’s CA Certificate Inclusion Policy at
https://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/

Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

Inclusion Policy Section 4 [Technical].
I am not aware of instances where DocuSign has knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug.

Inclusion Policy Section 6 [Relevance and Policy].
DocuSign appears to provide a service relevant to Mozilla users. Previously the company was known as Keynectis, with the Certplus and OpenTrust brands, issuing certs to public or private corporations, associations. Ownership changed November 3, 2015, from Keynectis to DocuSign France, which was acquired by DocuSign Inc. The root keys remained at the same physical location operated by the same team. During the transfer of activity, all past agreements/contracts and so on remain available. People linked to this activity were also transferred to the new company. 


Root Certificate Name: Certplus Root CA G1
O From Issuer Field: Certplus
Trust Bits: Email; Websites
EV Policy OID(s): 1.3.6.1.4.1.22234.3.5.3.1
Root Certificate Download URL: https://bugzilla.mozilla.org/attachment.cgi?id=8446784

Root Certificate Name: Certplus Root CA G2
O From Issuer Field: Certplus
Trust Bits: Email; Websites
EV Policy OID(s): 1.3.6.1.4.1.22234.3.5.3.2
Root Certificate Download URL: https://bugzilla.mozilla.org/attachment.cgi?id=8446790

Root Certificate Name: OpenTrust Root CA G1
O From Issuer Field: OpenTrust
Trust Bits: Email; Websites
EV Policy OID(s): 1.3.6.1.4.1.22234.2.14.3.11
Root Certificate Download URL: https://bugzilla.mozilla.org/attachment.cgi?id=8446791

Root Certificate Name: OpenTrust Root CA G2
O From Issuer Field: OpenTrust
Trust Bits: Email; Websites
EV Policy OID(s): 1.3.6.1.4.1.22234.2.14.3.11
Root Certificate Download URL: https://bugzilla.mozilla.org/attachment.cgi?id=8446792

Root Certificate Name: OpenTrust Root CA G3
O From Issuer Field: OpenTrust
Trust Bits: Email; Websites
EV Policy OID(s): 1.3.6.1.4.1.22234.2.14.3.11
Root Certificate Download URL: https://bugzilla.mozilla.org/attachment.cgi?id=8446793


* The primary documents are the RCA CP, SSL CP, and EV CPS. Documents
are provided in French and some are translated into English.

Document Repository (French): http://www.OpenTrust.com/PC
Document Repository (English):
https://www.opentrustdtm.com/security-policies/?lang=en
RCA - Root Certificate Authorities - CP (English):
https://www.opentrustdtm.com//wp-content/uploads/2015/03/OpenTrust_DMS_RCA-Program_OpenTrust_CP-v-1.2s2.pdf
SSL CP (French):
https://www.opentrustdtm.com/wp-content/uploads/2015/11/OpenTrust_DMS_PC-Certificats-OpenTrust-SSL-RGS-et-ETSI-V15.pdf
EV CPS (English):
https://www.opentrustdtm.com//wp-content/uploads/2015/03/OpenTrust_DMS_EV_SSL_CA_Certification_Practice_Statement_2014_12_18s.pdf


Certificate Revocation
* CRL URLs:
http://get-crl.certificat.com/public/certplusrootcag1.crl
http://get-crl.certificat.com/public/certplusrootcag2.crl
http://get-crl.certificat.com/public/opentrustrootcag1.crl
http://get-crl.certificat.com/public/opentrustrootcag2.crl
http://get-crl.certificat.com/public/opentrustrootcag3.crl
* OCSP URL:
http://get-ocsp.certificat.com/certplusrootcag1
http://get-ocsp.certificat.com/certplusrootcag2
http://get-ocsp.certificat.com/opentrustrootcag1
http://get-ocsp.certificat.com/opentrustrootcag2
http://get-ocsp.certificat.com/opentrustrootcag3
SSL CP section 4.10.1: maximum expiration time of ten days 


Inclusion Policy Section 7 [Validation]. 
DocuSign appears to meet the minimum requirements for subscriber verification, as follows:

* SSL Verification: According to the SSL CP section 4.1.2, the domain name to be included in the certificate is validated via an email exchange using the email address from WHOIS or of the form "admin", "administrator", "webmaster", "hostmaster "or" postmaster "@ <domain name to be included in the certificate>. According to section 3.2.2 of the EV CPS, KEYNECTIS EV CA confirms that the domain name is registered with an Internet Corporation for Assigned Names and Numbers (ICANN) approved registrar or a registry listed by the Internet Assigned Numbers Authority (IANA); and Domain registration information in the WHOIS is public and shows the name, physical address, and administrative contact information for the organization. For Government Entity Applicants, the CA relies on the domain name listed for that entity in the records of the QGIS in Applicant’s Jurisdiction to verify Domain Name. 

* Email Verification: 	According to section 4.1.2 of the RCA CP, the certificate request is signed using a temporary password (OTP code), and OpenTrust signature Portal, transmitted to the email address contained in the certificate request described above in accordance with the signature policy [Form Signing]. This ensures the email address of the TC or the Administrator SSL.

Inclusion Policy Sections 11-14 [Audit]. 
Annual audits are performed by LSTI according to the ETSI TS 102 042 criteria.
http://www.lsti-certification.fr/images/liste_entreprise/Liste%20PSCe.pdf
https://bug1025095.bugzilla.mozilla.org/attachment.cgi?id=8590352


Inclusion Policy Section 18 [Certificate Hierarchy]

* CA Hierarchy: These new root certificates have cross-signed with the
currently-included ‘Certplus Class 2’ root certificate which expires in
2019.

Certplus Root CA G1 issued:
- EV CA: KEYNECTIS Extended Validation CA

Certplus Root CA G2 issued:
- EV CA: KEYNECTIS Extended Validation CA

OpenTrust Root CA G1 issued:
- EV CA: KEYNECTIS Extended Validation CA
- AATL CA: OpenTrust CA for AATL G1

OpenTrust Root CA G2 issued:
- EV CA: KEYNECTIS Extended Validation CA
- AATL CA: OpenTrust CA for AATL G2

OpenTrust Root CA G3 issued:
- EV CA: KEYNECTIS Extended Validation CA
- AATL CA: OpenTrust CA for AATL G3 


Based on this assessment I intend to approve this request from DocuSign to include the following root certificates, turn on the Websites and Email trust bits for all of them, and enable EV treatment for all of them.
+ Certplus Root CA G1 - (SHA512, RSA4096)
+ Certplus Root CA G2 - (SHA384, ECC)
+ OpenTrust Root CA G1 - (SHA256, RSA4096)
+ OpenTrust Root CA G2 - (SHA512, RSA4096)
+ OpenTrust Root CA G3 - (SHA384, ECC) 


The following action items will be tracked in this bug, in parallel with the inclusion process.

CA ACTION ITEMS: 
1) Update CPS to address the concerns raised in the discussion in mozilla.dev.security.policy about this request.
2) Update cert issuance process to prevent use of PrintableString, and enforce use of UTF8String instead.

Comment 48

[Nick Lamb (tialaramex)]

NB Kathleen intention is not that the issuance policy must "prevent use of PrintableString" but that PrintableString must only be used where it is suitable. ISO country codes used in C= for example can all be expressed as PrintableString, but many other things cannot.

The DocuSign plan they've explained meets Mozilla's requirements here, even though it does not per se "prevent use of PrintableString" since there will still be PrintableString values encoded in their certificates but only where it is safe and appropriate to do so.

If you wanted a one word change to your phrasing of the action item, I would insert invalid or inappropriate, to form e.g. "prevent inappropriate use of PrintableString". But getting the wording right isn't important so long as DocuSign do what they said they would.

Comment 49

[Kathleen Wilson]

As per the summary in Comment #47, and on behalf of Mozilla I approve this request from DocuSign to include the following root certificates:

** "Certplus Root CA G1" (websites, email), enable EV
** "Certplus Root CA G2" (websites, email), enable EV
** "OpenTrust Root CA G1" (websites, email), enable EV
** "OpenTrust Root CA G2" (websites, email), enable EV
** "OpenTrust Root CA G3" (websites, email), enable EV

I will file the NSS and PSM bugs for the approved changes.

Comment 50

[Kathleen Wilson]

I have filed bug #1274674 against NSS and bug #1274677 against PSM for the actual changes.

Comment 51

[Kathleen Wilson]

Updated audit statements provided in Bug #1297034.

Comment 52

[Kathleen Wilson]

Remi or Erwann, Please update the test websites with non-expired TLS/SSL certs, and comment in this bug when done.

Test URL: https://certplusrootcag1-test.opentrust.com
	 
Test URL: https://certplusrootcag2-test.opentrust.com
 
Test URL: https://opentrustrootcag1-test.opentrust.com
	 
Test URL: https://opentrustrootcag2-test.opentrust.com
	 
Test URL: https://opentrustrootcag3-test.opentrust.com

Comment 53

[Kathleen Wilson]

Closing this bug, but I would like to remind the CA that their annual updates must include test websites for each root certificate as stated in Section 2.2 of the BRs: "The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate. At a minimum, the CA SHALL host separate Web pages using Subscriber Certificates that are (i) valid, (ii) revoked, and (iii) expired." 

Instructions for providing annual updates are here:
https://wiki.mozilla.org/CA:CommonCADatabase#How_To_Provide_Annual_Updates

Comment 54

[Erwann Abalea]

Bonjour,

We want to remove the Trust Bit "Websites" for these 5 root CAs, repeated below:

OpenTrust Root CA G1
SHA1 fingerprint: 7991e834f7e2eedd08950152e9552d14e958d57e

OpenTrust Root CA G2
SHA1 fingerprint: 795f8860c5ab7c3d92e6cbf48de145cd11ef600b

OpenTrust Root CA G3
SHA1 fingerprint: 6e2664f356bf3455bfd1933f7c01ded813da8aa6

Certplus Root CA G1
SHA1 fingerprint: 22fdd0b7fda24e0dac492ca0aca67b6a1fe3f766

Certplus Root CA G2
SHA1 fingerprint: 4f658e1fe906d82802e9544741c954255d69cc1a

Comment 55

[Kathleen Wilson]

(In reply to Erwann Abalea from comment #54)
> Bonjour,
> 
> We want to remove the Trust Bit "Websites" for these 5 root CAs, repeated
> below:
> 
> OpenTrust Root CA G1
> SHA1 fingerprint: 7991e834f7e2eedd08950152e9552d14e958d57e
> 
> OpenTrust Root CA G2
> SHA1 fingerprint: 795f8860c5ab7c3d92e6cbf48de145cd11ef600b
> 
> OpenTrust Root CA G3
> SHA1 fingerprint: 6e2664f356bf3455bfd1933f7c01ded813da8aa6
> 
> Certplus Root CA G1
> SHA1 fingerprint: 22fdd0b7fda24e0dac492ca0aca67b6a1fe3f766
> 
> Certplus Root CA G2
> SHA1 fingerprint: 4f658e1fe906d82802e9544741c954255d69cc1a


I created Bug #1465625 for this request to turn off the websites trust bit.