Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Entrust Request to Replace Previously Included Root Cert
229 views
Skip to first unread message
Kathleen Wilson
Mar 11, 2013, 9:01:38 PM3/11/13
to mozilla-dev-s...@lists.mozilla.org
Entrust has applied to replace the “Entrust.net Certification Authority
(2048)” root certificate. Several years ago Entrust realized that the
certificate was missing the Basic Constraint Extension, so they issued a
new root certificate to replace it. The root cert to be replaced has
all three trust bits enabled. This request is to also enable EV for
this root cert.
Entrust is a commercial CA serving the global market for SSL web
certificates. Entrust also issues certificates to subordinate CAs for
enterprise and commercial use. Entrust has enterprise subordinate CAs
that issue certificates for SSL and S/MIME internal use. There are also
commercial subordinate CAs that issue SSL certificates and S/MIME
certificates to the public.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=694536
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#Entrust
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=723649
Noteworthy points:
* The primary documents are the CPS and EV CPS documents, which are
provided in English.
Document Repository: http://www.entrust.net/CPS
CPS: http://www.entrust.net/CPS/pdf/ssl-cps-250612-v2-8.pdf
EV CPS: http://www.entrust.net/CPS/pdf/evssl_cps_english250612.pdf
The “Entrust.net Certification Authority (2048)” root certificate is
already included in NSS. It has been updated to extend the validity
period and to correct the Basic Constraints extension. This root is
Entrust's primary trust anchor for commercially issuing SSL, S/MIME, and
Code Signing certificates.
This root signs both internally-operated subCAs and externally-operated
subCAs. It has also been used to cross-sign other roots in Mozilla’s
Program. Details are provided in the CAInformation document attached to
the bug.
Enterprise RAs
* Entrust has Enterprise administrator accounts that allow customers to
issue certificates on demand for pre-verified domains and organization
names. Software run at Entrust limits issuance to the pre-verified
domains. All enterprise administrators authenticate with
username/password and a second factor.
Third-Party Private (or Enterprise) Subordinate CAs
* Generally Enterprise sub-CAs are Entrust PKI software customers
looking for public trust in the certificates they are issuing for
enterprise business purposes.
* Enterprise CAs have generally been allowed to have a cross-certificate
as they are also Entrust PKI software customers. Entrust is planning to
stop the practice of issuing cross-certificates to third parties that
operate their own CA. No new customers of this type will be added, and
existing customers will be transitioned to a different solution.
* Third Party sub-CAs must develop their own CP/CPS documentation, which
must be no less stringent than the Entrust CPS and meet the requirements
of the cross-certificate agreement. Entrust is in the process of
updating these third party sub-CAs to also meet the requirements of the
CAB Forum Baseline Requirements.
* Sub-CAs domains are currently only constrained by contract. In some
cases sub-CAs are allowed to issue their own subordinates. This is
assessed on a case-by-case basis. In practice many sub-CAs want to
operate their own “root” that can be secured off-line.
* Enterprise sub-CAs can only issue to Subscribers as defined in their
contract. Subscribers of S/MIME client certificates are employees,
groups of employees, or business partners that use the certificates for
enterprise business purposes. Subscribers of SSL certificates are the
enterprise or affiliate that has registered the domain name.
* Enterprise sub-CAs are contractually bound only to issue SSL and/or
S/MIME certificates with domains registered to the enterprise or
enterprise affiliate.
All certificates issued by an enterprise sub-CA must contain the
organization name of the enterprise or enterprise affiliate. Use of
certificates must be restricted by EKU.
* All enterprise sub-CAs are subject to an annual audit to be conducted
by an independent security auditor. In the past, Entrust allowed audits
to be conducted in accordance with criteria specified in the sub-CA
agreement. Entrust has revised all agreements to require annual audits
to be conducted in accordance with one of the audit standards as
specified in the Mozilla and Microsoft CA policies.
Third-Party Public Subordinate CAs
* Entrust (2048) Root CA has cross-signed CAs from three (3)
organizations that can issue sub-CA or end entity certificates to third
parties. These are Comodo, DigiCert and LAWtrust.
* Comodo and DigiCert are also in the Mozilla root certificate program
and operate their sub-CAs in accordance with the same CP/CPS document as
their roots.
* LAWtrust issues client certificates to third parties and has been
authorized to issue one enterprise sub-CA certificate. Below is the
requested information for LAWtrust.
1. LAW Trusted Third Party Services (Pty) Ltd, aka LAWtrust
2. LAWtrust website - https://www.lawtrust.co.za/index.php
LAWtrust repository -
https://www.lawtrust.co.za/index.php?option=com_content&view=article&id=70&Itemid=80
3. Sub-CA cert download page – see LAWtrust repository
4. LAWtrust has two CAs under the Entrust root. One CA issues only
issues third party client certificates. The other sub-CA has only issued
one enterprise sub-CA certificate which in turn only issues enterprise
client certificates.
5. CPS link – see LAWtrust repository
6. Email address ownership control is done in accordance with paragraph
3.2.4 of the LAWtrust CPS. Here is the text: In cases where the
LAWtrust Certificate will be used for digitally signing and/or
encrypting eMail the LAWtrust RA shall establish reasonable proof that
the person or entity submitting the certificate request controls the
eMail account associated with the eMail address referenced in the
LAWtrust Certificate.
7. LAWtrust does not issue SSL certificates.
8. Problematic Practices – none identified
9. LAWtrust is audited annually by KPMG according to the WebTrust for CA
criteria.
10. LAWtrust issues a CRL at least every 24 hours valid for 24 per CPS
4.9.5. LAWtrust publishes revoked certificate serial numbers to the CRL
within 48 hours of revocation request per CPS 4.9.3.
11. LAWtrust does not support OCSP.
The request is to keep all three trust bits enabled.
* CPS section 3.1.10: Registration Authorities operating under the
Entrust Certification Authorities shall use reasonable means to confirm
the Applicant or Subscriber has control of the domain names to be
included in the Entrust Certificate. The Registration Authority shall
check the WHOIS record to determine who the top level domain (TLD) is
registered to.
The authorization to use the domain is done by contacting an
authorization contact at the entity that registered the domain name or
by contacting a user identified in the WHOIS record.
If contacting a user identified in the WHOIS record by email, then only
the following emails addresses may be used:
(i) Supplied by the Domain Name Registrar;
(ii) Taken from the Domain Name Registrant’s “registrant”, “technical”,
or “administrative” contact information, as it appears in the Domain’s
WHOIS record; or;
(iii) By prepending a local part to a Domain Name as follows:
a. Local part - One of the following: ‘admin’, ‘administrator’,
‘webmaster’, ‘hostmaster’, or ‘postmaster’; and
b. Domain Name – Formed by pruning zero or more components from the
Registered Domain Name or the requested Fully Qualified Domain Name.
* CPS section 3.1.11: Registration Authorities operating under the
Entrust Certification Authorities shall use reasonable means to confirm
the Applicant or Subscriber has control of the email address to be
included in the Entrust Certificate. The email address for Entrust
Client Certificates is confirmed using the email through the enrollment
process.
* Entrust only issues Code Signing certificates to organizations.
Organization identity information and authorization is verified the same
as with Entrust EV SSL certificates.
* EV CPS section 3.1.8: Registration Authorities operating under the
Entrust EV SSL Certification Authorities shall determine whether the
organizational identity, legal existence, physical existence,
operational existence, and domain name provided with an Entrust EV SSL
Certificate Application are consistent with the requirements set forth
in the Guidelines published by the CA/Browser Forum.
* EV CPS section 3.1.9: Registration Authorities operating under the
Entrust EV SSL Certification Authorities shall perform a verification of
the identity and authority of the Contract Signer, the Certificate
Approver, and the Certificate Requestor associated with EV SSL
Certificate Applications that are submitted by an Applicant or
Subscriber. In order to establish the accuracy of an individual
identity, the Registration Authority operating under an Entrust EV SSL
Certification Authority shall perform identity and authority
verification consistent with the requirements set forth in the
Guidelines published by the CA/Browser Forum.
* EV CPS section 3.1: Before issuing an EV SSL Certificate, the Entrust
EV SSL Certification Authorities ensure that all Subject organization
information in the EV SSL Certificate conforms to the requirements of,
and has been verified in accordance with, the procedures prescribed in
this CPS and the Guidelines published by the CA/Browser Forum and
matches the information confirmed and documented by the Registration
Authority pursuant to its verification processes. Such verification
processes are intended accomplish the following:
(i) Verify the Applicant’s existence and identity, including;
a. Verify the Applicant’s legal existence and identity (as stipulated in
the Guidelines),
b. Verify the Applicant’s physical existence (business presence at a
physical address), and
c. Verify the Applicant’s operational existence (business activity).
(ii) Verify the Applicant is a registered holder or has exclusive
control of the domain name to be included in the EV SSL Certificate; and
(iii) Verify the Applicant’s authorization for the EV SSL Certificate,
including;
a. Verify the name, title, and authority of the Contract Signer,
Certificate Approver, and Certificate Requester;
b. Verify that Contract Signer signed the Subscription Agreement; and
c. Verify that a Certificate Approver has signed or otherwise approved
the EV SSL Certificate Request.
* EV Policy OID: 2.16.840.1.114028.10.1.2
* Root Cert URL
https://bugzilla.mozilla.org/attachment.cgi?id=567058
* Test Websites
https://2048test.entrust.net/
https://evtest2048.entrust.net/
* CRL
http://crl.entrust.net/2048ca.crl
http://crl.entrust.net/level1c.crl (NextUpdate: 7 days)
CPS section 4.4.3: CRLs updated within 24 hours of revocation request.
CPS section 4.4.9: CRLs for end entities shall be issued at least once
every seven days.
* OCSP
http://ocsp.entrust.net/
CPS section 4.4.11: OCSP responses for end entities issued at least
every 4 days, with maximum expiration time of 10 days.
* Audit: Annual audits are performed by Deloitte and Touche according to
the WebTrust CA and WebTrust EV criteria and posted on the webtrust.org
website.
https://entrust.webtrust.org/ViewSeal?id=328
* Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices)
** Third-party RAs and externally-operated subCA, see information above.
** Entrust does issue SSL certificates with internal host names and
reserved IP addresses. Entrust is phasing this practice out in
accordance with the CAB Forum Baseline Requirements.
This begins the discussion of the request from Entrust to replace the
“Entrust.net Certification Authority (2048)” root certificate, keep all
three trust bits enabled, and also enable EV. 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
(2048)” root certificate. Several years ago Entrust realized that the
certificate was missing the Basic Constraint Extension, so they issued a
new root certificate to replace it. The root cert to be replaced has
all three trust bits enabled. This request is to also enable EV for
this root cert.
Entrust is a commercial CA serving the global market for SSL web
certificates. Entrust also issues certificates to subordinate CAs for
enterprise and commercial use. Entrust has enterprise subordinate CAs
that issue certificates for SSL and S/MIME internal use. There are also
commercial subordinate CAs that issue SSL certificates and S/MIME
certificates to the public.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=694536
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#Entrust
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=723649
Noteworthy points:
* The primary documents are the CPS and EV CPS documents, which are
provided in English.
Document Repository: http://www.entrust.net/CPS
CPS: http://www.entrust.net/CPS/pdf/ssl-cps-250612-v2-8.pdf
EV CPS: http://www.entrust.net/CPS/pdf/evssl_cps_english250612.pdf
The “Entrust.net Certification Authority (2048)” root certificate is
already included in NSS. It has been updated to extend the validity
period and to correct the Basic Constraints extension. This root is
Entrust's primary trust anchor for commercially issuing SSL, S/MIME, and
Code Signing certificates.
This root signs both internally-operated subCAs and externally-operated
subCAs. It has also been used to cross-sign other roots in Mozilla’s
Program. Details are provided in the CAInformation document attached to
the bug.
Enterprise RAs
* Entrust has Enterprise administrator accounts that allow customers to
issue certificates on demand for pre-verified domains and organization
names. Software run at Entrust limits issuance to the pre-verified
domains. All enterprise administrators authenticate with
username/password and a second factor.
Third-Party Private (or Enterprise) Subordinate CAs
* Generally Enterprise sub-CAs are Entrust PKI software customers
looking for public trust in the certificates they are issuing for
enterprise business purposes.
* Enterprise CAs have generally been allowed to have a cross-certificate
as they are also Entrust PKI software customers. Entrust is planning to
stop the practice of issuing cross-certificates to third parties that
operate their own CA. No new customers of this type will be added, and
existing customers will be transitioned to a different solution.
* Third Party sub-CAs must develop their own CP/CPS documentation, which
must be no less stringent than the Entrust CPS and meet the requirements
of the cross-certificate agreement. Entrust is in the process of
updating these third party sub-CAs to also meet the requirements of the
CAB Forum Baseline Requirements.
* Sub-CAs domains are currently only constrained by contract. In some
cases sub-CAs are allowed to issue their own subordinates. This is
assessed on a case-by-case basis. In practice many sub-CAs want to
operate their own “root” that can be secured off-line.
* Enterprise sub-CAs can only issue to Subscribers as defined in their
contract. Subscribers of S/MIME client certificates are employees,
groups of employees, or business partners that use the certificates for
enterprise business purposes. Subscribers of SSL certificates are the
enterprise or affiliate that has registered the domain name.
* Enterprise sub-CAs are contractually bound only to issue SSL and/or
S/MIME certificates with domains registered to the enterprise or
enterprise affiliate.
All certificates issued by an enterprise sub-CA must contain the
organization name of the enterprise or enterprise affiliate. Use of
certificates must be restricted by EKU.
* All enterprise sub-CAs are subject to an annual audit to be conducted
by an independent security auditor. In the past, Entrust allowed audits
to be conducted in accordance with criteria specified in the sub-CA
agreement. Entrust has revised all agreements to require annual audits
to be conducted in accordance with one of the audit standards as
specified in the Mozilla and Microsoft CA policies.
Third-Party Public Subordinate CAs
* Entrust (2048) Root CA has cross-signed CAs from three (3)
organizations that can issue sub-CA or end entity certificates to third
parties. These are Comodo, DigiCert and LAWtrust.
* Comodo and DigiCert are also in the Mozilla root certificate program
and operate their sub-CAs in accordance with the same CP/CPS document as
their roots.
* LAWtrust issues client certificates to third parties and has been
authorized to issue one enterprise sub-CA certificate. Below is the
requested information for LAWtrust.
1. LAW Trusted Third Party Services (Pty) Ltd, aka LAWtrust
2. LAWtrust website - https://www.lawtrust.co.za/index.php
LAWtrust repository -
https://www.lawtrust.co.za/index.php?option=com_content&view=article&id=70&Itemid=80
3. Sub-CA cert download page – see LAWtrust repository
4. LAWtrust has two CAs under the Entrust root. One CA issues only
issues third party client certificates. The other sub-CA has only issued
one enterprise sub-CA certificate which in turn only issues enterprise
client certificates.
5. CPS link – see LAWtrust repository
6. Email address ownership control is done in accordance with paragraph
3.2.4 of the LAWtrust CPS. Here is the text: In cases where the
LAWtrust Certificate will be used for digitally signing and/or
encrypting eMail the LAWtrust RA shall establish reasonable proof that
the person or entity submitting the certificate request controls the
eMail account associated with the eMail address referenced in the
LAWtrust Certificate.
7. LAWtrust does not issue SSL certificates.
8. Problematic Practices – none identified
9. LAWtrust is audited annually by KPMG according to the WebTrust for CA
criteria.
10. LAWtrust issues a CRL at least every 24 hours valid for 24 per CPS
4.9.5. LAWtrust publishes revoked certificate serial numbers to the CRL
within 48 hours of revocation request per CPS 4.9.3.
11. LAWtrust does not support OCSP.
The request is to keep all three trust bits enabled.
* CPS section 3.1.10: Registration Authorities operating under the
Entrust Certification Authorities shall use reasonable means to confirm
the Applicant or Subscriber has control of the domain names to be
included in the Entrust Certificate. The Registration Authority shall
check the WHOIS record to determine who the top level domain (TLD) is
registered to.
The authorization to use the domain is done by contacting an
authorization contact at the entity that registered the domain name or
by contacting a user identified in the WHOIS record.
If contacting a user identified in the WHOIS record by email, then only
the following emails addresses may be used:
(i) Supplied by the Domain Name Registrar;
(ii) Taken from the Domain Name Registrant’s “registrant”, “technical”,
or “administrative” contact information, as it appears in the Domain’s
WHOIS record; or;
(iii) By prepending a local part to a Domain Name as follows:
a. Local part - One of the following: ‘admin’, ‘administrator’,
‘webmaster’, ‘hostmaster’, or ‘postmaster’; and
b. Domain Name – Formed by pruning zero or more components from the
Registered Domain Name or the requested Fully Qualified Domain Name.
* CPS section 3.1.11: Registration Authorities operating under the
Entrust Certification Authorities shall use reasonable means to confirm
the Applicant or Subscriber has control of the email address to be
included in the Entrust Certificate. The email address for Entrust
Client Certificates is confirmed using the email through the enrollment
process.
* Entrust only issues Code Signing certificates to organizations.
Organization identity information and authorization is verified the same
as with Entrust EV SSL certificates.
* EV CPS section 3.1.8: Registration Authorities operating under the
Entrust EV SSL Certification Authorities shall determine whether the
organizational identity, legal existence, physical existence,
operational existence, and domain name provided with an Entrust EV SSL
Certificate Application are consistent with the requirements set forth
in the Guidelines published by the CA/Browser Forum.
* EV CPS section 3.1.9: Registration Authorities operating under the
Entrust EV SSL Certification Authorities shall perform a verification of
the identity and authority of the Contract Signer, the Certificate
Approver, and the Certificate Requestor associated with EV SSL
Certificate Applications that are submitted by an Applicant or
Subscriber. In order to establish the accuracy of an individual
identity, the Registration Authority operating under an Entrust EV SSL
Certification Authority shall perform identity and authority
verification consistent with the requirements set forth in the
Guidelines published by the CA/Browser Forum.
* EV CPS section 3.1: Before issuing an EV SSL Certificate, the Entrust
EV SSL Certification Authorities ensure that all Subject organization
information in the EV SSL Certificate conforms to the requirements of,
and has been verified in accordance with, the procedures prescribed in
this CPS and the Guidelines published by the CA/Browser Forum and
matches the information confirmed and documented by the Registration
Authority pursuant to its verification processes. Such verification
processes are intended accomplish the following:
(i) Verify the Applicant’s existence and identity, including;
a. Verify the Applicant’s legal existence and identity (as stipulated in
the Guidelines),
b. Verify the Applicant’s physical existence (business presence at a
physical address), and
c. Verify the Applicant’s operational existence (business activity).
(ii) Verify the Applicant is a registered holder or has exclusive
control of the domain name to be included in the EV SSL Certificate; and
(iii) Verify the Applicant’s authorization for the EV SSL Certificate,
including;
a. Verify the name, title, and authority of the Contract Signer,
Certificate Approver, and Certificate Requester;
b. Verify that Contract Signer signed the Subscription Agreement; and
c. Verify that a Certificate Approver has signed or otherwise approved
the EV SSL Certificate Request.
* EV Policy OID: 2.16.840.1.114028.10.1.2
* Root Cert URL
https://bugzilla.mozilla.org/attachment.cgi?id=567058
* Test Websites
https://2048test.entrust.net/
https://evtest2048.entrust.net/
* CRL
http://crl.entrust.net/2048ca.crl
http://crl.entrust.net/level1c.crl (NextUpdate: 7 days)
CPS section 4.4.3: CRLs updated within 24 hours of revocation request.
CPS section 4.4.9: CRLs for end entities shall be issued at least once
every seven days.
* OCSP
http://ocsp.entrust.net/
CPS section 4.4.11: OCSP responses for end entities issued at least
every 4 days, with maximum expiration time of 10 days.
* Audit: Annual audits are performed by Deloitte and Touche according to
the WebTrust CA and WebTrust EV criteria and posted on the webtrust.org
website.
https://entrust.webtrust.org/ViewSeal?id=328
* Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices)
** Third-party RAs and externally-operated subCA, see information above.
** Entrust does issue SSL certificates with internal host names and
reserved IP addresses. Entrust is phasing this practice out in
accordance with the CAB Forum Baseline Requirements.
This begins the discussion of the request from Entrust to replace the
“Entrust.net Certification Authority (2048)” root certificate, keep all
three trust bits enabled, and also enable EV. 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
Kathleen Wilson
Mar 12, 2013, 1:48:28 PM3/12/13
to mozilla-dev-s...@lists.mozilla.org
On 3/11/13 6:01 PM, Kathleen Wilson wrote:
> Entrust has applied to replace the “Entrust.net Certification Authority
> (2048)” root certificate. Several years ago Entrust realized that the
> certificate was missing the Basic Constraint Extension, so they issued a
> new root certificate to replace it. The root cert to be replaced has
> all three trust bits enabled. This request is to also enable EV for
> this root cert.
>
> Entrust is a commercial CA serving the global market for SSL web
> certificates. Entrust also issues certificates to subordinate CAs for
> enterprise and commercial use. Entrust has enterprise subordinate CAs
> that issue certificates for SSL and S/MIME internal use. There are also
> commercial subordinate CAs that issue SSL certificates and S/MIME
> certificates to the public.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=694536
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#Entrust
>
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=723649
>
All,
> Entrust has applied to replace the “Entrust.net Certification Authority
> (2048)” root certificate. Several years ago Entrust realized that the
> certificate was missing the Basic Constraint Extension, so they issued a
> new root certificate to replace it. The root cert to be replaced has
> all three trust bits enabled. This request is to also enable EV for
> this root cert.
>
> Entrust is a commercial CA serving the global market for SSL web
> certificates. Entrust also issues certificates to subordinate CAs for
> enterprise and commercial use. Entrust has enterprise subordinate CAs
> that issue certificates for SSL and S/MIME internal use. There are also
> commercial subordinate CAs that issue SSL certificates and S/MIME
> certificates to the public.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=694536
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#Entrust
>
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=723649
>
Please review and comment on this request soon, because we would like to
do this root cert replacement in the next batch of root changes to NSS.
This issue of the old certificate missing the basic constraint extension
is causing problems for new development work.
Thanks,
Kathleen
Erwann Abalea
Mar 12, 2013, 3:28:56 PM3/12/13
to
Le mardi 12 mars 2013 02:01:38 UTC+1, Kathleen Wilson a écrit :
[...]
[...]
That last certificate has expired and is directly signed by the root, it shouldn't get the EV UI (that's forbidden by CABF BR). But you already know it, and it's a test certificate.
There's also not enough entropy in the serial number and you're still using sha1WithRSA, but you'll change that soon, based on your responses to January communication from Mozilla.
> This begins the discussion of the request from Entrust to replace the
> “Entrust.net Certification Authority (2048)” root certificate, keep all
> three trust bits enabled, and also enable EV. 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.
No outstanding issue for me.
[...]
> * All enterprise sub-CAs are subject to an annual audit to be conducted
> by an independent security auditor. In the past, Entrust allowed audits
> to be conducted in accordance with criteria specified in the sub-CA
> agreement. Entrust has revised all agreements to require annual audits
> to be conducted in accordance with one of the audit standards as
> specified in the Mozilla and Microsoft CA policies.
>
> Third-Party Public Subordinate CAs
[...]
> by an independent security auditor. In the past, Entrust allowed audits
> to be conducted in accordance with criteria specified in the sub-CA
> agreement. Entrust has revised all agreements to require annual audits
> to be conducted in accordance with one of the audit standards as
> specified in the Mozilla and Microsoft CA policies.
>
> Third-Party Public Subordinate CAs
> 11. LAWtrust does not support OCSP.
OCSP support for verification of subscriber certificates is a MUST, as defined by the BR. They'll probably fail their next audit, right?
[...]
That last certificate has expired and is directly signed by the root, it shouldn't get the EV UI (that's forbidden by CABF BR). But you already know it, and it's a test certificate.
There's also not enough entropy in the serial number and you're still using sha1WithRSA, but you'll change that soon, based on your responses to January communication from Mozilla.
> This begins the discussion of the request from Entrust to replace the
> “Entrust.net Certification Authority (2048)” root certificate, keep all
> three trust bits enabled, and also enable EV. 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.
Erwann Abalea
Mar 12, 2013, 3:34:04 PM3/12/13
to
Le mardi 12 mars 2013 18:48:28 UTC+1, Kathleen Wilson a écrit :
[...]
[...]
> Please review and comment on this request soon, because we would like to
> do this root cert replacement in the next batch of root changes to NSS.
> This issue of the old certificate missing the basic constraint extension
> is causing problems for new development work.
I'm curious about what causes the problem with the lack of a BasicConstraints extension, as it's not mandatory for a trust anchor. Is it a side effect of DANE support?
> do this root cert replacement in the next batch of root changes to NSS.
> This issue of the old certificate missing the basic constraint extension
> is causing problems for new development work.
Kathleen Wilson
Mar 12, 2013, 6:38:13 PM3/12/13
to mozilla-dev-s...@lists.mozilla.org
From bug #849833: "We're working on an application that consumes the
Mozilla root CA list, and above certificate is causing problems."
Kathleen
Bruce
Mar 12, 2013, 10:22:40 PM3/12/13
to
On Tuesday, March 12, 2013 3:28:56 PM UTC-4, Erwann Abalea wrote:
> Le mardi 12 mars 2013 02:01:38 UTC+1, Kathleen Wilson a écrit :
>
>
>
> [...]
>
> > * All enterprise sub-CAs are subject to an annual audit to be conducted
>
> > by an independent security auditor. In the past, Entrust allowed audits
>
> > to be conducted in accordance with criteria specified in the sub-CA
>
> > agreement. Entrust has revised all agreements to require annual audits
>
> > to be conducted in accordance with one of the audit standards as
>
> > specified in the Mozilla and Microsoft CA policies.
>
> >
>
> > Third-Party Public Subordinate CAs
>
> [...]
>
> > 11. LAWtrust does not support OCSP.
>
>
>
> OCSP support for verification of subscriber certificates is a MUST, as defined by the BR. They'll probably fail their next audit, right?
The BR only supports SSL; however, LAWtrust does not issue SSL. As such no OCSP should not be an issue.
> Le mardi 12 mars 2013 02:01:38 UTC+1, Kathleen Wilson a écrit :
>
>
>
> [...]
>
> > * All enterprise sub-CAs are subject to an annual audit to be conducted
>
> > by an independent security auditor. In the past, Entrust allowed audits
>
> > to be conducted in accordance with criteria specified in the sub-CA
>
> > agreement. Entrust has revised all agreements to require annual audits
>
> > to be conducted in accordance with one of the audit standards as
>
> > specified in the Mozilla and Microsoft CA policies.
>
> >
>
> > Third-Party Public Subordinate CAs
>
> [...]
>
> > 11. LAWtrust does not support OCSP.
>
>
>
> OCSP support for verification of subscriber certificates is a MUST, as defined by the BR. They'll probably fail their next audit, right?
>
>
>
> [...]
>
> > * Test Websites
>
> > https://2048test.entrust.net/
>
> > https://evtest2048.entrust.net/
>
>
>
> That last certificate has expired and is directly signed by the root, it shouldn't get the EV UI (that's forbidden by CABF BR). But you already know it, and it's a test certificate.
>
>
>
> There's also not enough entropy in the serial number and you're still using sha1WithRSA, but you'll change that soon, based on your responses to January communication from Mozilla.
Entropy is currently supported in the Valid From/To fields. We will move to entropy in the serial number in the future.
>
>
> [...]
>
> > * Test Websites
>
> > https://2048test.entrust.net/
>
> > https://evtest2048.entrust.net/
>
>
>
> That last certificate has expired and is directly signed by the root, it shouldn't get the EV UI (that's forbidden by CABF BR). But you already know it, and it's a test certificate.
>
>
>
> There's also not enough entropy in the serial number and you're still using sha1WithRSA, but you'll change that soon, based on your responses to January communication from Mozilla.
The choice of SHA1 or SHA2 is offered and it is the Subscriber's decision to choose which signing algorithm is chosen.
Erwann Abalea
Mar 13, 2013, 7:05:30 AM3/13/13
to
Le mercredi 13 mars 2013 03:22:40 UTC+1, Bruce a écrit :
> On Tuesday, March 12, 2013 3:28:56 PM UTC-4, Erwann Abalea wrote:
> > Le mardi 12 mars 2013 02:01:38 UTC+1, Kathleen Wilson a écrit :
> > [...]
> > > * All enterprise sub-CAs are subject to an annual audit to be conducted
> > > by an independent security auditor. In the past, Entrust allowed audits
> > > to be conducted in accordance with criteria specified in the sub-CA
> > > agreement. Entrust has revised all agreements to require annual audits
> > > to be conducted in accordance with one of the audit standards as
> > > specified in the Mozilla and Microsoft CA policies.
>
> > > Third-Party Public Subordinate CAs
> > [...]
> > > 11. LAWtrust does not support OCSP.
>
> > OCSP support for verification of subscriber certificates is a MUST, as defined by the BR. They'll probably fail their next audit, right?
>
> The BR only supports SSL; however, LAWtrust does not issue SSL. As such no OCSP should not be an issue.
You're right, and it was mentioned. My mistake.
> On Tuesday, March 12, 2013 3:28:56 PM UTC-4, Erwann Abalea wrote:
> > Le mardi 12 mars 2013 02:01:38 UTC+1, Kathleen Wilson a écrit :
> > [...]
> > > * All enterprise sub-CAs are subject to an annual audit to be conducted
> > > by an independent security auditor. In the past, Entrust allowed audits
> > > to be conducted in accordance with criteria specified in the sub-CA
> > > agreement. Entrust has revised all agreements to require annual audits
> > > to be conducted in accordance with one of the audit standards as
> > > specified in the Mozilla and Microsoft CA policies.
>
> > > Third-Party Public Subordinate CAs
> > [...]
> > > 11. LAWtrust does not support OCSP.
>
> > OCSP support for verification of subscriber certificates is a MUST, as defined by the BR. They'll probably fail their next audit, right?
>
> The BR only supports SSL; however, LAWtrust does not issue SSL. As such no OCSP should not be an issue.
[...]
> > There's also not enough entropy in the serial number and you're still using sha1WithRSA, but you'll change that soon, based on your responses to January communication from Mozilla.
>
> Entropy is currently supported in the Valid From/To fields. We will move to entropy in the serial number in the future.
I don't think it's the same kind of "entropy". Inaccuracy in the validFrom/To fields doesn't really count.
>
> Entropy is currently supported in the Valid From/To fields. We will move to entropy in the serial number in the future.
CABF BR and Mozilla ask for 20 bits of entropy. It is achievable with the validFrom/To fields combined (by playing only on the time, 16 bits are reachable for each validFrom/To field). But the subscriber is generally unhappy to receive a certificate he can't use right now, so useful entropy in the time fields is reduced; if you play with the entire minute+second fields, nearly 2*12 bits can be stored.
(Microsoft ask for 64 bits, out of reach for the date/time fields alone).
You'll move to serialNumber in the future, SHA1 isn't collision broken yet, so that's not a blocker.
> The choice of SHA1 or SHA2 is offered and it is the Subscriber's decision to choose which signing algorithm is chosen.
Again, I'm fine with that request.
Kathleen Wilson
Mar 15, 2013, 7:56:04 PM3/15/13
to mozilla-dev-s...@lists.mozilla.org
> Entrust has applied to replace the “Entrust.net Certification Authority
> (2048)” root certificate. Several years ago Entrust realized that the
> certificate was missing the Basic Constraint Extension, so they issued a
> new root certificate to replace it. The root cert to be replaced has
> all three trust bits enabled. This request is to also enable EV for
> this root cert.
> (2048)” root certificate. Several years ago Entrust realized that the
> certificate was missing the Basic Constraint Extension, so they issued a
> new root certificate to replace it. The root cert to be replaced has
> all three trust bits enabled. This request is to also enable EV for
> this root cert.
On 3/13/13 4:05 AM, Erwann Abalea wrote:
>
> Again, I'm fine with that request.
>
Thanks Erwann!
>
> Again, I'm fine with that request.
>
Does anyone else want to comment on this request before I close this
discussion and recommend approval in the bug?
Kathleen
Gervase Markham
Mar 18, 2013, 7:45:15 AM3/18/13
to mozilla-dev-s...@lists.mozilla.org
On 12/03/13 19:34, Erwann Abalea wrote:
> I'm curious about what causes the problem with the lack of a
> BasicConstraints extension, as it's not mandatory for a trust anchor.
> Is it a side effect of DANE support?
You'd need to ask Kai, who wrote the bit quoted by Kathleen; comments in
> I'm curious about what causes the problem with the lack of a
> BasicConstraints extension, as it's not mandatory for a trust anchor.
> Is it a side effect of DANE support?
the bug suggest that it's a Red Hat product that has this issue.
Gerv
Kathleen Wilson
Mar 20, 2013, 1:45:24 PM3/20/13
to mozilla-dev-s...@lists.mozilla.org
On 3/15/13 4:56 PM, Kathleen Wilson wrote:
>> Entrust has applied to replace the �Entrust.net Certification Authority
>> (2048)� root certificate. Several years ago Entrust realized that the
discussion about the request from Entrust to update the �Entrust.net
Certification Authority (2048)� root certificate, keep all three trust
EV-enablement will be on hold until Entrust has successfully completed
EV-testing (https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version).
https://bugzilla.mozilla.org/show_bug.cgi?id=694536
Any further follow-up on this request should be added directly to the bug.
Thanks,
Kathleen
>> Entrust has applied to replace the �Entrust.net Certification Authority
>> (2048)� root certificate. Several years ago Entrust realized that the
>> certificate was missing the Basic Constraint Extension, so they issued a
>> new root certificate to replace it. The root cert to be replaced has
>> all three trust bits enabled. This request is to also enable EV for
>> this root cert.
>
> On 3/13/13 4:05 AM, Erwann Abalea wrote:
>>
>> Again, I'm fine with that request.
>>
>
>
> Thanks Erwann!
>
> Does anyone else want to comment on this request before I close this
> discussion and recommend approval in the bug?
>
> Kathleen
>
Thank you to those of you who reviewed and contributed to this
>> new root certificate to replace it. The root cert to be replaced has
>> all three trust bits enabled. This request is to also enable EV for
>> this root cert.
>
> On 3/13/13 4:05 AM, Erwann Abalea wrote:
>>
>> Again, I'm fine with that request.
>>
>
>
> Thanks Erwann!
>
> Does anyone else want to comment on this request before I close this
> discussion and recommend approval in the bug?
>
> Kathleen
>
discussion about the request from Entrust to update the �Entrust.net
Certification Authority (2048)� root certificate, keep all three trust
bits enabled, and also enable EV.
I am closing this discussion, and I will recommend approval in the bug.
EV-enablement will be on hold until Entrust has successfully completed
EV-testing (https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version).
https://bugzilla.mozilla.org/show_bug.cgi?id=694536
Any further follow-up on this request should be added directly to the bug.
Thanks,
Kathleen
0 new messages