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
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
