On 02/09/16 20:07, Kathleen Wilson wrote: > This request by DocuSign (OpenTrust/Keynectis/Certplus) is 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. These new > certs will eventually replace the ‘Certplus Class 2’ root certificate > that was included via Bugzilla Bug #335392. > + 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) > > 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. > > The request is documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=1025095 > > And in the pending certificates list: > https://wiki.mozilla.org/CA:PendingCAs > > Summary of Information Gathered and Verified: > https://bugzilla.mozilla.org/attachment.cgi?id=8692112 > > Noteworthy points: > > * 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
My reading of section 8.1 of the CP is that if CA is - _not_ technically constrained (as defined by Mozilla); and - not "issuing SSL certificates" (e.g. a CA lacking any EKU or name constraints that only issues certificates to individuals), then, it can be audited only by auditors who do not meet Mozilla's definition of an independent auditor. (8.2 allows internal auditors to be only "sufficiently organizationally separated from that entity to provide an unbiased, independent evaluation", which seems like it could include a CA employee.) Is this correct? Section 9.3.1 of this CP suggests that "audit results and reports" are confidential information, which seems to be at odds with Mozilla's public attestation requirement. Section 9.3.3 of this CP states in part: "PKI components must not disclose certificate or certificate-related information to any third party unless authorized by this policy" while section 9.4.3 states: "Any and all information within a certificate is inherently public information and shall not be considered confidential information." What is the 'certificate information' contemplated by section 9.3.3 that is not contained within a certificate? > > 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 > > > > * 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 > > * This request is to turn on the Websites and Email trust bits, and > enable EV treatment for all 5 of these root certificates. > > Translation of sections of the SSL CP: > > 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.” > > > EV CPS section 3.2.2: Authentication of an entity identity is based on > the verification of information provided by the entity, in compliance > with information verification requirements issued from "GUIDELINES FOR > THE ISSUANCE AND MANAGEMENT OF EXTENDED VALIDATION CERTIFICATES" (refer > to [EV SSL, section 11 to 14]). > Applicant's existence and identity are verified, including; > - Applicant’s legal existence and identity, and > - Applicant’s physical existence (business presence at a physical > address), and > - Applicant’s operational existence (business activity), and > - Verification of Applicant’s Domain Name. > > Further details also provided in the EV CPS. > > EV CPS section 3.2.2.4: Checks on domain names are such that the > KEYNECTIS EV CA confirms such domain name satisfies the following > requirements: > - 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); > - 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. > - Applicant: > -- is the registered holder of the domain name; or > -- has been granted the exclusive right to use the domain name by the > registered holder of the domain name; > - Applicant is aware of its registration or exclusive control of the > domain name. > In case an EV Certificate request is made for a domain name containing > mixed character KEYNECTIS EV CA visually compares the domain name with > mixed character sets with known high risk domains. If a similarity is > found then the EV Certificate Request is flagged as High Risk. The CA > performs appropriate additional authentication and verification to be > certain that Applicant and the target in question are the same org > > > * Root Certificate Download URL: > https://www.opentrustdtm.com/security-policies/?lang=en > + Certplus Root CA G1 - > https://bugzilla.mozilla.org/attachment.cgi?id=8446784 > + Certplus Root CA G2 - > https://bugzilla.mozilla.org/attachment.cgi?id=8446790 > + OpenTrust Root CA G1 - > https://bugzilla.mozilla.org/attachment.cgi?id=8446791 > + OpenTrust Root CA G2 - > https://bugzilla.mozilla.org/attachment.cgi?id=8446792 > + OpenTrust Root CA G3 - > https://bugzilla.mozilla.org/attachment.cgi?id=8446793 > > * EV Policy OIDs: > + Certplus Root CA G1 - 1.3.6.1.4.1.22234.3.5.3.1 > + Certplus Root CA G2 - 1.3.6.1.4.1.22234.3.5.3.2 > + OpenTrust Root CA G1 - 1.3.6.1.4.1.22234.2.14.3.11 > + OpenTrust Root CA G2 - 1.3.6.1.4.1.22234.2.14.3.11 > + OpenTrust Root CA G3 - 1.3.6.1.4.1.22234.2.14.3.11 > > > * Test Websites: > 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/ > > * 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 > > * 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 > > * Potentially Problematic Practices: > (http://wiki.mozilla.org/CA:Problematic_Practices) > ** Both external CAs and External RAs are allowed. > RCA CP describes 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. > ** Externally Operated SubCAs: Currently none, but the CP does allow for > external CAs. > *** RCA CP section 1.1: The present CP represents the common > requirements that RCAs, ICAs and CAs have to enforce to be signed by a > RCA or an ICA and designates standards to be implemented by a CA in > order to issue Subscriber (or Subject) Certificates. > OpenTrust manages its RCA certificates lifecycle as detailed in [ETSI > 102 042] and [ETSI 101 456]. CAs signed by a RCA or an ICA shall be > audited against ETSI standards (102 042 and/or 101 456) or WebTrust > (http://www.webtrust.org/item64428.aspx) or according to rules defined > by [Adobe] for all types of Subscriber certificates it issues and in the > certification path of the RCA. In case the CA issues SSL and / or email > certificates, as an alternative to the above audits, this CA may be > technically constrained in the CA certificate and audited by Opentrust. > *** RCA CP section 4.1.2.3: For SSL/TLS Certificate and email > certificate under [Mozilla] program, choice for the CA certificate > between “audit” against ETSI standards, or [CAB Forum] for SSL/TLS, > (refer to section 8 below) or “technical constraint” (refer to section > 10.3 below). > - If Subscribers are only internal: Customer may choose to have only > “technical constraint”. > - If some Subscribers are external: Customer shall choose to have > “audit” against ETSI standards (refer to section 8 below). > - If “Technical constraint” choice is made, then following information > shall be provided: > — All the domain name to be set in extension “Name Constraint” for > “dnsNames” if Subscriber Certificate are for SSL certificate and/or > email protection to be set in the CA certificate (refer to section 10.3 > below). > — All the domain name to be set in extension “Name Constraint” for > “rfc822names” if Subscriber Certificate are for email protection to be > set in the CA certificate (refer to section 10.3 below). > — All the possible “Extended Key Usage” that are set in the Subscriber > Certificate in order to be set in the CA certificate (refer to section > 10.3 below). > > > This begins the discussion of the 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. > > At the conclusion of this discussion I will provide a summary of issues > noted and action items. If there are outstanding issues, then an > additional discussion may be needed as follow-up. If there are no > outstanding issues, then I will recommend approval of this request in > the bug. > > Kathleen > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
