info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
DocuSign (OpenTrust/Keynectis/Certplus) root renewal request
925 views
Skip to first unread message
Kathleen Wilson
Feb 9, 2016, 3:08:09 PM2/9/16
to mozilla-dev-s...@lists.mozilla.org
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
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
David E. Ross
Feb 9, 2016, 4:41:37 PM2/9/16
to mozilla-dev-s...@lists.mozilla.org
On 2/9/2016 12:07 PM, Kathleen Wilson wrote:
[snipped]
> * 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
Has an audit been performed with respect to the current ownership and
management, which changed less than six months ago?
Have any of the external CAs or RAs been audited since the recent change
of ownership?
--
David E. Ross
The Crimea is Putin's Sudetenland.
The Ukraine will be Putin's Czechoslovakia.
See <http://www.rossde.com/editorials/edtl_PutinUkraine.html>.
[snipped]
> * 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
management, which changed less than six months ago?
of ownership?
--
David E. Ross
The Crimea is Putin's Sudetenland.
The Ukraine will be Putin's Czechoslovakia.
See <http://www.rossde.com/editorials/edtl_PutinUkraine.html>.
Charles Reiss
Feb 9, 2016, 6:15:11 PM2/9/16
to mozilla-dev-s...@lists.mozilla.org
- _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?
Jakob Bohm
Feb 9, 2016, 11:11:01 PM2/9/16
to mozilla-dev-s...@lists.mozilla.org
Commenting only on a two points, snipping rest.
I am not associated with Docusign and this is just some guesswork to
help the process along. Obviously someone official will have to
directly or indirectly state which of these guesses are correct.
On 10/02/2016 00:14, Charles Reiss wrote:
>
> 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.
>
Could it be that the conclusion of the auditor is public, but the
detailed assessments about the confidential stuff the auditor had
access to (such as internal procedures, exact layout of the building
housing the private keys, discovered code vulnerabilities etc. etc.)
remain confidential? Similar to how the independent audits of
financial accounts has a public part (the results and a statement by
the auditor that it has been checked to be factually true) and a
private part (commentary for the board and management).
>
> 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?
>
Could it be a prohibition against publishing the certificates to all
and sundry (e.g. via Google's certificate indexing protocol), even
though the certificates are not technically confidential?
Or could it be that the records and documents used in validating the
certificate application (such as the CSR, signed paperwork, copies of
official documents, callback phone numbers, revocation passwords etc.)
remain confidential?
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
I am not associated with Docusign and this is just some guesswork to
help the process along. Obviously someone official will have to
directly or indirectly state which of these guesses are correct.
On 10/02/2016 00:14, Charles Reiss wrote:
>
> 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.
>
detailed assessments about the confidential stuff the auditor had
access to (such as internal procedures, exact layout of the building
housing the private keys, discovered code vulnerabilities etc. etc.)
remain confidential? Similar to how the independent audits of
financial accounts has a public part (the results and a statement by
the auditor that it has been checked to be factually true) and a
private part (commentary for the board and management).
>
> 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?
>
and sundry (e.g. via Google's certificate indexing protocol), even
though the certificates are not technically confidential?
Or could it be that the records and documents used in validating the
certificate application (such as the CSR, signed paperwork, copies of
official documents, callback phone numbers, revocation passwords etc.)
remain confidential?
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
Charles Reiss
Feb 16, 2016, 8:11:58 PM2/16/16
to mozilla-dev-s...@lists.mozilla.org
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
These certificates chain to the 'Certplus Class 2' root and contain a
> 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
trailing space in one of their dNSName SANs:
notBefore in 2016:
https://crt.sh/?id=12994171&opt=cablint
notBefore in 2015:
https://crt.sh/?id=10643272&opt=cablint
https://crt.sh/?id=9651778&opt=cablint
> 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.
Erwann Abalea
Feb 18, 2016, 12:08:35 PM2/18/16
to mozilla-dev-s...@lists.mozilla.org
Bonjour,
Le mardi 9 février 2016 22:41:37 UTC+1, David E. Ross a écrit :
> On 2/9/2016 12:07 PM, Kathleen Wilson wrote:
>
> [snipped]
>
> > * 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
>
> Has an audit been performed with respect to the current ownership and
> management, which changed less than six months ago?
No. Our last complete annual audit was performed in October 2015, and included these 5 new roots. The next complete audit is scheduled for October 2016. An extension audit will be performed this month (for other CAs, unrelated to this request). We asked the auditor to clearly distinguish between the two companies (Keynectis and Opentrust/Docusign France) in their next publication, we hope it will be done in March.
> > -- All the domain name to be set in extension "Name Constraint" for
Le mardi 9 février 2016 22:41:37 UTC+1, David E. Ross a écrit :
> On 2/9/2016 12:07 PM, Kathleen Wilson wrote:
>
> [snipped]
>
> > * 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
>
> Has an audit been performed with respect to the current ownership and
> management, which changed less than six months ago?
> > "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
> > email protection to be set in the CA certificate (refer to section 10.3
> > below).
> > "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
> > set in the CA certificate (refer to section 10.3 below).
> > Certificate in order to be set in the CA certificate (refer to section
> > 10.3 below).
>
> Have any of the external CAs or RAs been audited since the recent change
> of ownership?
We don't have any unconstrained external CA under these 5 new roots, and no external RA.
> > 10.3 below).
>
> Have any of the external CAs or RAs been audited since the recent change
> of ownership?
Erwann Abalea
Feb 18, 2016, 4:40:50 PM2/18/16
to mozilla-dev-s...@lists.mozilla.org
Bonsoir,
For CAs not issuing TLS certificates, an internal audit is performed, as permitted by Mozilla's definition of an independent auditor. See Mozilla Inclusion Policy version 2.2, items 11, 12, 13, and 14.
During our regular ETSI TS 102042 and ETSI TS 101456 audits, the auditor ensures that the internal audit team (a trusted role) is free from any pressures that might adversely influence trust in the service it provides. See section 7.5 of the aforementioned ETSI TS documents.
> 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.
The conclusion of the auditor is public, not the findings and mentions. Those are transmitted to the supervisory body.
> 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?
Certificate-related information that are protected by privacy laws, such as telephone numbers, copies of ID cards, passwords or PIN numbers exchanged between the customer and the CA/RA. Event logs are also confidential.
During our regular ETSI TS 102042 and ETSI TS 101456 audits, the auditor ensures that the internal audit team (a trusted role) is free from any pressures that might adversely influence trust in the service it provides. See section 7.5 of the aforementioned ETSI TS documents.
> 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?
Erwann Abalea
Feb 18, 2016, 4:42:17 PM2/18/16
to mozilla-dev-s...@lists.mozilla.org
Bonsoir,
Le mercredi 17 février 2016 02:11:58 UTC+1, Charles Reiss a écrit :
> 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
>
> These certificates chain to the 'Certplus Class 2' root and contain a
> trailing space in one of their dNSName SANs:
>
> notBefore in 2016:
> https://crt.sh/?id=12994171&opt=cablint
> notBefore in 2015:
> https://crt.sh/?id=10643272&opt=cablint
> https://crt.sh/?id=9651778&opt=cablint
Thank you for the information, we will investigate the events chains that came to the production of these certificates.
On first analysis, it seems it's a human error during a copy/paste operation, and a clarification of the procedures is necessary.
The self-audit tool we use for our quarterly self-audits will also be extended to detect that kind of defect.
Le mercredi 17 février 2016 02:11:58 UTC+1, Charles Reiss a écrit :
> 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
>
> These certificates chain to the 'Certplus Class 2' root and contain a
> trailing space in one of their dNSName SANs:
>
> notBefore in 2016:
> https://crt.sh/?id=12994171&opt=cablint
> notBefore in 2015:
> https://crt.sh/?id=10643272&opt=cablint
> https://crt.sh/?id=9651778&opt=cablint
On first analysis, it seems it's a human error during a copy/paste operation, and a clarification of the procedures is necessary.
The self-audit tool we use for our quarterly self-audits will also be extended to detect that kind of defect.
Charles Reiss
Feb 18, 2016, 6:55:02 PM2/18/16
to mozilla-dev-s...@lists.mozilla.org
not [be] affiliated with the CA as an employee or director". I assume
that this will be the case for subCAs for which an internal audit is
performed by virtue of the audit being performed employees of the parent
CA, a different company.
I don't believe having CAs audit their unconstrained subCAs is within
the spirit of Mozilla's policy (since a sufficiently non-compliant subCA
is an existential risk to the parent CA) though it is probably
technically in conformance.
I assume you believe the internal audit fits the third option of item
14's second requirement: "the party is bound by law, government
regulation, and/or a professional code of ethics to render an honest and
objective judgement regarding the CA" (since I imagine you aren't going
to be disclosing your financial relationship with external subCAs). Can
you identify what law, regulation, or code of ethics is involved?
[snip]
>
>> 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?
>
> Certificate-related information that are protected by privacy laws,
> such as telephone numbers, copies of ID cards, passwords or PIN
> numbers exchanged between the customer and the CA/RA. Event logs are
> also confidential.
In the event of serious certificate misissuance, what information about
>> 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?
>
> Certificate-related information that are protected by privacy laws,
> such as telephone numbers, copies of ID cards, passwords or PIN
> numbers exchanged between the customer and the CA/RA. Event logs are
> also confidential.
those certificates and how they were issued will DocuSign be able to
share with the public?
Erwann Abalea
Apr 4, 2016, 3:13:39 PM4/4/16
to mozilla-dev-s...@lists.mozilla.org
Bonsoir,
Le jeudi 18 février 2016 22:42:17 UTC+1, Erwann Abalea a écrit :
[...]
First-hand analysis was right, it was cut/paste errors.
The rules were repeated to our customer service and to our customers acting as RAs.
Parallel to that, we're currently modifying the configuration of what is exposed to our customers and to the customer service, to check that what is declared as an FQDN is correctly formed (only valid characters plus an optional star as leftmost label, valid total length, valid labels lengths).
And the self-audit tool is being modified to detect that kind of defect.
Le jeudi 18 février 2016 22:42:17 UTC+1, Erwann Abalea a écrit :
[...]
> > These certificates chain to the 'Certplus Class 2' root and contain a
> > trailing space in one of their dNSName SANs:
> >
> > notBefore in 2016:
> > https://crt.sh/?id=12994171&opt=cablint
> > notBefore in 2015:
> > https://crt.sh/?id=10643272&opt=cablint
> > https://crt.sh/?id=9651778&opt=cablint
>
> Thank you for the information, we will investigate the events chains that came to the production of these certificates.
> On first analysis, it seems it's a human error during a copy/paste operation, and a clarification of the procedures is necessary.
>
> The self-audit tool we use for our quarterly self-audits will also be extended to detect that kind of defect.
I forgot an update on this case.
> > trailing space in one of their dNSName SANs:
> >
> > notBefore in 2016:
> > https://crt.sh/?id=12994171&opt=cablint
> > notBefore in 2015:
> > https://crt.sh/?id=10643272&opt=cablint
> > https://crt.sh/?id=9651778&opt=cablint
>
> Thank you for the information, we will investigate the events chains that came to the production of these certificates.
> On first analysis, it seems it's a human error during a copy/paste operation, and a clarification of the procedures is necessary.
>
> The self-audit tool we use for our quarterly self-audits will also be extended to detect that kind of defect.
First-hand analysis was right, it was cut/paste errors.
The rules were repeated to our customer service and to our customers acting as RAs.
Parallel to that, we're currently modifying the configuration of what is exposed to our customers and to the customer service, to check that what is declared as an FQDN is correctly formed (only valid characters plus an optional star as leftmost label, valid total length, valid labels lengths).
And the self-audit tool is being modified to detect that kind of defect.
Erwann Abalea
Apr 4, 2016, 4:41:07 PM4/4/16
to mozilla-dev-s...@lists.mozilla.org
Bonsoir,
Our Root CA and intermediate CAs are ETSI TS 102042 compliant, and the audit is performed by an external auditor (LSTI).
As described in our CP (section 8), we have an internal organization that allows fulfilling the requirements set in ETSI TS 102042 section 7.5, including the independence of trusted roles regarding to any "commercial, financial, or other pressures which might adversely influence trust in the services it provides." The organization team at DocuSign France performing the internal audits and validating the CP/CPS is the PMA (Policy Management Authority), and has no hierarchical relationship with the department operating the CAs. This is also in line with TS 102042 section 5.4.1).
This requirement is verified during the annual ETSI TS 102042 audit performed by the external auditor.
> [snip]
> >
> >> 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?
> >
> > Certificate-related information that are protected by privacy laws,
> > such as telephone numbers, copies of ID cards, passwords or PIN
> > numbers exchanged between the customer and the CA/RA. Event logs are
> > also confidential.
>
> In the event of serious certificate misissuance, what information about
> those certificates and how they were issued will DocuSign be able to
> share with the public?
In compliance with applicable law and reglementation, facing a serious misissuance, DocuSign will be able to publicly share the affected certificates (since they're not confidential), certificate lifecycle (production, detection, and revocation date), what caused the misissuance, what countermeasures are to be applied.
Depending on the nature of what caused the misissuance, if the cause may also impact other CAs, we'll responsibly disclose more details with CABForum members on the Management list.
As described in our CP (section 8), we have an internal organization that allows fulfilling the requirements set in ETSI TS 102042 section 7.5, including the independence of trusted roles regarding to any "commercial, financial, or other pressures which might adversely influence trust in the services it provides." The organization team at DocuSign France performing the internal audits and validating the CP/CPS is the PMA (Policy Management Authority), and has no hierarchical relationship with the department operating the CAs. This is also in line with TS 102042 section 5.4.1).
This requirement is verified during the annual ETSI TS 102042 audit performed by the external auditor.
> [snip]
> >
> >> 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?
> >
> > Certificate-related information that are protected by privacy laws,
> > such as telephone numbers, copies of ID cards, passwords or PIN
> > numbers exchanged between the customer and the CA/RA. Event logs are
> > also confidential.
>
> In the event of serious certificate misissuance, what information about
> those certificates and how they were issued will DocuSign be able to
> share with the public?
Depending on the nature of what caused the misissuance, if the cause may also impact other CAs, we'll responsibly disclose more details with CABForum members on the Management list.
awha...@google.com
Apr 7, 2016, 7:38:09 PM4/7/16
to mozilla-dev-s...@lists.mozilla.org
OpenTrust has requested EV treatment in Chrome, with bug: https://bugs.chromium.org/p/chromium/issues/detail?id=385090
As such I've reviewed the "EV SSL CA Certificate Practice Statement" version 0.8 dated Feb 1st 2016, and have the following comments and questions for them:
1.1 Overview
We encourage honouring CAA records, even though it's not currently required. We also encourage CAs to publish how they would use CAA values in the future if they were to support it, to allow domain owners to start creating such records.
For Club EV and ISP EV, it says they perform "All checks required to issue EV Certificates, in accordance with this CPS." Could you confirm that KEYNECTIS EV still performs the final cross check, per 3.2.6 Validation of Authority.
1.2 Document Name and Identification
The application lists 1.3.6.1.4.1.22234.2.5.2.3.1 as the EV OID, but this section mentions that you're moving to 1.3.6.1.4.1.22234.2.14.3.11. Are both being requested? If so, please update in the Chromium bug.
1.5.4 CPS Approval Procedure
Please clarify the exact details regarding "Parts of the CPS are remains (sic) confidential and are not published."
1.6 Definitions and Acronyms
Independent confirmation from applicant: definition missing.
3.1.5 Unicity of Names
Good to see 64 bits of serial number entropy.
3.2.2.4 Verification of an Entity Domain Name
"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."
Please describe how this is covered by one of items 1 to 7 of section 3.2.2.4 of the Baseline Requirements.
4.1.2.1 K.EV offer
"at the following address:" - no address is specified
4.2.1.1 K.EV offer
Missing section reference in the 7th bullet
4.9.4 Time within Which CA Must Process the Revocation Request
"OPENTRUST RA for revocation is available from 9:00 am to 06:00 pm Monday to Friday, except during bank holidays."
Baseline Requirements section 4.9.1.1. "The CA SHALL revoke a Certificate within 24 hours", and 4.9.3. "The CA SHALL maintain a continuous 24x7 ability to accept and respond to revocation requests and related inquiries.". Please confirm that a revocation request can go directly to the CA if the RA isn't currently open.
5.8 EV CA component termination
Several sections of the Baseline Requirements refer to CA being revoked making arrangements for another CA to provide revocation support for issued certificates. Would such an arrangement be considered here?
6.8 Time Stamping
This section appears to prohibit the backdating of certificates. Good to see.
7.1 Certificate Profile
Key length still mentions 1024 bits, without caveat.
Public key algorithm still mentions SHA1, without caveat.
Many thanks,
Andrew
As such I've reviewed the "EV SSL CA Certificate Practice Statement" version 0.8 dated Feb 1st 2016, and have the following comments and questions for them:
1.1 Overview
We encourage honouring CAA records, even though it's not currently required. We also encourage CAs to publish how they would use CAA values in the future if they were to support it, to allow domain owners to start creating such records.
For Club EV and ISP EV, it says they perform "All checks required to issue EV Certificates, in accordance with this CPS." Could you confirm that KEYNECTIS EV still performs the final cross check, per 3.2.6 Validation of Authority.
1.2 Document Name and Identification
The application lists 1.3.6.1.4.1.22234.2.5.2.3.1 as the EV OID, but this section mentions that you're moving to 1.3.6.1.4.1.22234.2.14.3.11. Are both being requested? If so, please update in the Chromium bug.
1.5.4 CPS Approval Procedure
Please clarify the exact details regarding "Parts of the CPS are remains (sic) confidential and are not published."
1.6 Definitions and Acronyms
Independent confirmation from applicant: definition missing.
3.1.5 Unicity of Names
Good to see 64 bits of serial number entropy.
3.2.2.4 Verification of an Entity Domain Name
"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."
4.1.2.1 K.EV offer
"at the following address:" - no address is specified
4.2.1.1 K.EV offer
Missing section reference in the 7th bullet
4.9.4 Time within Which CA Must Process the Revocation Request
"OPENTRUST RA for revocation is available from 9:00 am to 06:00 pm Monday to Friday, except during bank holidays."
Baseline Requirements section 4.9.1.1. "The CA SHALL revoke a Certificate within 24 hours", and 4.9.3. "The CA SHALL maintain a continuous 24x7 ability to accept and respond to revocation requests and related inquiries.". Please confirm that a revocation request can go directly to the CA if the RA isn't currently open.
5.8 EV CA component termination
Several sections of the Baseline Requirements refer to CA being revoked making arrangements for another CA to provide revocation support for issued certificates. Would such an arrangement be considered here?
6.8 Time Stamping
This section appears to prohibit the backdating of certificates. Good to see.
7.1 Certificate Profile
Key length still mentions 1024 bits, without caveat.
Public key algorithm still mentions SHA1, without caveat.
Many thanks,
Andrew
Erwann Abalea
Apr 28, 2016, 10:19:21 AM4/28/16
to mozilla-dev-s...@lists.mozilla.org
Bonjour,
Le vendredi 8 avril 2016 01:38:09 UTC+2, awha...@google.com a écrit :
> OpenTrust has requested EV treatment in Chrome, with bug: https://bugs.chromium.org/p/chromium/issues/detail?id=385090
>
> As such I've reviewed the "EV SSL CA Certificate Practice Statement" version 0.8 dated Feb 1st 2016, and have the following comments and questions for them:
>
> 1.1 Overview
>
> We encourage honouring CAA records, even though it's not currently required. We also encourage CAs to publish how they would use CAA values in the future if they were to support it, to allow domain owners to start creating such records.
Ok, we'll adapt our procedures if necessary.
> For Club EV and ISP EV, it says they perform "All checks required to issue EV Certificates, in accordance with this CPS." Could you confirm that KEYNECTIS EV still performs the final cross check, per 3.2.6 Validation of Authority.
As described in sections 4.2.1.2 and 4.2.1.3, Club EV and ISP EV offers can't be open unless KEYNECTIS EV CA has performed necessary identification and authentication processes under dual control (RA operator 1 and RA operator 2), to perform this cross-check.
> 1.2 Document Name and Identification
>
> The application lists 1.3.6.1.4.1.22234.2.5.2.3.1 as the EV OID, but this section mentions that you're moving to 1.3.6.1.4.1.22234.2.14.3.11. Are both being requested? If so, please update in the Chromium bug.
The Google Chromium application request will be updated accordingly.
> 1.5.4 CPS Approval Procedure
>
> Please clarify the exact details regarding "Parts of the CPS are remains (sic) confidential and are not published."
Internal procedures, such as management of badges, management of access controls (physical and logical), management of secret shares, etc.
> 1.6 Definitions and Acronyms
>
> Independent confirmation from applicant: definition missing.
We meant to copy/paste the definition from EV guidelines, and missed it. This will be corrected in the next CPS revision.
> 3.2.2.4 Verification of an Entity Domain Name
>
> "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."
>
> Please describe how this is covered by one of items 1 to 7 of section 3.2.2.4 of the Baseline Requirements.
This is an unfortunate mix, inspired by section 3.2.2.1 (dealing with Entity legal existence verifications). This phrase will be removed in the next CPS revision. We only use methods 1 to 4.
> 4.1.2.1 K.EV offer
>
> "at the following address:" - no address is specified
That's an error, the proper address is transmitted with the purchase order. This will be corrected in the next CPS revision.
> 4.2.1.1 K.EV offer
>
> Missing section reference in the 7th bullet
The next 2 bullets should have been right-indented, as in sections 4.2.1.2 and 4.2.1.3. Will be corrected in the next CPS revision.
> 4.9.4 Time within Which CA Must Process the Revocation Request
>
> "OPENTRUST RA for revocation is available from 9:00 am to 06:00 pm Monday to Friday, except during bank holidays."
>
> Baseline Requirements section 4.9.1.1. "The CA SHALL revoke a Certificate within 24 hours", and 4.9.3. "The CA SHALL maintain a continuous 24x7 ability to accept and respond to revocation requests and related inquiries.". Please confirm that a revocation request can go directly to the CA if the RA isn't currently open.
This 9-18 Mon-Fri time frame is only for OPENTRUST RA human personnel. KEYNECTIS EV CA online revocation service is available on a 24x7 basis, as written on the preceding page.
> 5.8 EV CA component termination
>
> Several sections of the Baseline Requirements refer to CA being revoked making arrangements for another CA to provide revocation support for issued certificates. Would such an arrangement be considered here?
No.
> 7.1 Certificate Profile
>
> Key length still mentions 1024 bits, without caveat.
>
> Public key algorithm still mentions SHA1, without caveat.
1024 bits and SHA1 were not removed from the CPS, this will be done in the next CPS revision.
In the meantime, we of course follow CABF BR regarding key sizes and signature algorithm (keys smaller than 2048 bits are rejected, and certificates are signed with SHA2 only since 01/01/2016).
Le vendredi 8 avril 2016 01:38:09 UTC+2, awha...@google.com a écrit :
> OpenTrust has requested EV treatment in Chrome, with bug: https://bugs.chromium.org/p/chromium/issues/detail?id=385090
>
> As such I've reviewed the "EV SSL CA Certificate Practice Statement" version 0.8 dated Feb 1st 2016, and have the following comments and questions for them:
>
> 1.1 Overview
>
> We encourage honouring CAA records, even though it's not currently required. We also encourage CAs to publish how they would use CAA values in the future if they were to support it, to allow domain owners to start creating such records.
> For Club EV and ISP EV, it says they perform "All checks required to issue EV Certificates, in accordance with this CPS." Could you confirm that KEYNECTIS EV still performs the final cross check, per 3.2.6 Validation of Authority.
> 1.2 Document Name and Identification
>
> The application lists 1.3.6.1.4.1.22234.2.5.2.3.1 as the EV OID, but this section mentions that you're moving to 1.3.6.1.4.1.22234.2.14.3.11. Are both being requested? If so, please update in the Chromium bug.
> 1.5.4 CPS Approval Procedure
>
> Please clarify the exact details regarding "Parts of the CPS are remains (sic) confidential and are not published."
> 1.6 Definitions and Acronyms
>
> Independent confirmation from applicant: definition missing.
> 3.2.2.4 Verification of an Entity Domain Name
>
> "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."
>
> Please describe how this is covered by one of items 1 to 7 of section 3.2.2.4 of the Baseline Requirements.
> 4.1.2.1 K.EV offer
>
> "at the following address:" - no address is specified
> 4.2.1.1 K.EV offer
>
> Missing section reference in the 7th bullet
> 4.9.4 Time within Which CA Must Process the Revocation Request
>
> "OPENTRUST RA for revocation is available from 9:00 am to 06:00 pm Monday to Friday, except during bank holidays."
>
> Baseline Requirements section 4.9.1.1. "The CA SHALL revoke a Certificate within 24 hours", and 4.9.3. "The CA SHALL maintain a continuous 24x7 ability to accept and respond to revocation requests and related inquiries.". Please confirm that a revocation request can go directly to the CA if the RA isn't currently open.
> 5.8 EV CA component termination
>
> Several sections of the Baseline Requirements refer to CA being revoked making arrangements for another CA to provide revocation support for issued certificates. Would such an arrangement be considered here?
> 7.1 Certificate Profile
>
> Key length still mentions 1024 bits, without caveat.
>
> Public key algorithm still mentions SHA1, without caveat.
In the meantime, we of course follow CABF BR regarding key sizes and signature algorithm (keys smaller than 2048 bits are rejected, and certificates are signed with SHA2 only since 01/01/2016).
Andrew R. Whalley
May 4, 2016, 7:21:25 PM5/4/16
to Erwann Abalea, mozilla-dev-s...@lists.mozilla.org
Thank you Erwann. I have no other questions at this time.
On Thu, Apr 28, 2016 at 7:13 AM, Erwann Abalea <eab...@gmail.com> wrote:
> Bonjour,
>
> Le vendredi 8 avril 2016 01:38:09 UTC+2, awha...@google.com a écrit :
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
On Thu, Apr 28, 2016 at 7:13 AM, Erwann Abalea <eab...@gmail.com> wrote:
> Bonjour,
>
> Le vendredi 8 avril 2016 01:38:09 UTC+2, awha...@google.com a écrit :
> > OpenTrust has requested EV treatment in Chrome, with bug:
> https://bugs.chromium.org/p/chromium/issues/detail?id=385090
> >
> > As such I've reviewed the "EV SSL CA Certificate Practice Statement"
> version 0.8 dated Feb 1st 2016, and have the following comments and
> questions for them:
> >
> > 1.1 Overview
> >
> > We encourage honouring CAA records, even though it's not currently
> required. We also encourage CAs to publish how they would use CAA values
> in the future if they were to support it, to allow domain owners to start
> creating such records.
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=385090
> >
> > As such I've reviewed the "EV SSL CA Certificate Practice Statement"
> version 0.8 dated Feb 1st 2016, and have the following comments and
> questions for them:
> >
> > 1.1 Overview
> >
> > We encourage honouring CAA records, even though it's not currently
> required. We also encourage CAs to publish how they would use CAA values
> in the future if they were to support it, to allow domain owners to start
> creating such records.
>
> Ok, we'll adapt our procedures if necessary.
>
>
>
>
> > For Club EV and ISP EV, it says they perform "All checks required to
> issue EV Certificates, in accordance with this CPS." Could you confirm
> that KEYNECTIS EV still performs the final cross check, per 3.2.6
> Validation of Authority.
>
> issue EV Certificates, in accordance with this CPS." Could you confirm
> that KEYNECTIS EV still performs the final cross check, per 3.2.6
> Validation of Authority.
>
> As described in sections 4.2.1.2 and 4.2.1.3, Club EV and ISP EV offers
> can't be open unless KEYNECTIS EV CA has performed necessary identification
> and authentication processes under dual control (RA operator 1 and RA
> operator 2), to perform this cross-check.
>
>
> can't be open unless KEYNECTIS EV CA has performed necessary identification
> and authentication processes under dual control (RA operator 1 and RA
> operator 2), to perform this cross-check.
>
>
> > 1.2 Document Name and Identification
> >
> > The application lists 1.3.6.1.4.1.22234.2.5.2.3.1 as the EV OID, but
> this section mentions that you're moving to 1.3.6.1.4.1.22234.2.14.3.11.
> Are both being requested? If so, please update in the Chromium bug.
>
> >
> > The application lists 1.3.6.1.4.1.22234.2.5.2.3.1 as the EV OID, but
> this section mentions that you're moving to 1.3.6.1.4.1.22234.2.14.3.11.
> Are both being requested? If so, please update in the Chromium bug.
>
> The Google Chromium application request will be updated accordingly.
>
>
>
>
> > 1.5.4 CPS Approval Procedure
> >
> > Please clarify the exact details regarding "Parts of the CPS are remains
> (sic) confidential and are not published."
>
> >
> > Please clarify the exact details regarding "Parts of the CPS are remains
> (sic) confidential and are not published."
>
> Internal procedures, such as management of badges, management of access
> controls (physical and logical), management of secret shares, etc.
>
>
> controls (physical and logical), management of secret shares, etc.
>
>
> > 1.6 Definitions and Acronyms
> >
> > Independent confirmation from applicant: definition missing.
>
> >
> > Independent confirmation from applicant: definition missing.
>
> We meant to copy/paste the definition from EV guidelines, and missed it.
> This will be corrected in the next CPS revision.
>
>
> This will be corrected in the next CPS revision.
>
>
> > 3.2.2.4 Verification of an Entity Domain Name
> >
> > "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."
> >
> > Please describe how this is covered by one of items 1 to 7 of section
> 3.2.2.4 of the Baseline Requirements.
>
> >
> > "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."
> >
> > Please describe how this is covered by one of items 1 to 7 of section
> 3.2.2.4 of the Baseline Requirements.
>
> This is an unfortunate mix, inspired by section 3.2.2.1 (dealing with
> Entity legal existence verifications). This phrase will be removed in the
> next CPS revision. We only use methods 1 to 4.
>
>
> Entity legal existence verifications). This phrase will be removed in the
> next CPS revision. We only use methods 1 to 4.
>
>
> > 4.1.2.1 K.EV offer
> >
> > "at the following address:" - no address is specified
>
> >
> > "at the following address:" - no address is specified
>
> That's an error, the proper address is transmitted with the purchase
> order. This will be corrected in the next CPS revision.
>
>
> order. This will be corrected in the next CPS revision.
>
>
> > 4.2.1.1 K.EV offer
> >
> > Missing section reference in the 7th bullet
>
> >
> > Missing section reference in the 7th bullet
>
> The next 2 bullets should have been right-indented, as in sections 4.2.1.2
> and 4.2.1.3. Will be corrected in the next CPS revision.
>
>
> and 4.2.1.3. Will be corrected in the next CPS revision.
>
>
> > 4.9.4 Time within Which CA Must Process the Revocation Request
> >
> > "OPENTRUST RA for revocation is available from 9:00 am to 06:00 pm
> Monday to Friday, except during bank holidays."
> >
> > Baseline Requirements section 4.9.1.1. "The CA SHALL revoke a
> Certificate within 24 hours", and 4.9.3. "The CA SHALL maintain a
> continuous 24x7 ability to accept and respond to revocation requests and
> related inquiries.". Please confirm that a revocation request can go
> directly to the CA if the RA isn't currently open.
>
> >
> > "OPENTRUST RA for revocation is available from 9:00 am to 06:00 pm
> Monday to Friday, except during bank holidays."
> >
> > Baseline Requirements section 4.9.1.1. "The CA SHALL revoke a
> Certificate within 24 hours", and 4.9.3. "The CA SHALL maintain a
> continuous 24x7 ability to accept and respond to revocation requests and
> related inquiries.". Please confirm that a revocation request can go
> directly to the CA if the RA isn't currently open.
>
> This 9-18 Mon-Fri time frame is only for OPENTRUST RA human personnel.
> KEYNECTIS EV CA online revocation service is available on a 24x7 basis, as
> written on the preceding page.
>
>
> KEYNECTIS EV CA online revocation service is available on a 24x7 basis, as
> written on the preceding page.
>
>
> > 5.8 EV CA component termination
> >
> > Several sections of the Baseline Requirements refer to CA being revoked
> making arrangements for another CA to provide revocation support for issued
> certificates. Would such an arrangement be considered here?
>
> No.
> >
> > Several sections of the Baseline Requirements refer to CA being revoked
> making arrangements for another CA to provide revocation support for issued
> certificates. Would such an arrangement be considered here?
>
>
>
> > 7.1 Certificate Profile
> >
> > Key length still mentions 1024 bits, without caveat.
> >
> > Public key algorithm still mentions SHA1, without caveat.
>
>
> > 7.1 Certificate Profile
> >
> > Key length still mentions 1024 bits, without caveat.
> >
> > Public key algorithm still mentions SHA1, without caveat.
>
> 1024 bits and SHA1 were not removed from the CPS, this will be done in the
> next CPS revision.
> In the meantime, we of course follow CABF BR regarding key sizes and
> signature algorithm (keys smaller than 2048 bits are rejected, and
> certificates are signed with SHA2 only since 01/01/2016).
> _______________________________________________
> next CPS revision.
> In the meantime, we of course follow CABF BR regarding key sizes and
> signature algorithm (keys smaller than 2048 bits are rejected, and
> certificates are signed with SHA2 only since 01/01/2016).
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
Kathleen Wilson
May 9, 2016, 8:08:00 PM5/9/16
to mozilla-dev-s...@lists.mozilla.org
Thanks to all of you who have reviewed and commented on 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.
I did not see any show-stoppers, so I propose that we move forward with approving and including the root certificates listed above, and in parallel I will track the CA's action item to update their CPS.
Thanks,
Kathleen
+ 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)
I believe that all of the questions and concerns that were raised in this discussion have been resolved, or will be resolved in the next version of their CPS.
+ Certplus Root CA G2 - (SHA384, ECC)
+ OpenTrust Root CA G1 - (SHA256, RSA4096)
+ OpenTrust Root CA G2 - (SHA512, RSA4096)
+ OpenTrust Root CA G3 - (SHA384, ECC)
I did not see any show-stoppers, so I propose that we move forward with approving and including the root certificates listed above, and in parallel I will track the CA's action item to update their CPS.
Thanks,
Kathleen
Kurt Roeckx
May 10, 2016, 4:10:49 AM5/10/16
to mozilla-dev-s...@lists.mozilla.org
On 2016-05-10 02:07, Kathleen Wilson wrote:
> Thanks to all of you who have reviewed and commented on 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)
I'm only finding 1 certificate during the last week, and it has a
> Thanks to all of you who have reviewed and commented on 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)
problem with the encoding:
https://crt.sh/?id=18733629&opt=x509lint
It's using a PrintableString with "Hautes-Pyrénées" in it, which is
clearly wrong. A PrintableString has a very limited amount of valid
characters. All their strings are PrintableStrings. They should
probably switch most of those to UTF8String.
Kurt
Nick Lamb
May 10, 2016, 6:54:57 AM5/10/16
to mozilla-dev-s...@lists.mozilla.org
On Tuesday, 10 May 2016 09:10:49 UTC+1, Kurt Roeckx wrote:
> It's using a PrintableString with "Hautes-Pyrénées" in it, which is
> clearly wrong. A PrintableString has a very limited amount of valid
> characters. All their strings are PrintableStrings. They should
> probably switch most of those to UTF8String.
Ah yes, perhaps it is possible this sort of thing is what DocuSign is referring to with
> It's using a PrintableString with "Hautes-Pyrénées" in it, which is
> clearly wrong. A PrintableString has a very limited amount of valid
> characters. All their strings are PrintableStrings. They should
> probably switch most of those to UTF8String.
"As of 31st of March 2016, 10755 certificates are concerned by (e). Last issuance date will be 06/30/2016. Last expiration date will be 06/30/2019."
Even though the intent of 4e was phase out of legacy encodings like TeletexString, shoving things that aren't PrintableStrings into a PrintableString is definitely worse.
If that is what they intended by their response, is the implied promise to fix it at the end of next month ("last issuance date will be 06/30/2016") acceptable to Mozilla? I guess either way we can hope for a clarification from DocuSign.
Erwann Abalea
May 10, 2016, 11:30:45 AM5/10/16
to mozilla-dev-s...@lists.mozilla.org
Bonjour,
It's clearly wrong, yes, and we're checking and changing legacy configuration files to UTF8String (except specific attributes such as countryName or domainComponent). This will be done before 30/06/2016.
Kathleen Wilson
May 10, 2016, 11:50:41 AM5/10/16
to mozilla-dev-s...@lists.mozilla.org
As Nick pointed out, DocuSign did notify us that they have this problem and intend to resolve this by June 30, 2016.
Reference: https://wiki.mozilla.org/index.html#March_2016_Responses
I propose that we move forward with the inclusion process in parallel, since the inclusion process takes longer than that, so we will be able to confirm the change before the new roots are included in a release version of Firefox. There will be two action items that I will need to track for the CA:
1) Update CPS
2) Update cert issuance process to prevent use of PrintableString, and enforce use of UTF8String instead.
Thanks,
Kathleen
Kathleen Wilson
May 12, 2016, 4:19:22 PM5/12/16
to mozilla-dev-s...@lists.mozilla.org
Thanks to all of you who reviewed and commented on 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.
https://bugzilla.mozilla.org/show_bug.cgi?id=1025095
I will track the CA's 2 action items in the bug, in parallel with the rest of the inclusion process.
1) Update CPS to address the concerns raised in this discussion.
Thanks,
Kathleen
+ 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)
I am not aware of any issues that would prevent us from moving forward with this request. Therefore, I will recommend approval in the bug.
+ Certplus Root CA G2 - (SHA384, ECC)
+ OpenTrust Root CA G1 - (SHA256, RSA4096)
+ OpenTrust Root CA G2 - (SHA512, RSA4096)
+ OpenTrust Root CA G3 - (SHA384, ECC)
https://bugzilla.mozilla.org/show_bug.cgi?id=1025095
I will track the CA's 2 action items in the bug, in parallel with the rest of the inclusion process.
1) Update CPS to address the concerns raised in this discussion.
2) Update cert issuance process to prevent use of PrintableString, and enforce use of UTF8String instead.
Any further follow-up on this request should be added directly to the bug.
Thanks,
Kathleen
0 new messages