On Monday, December 1, 2014 4:29:31 PM UTC-6, Kathleen Wilson wrote: > Entrust has applied to include the "Entrust Root Certification Authority > - G2" and "Entrust Root Certification Authority - EC1" root > certificates, turn on all three trust bits for both, and enable EV > treatment for both. These new root certificates are intended to > eventually replace Entrust's currently included SHA-1 root certificates. > > 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=849950 > > And in the pending certificates list: > http://www.mozilla.org/projects/security/certs/pending/ > > Summary of Information Gathered and Verified: > https://bugzilla.mozilla.org/attachment.cgi?id=8513832 > > Noteworthy points: > I am posting to express my support that Mozilla accept these changes. I have been using these roots for websites accessed by other browsers and have not had any issues. I don't see anything in the CPS that would be a concern or deviate from standard practices. Accepting these changes offers support for current security standards.
> * The primary documents are in English > > Document Repository: http://www.entrust.net/CPS > > CPS: > http://www.entrust.net/CPS/pdf/SSL-CPS-English-20140304-Version-2-11.pdf > > EV CPS: http://www.entrust.net/CPS/pdf/EV-SSL-CPS-English-20140304-v1-6.pdf > > * CA Hierarchy: These G2 and EC1 roots will have internally-operated > subordinate CAs, and will eventually have externally-operated > subordinate CAs. The G2 root is intended to eventually replace Entrust's > SHA-1 root certificates, so the externally-operated subordinate CAs will > eventually be migrated to the new G2 CA hierarchy. > > ** Entrust's Third Party Subordinate CA Disclosure, including CP/CPS and > audit statements: > http://www.entrust.net/about/third-party-sub-ca.htm > > ** CPS Appendix B: Third Party Subordinate CAs are assessed to meet the > requirements of the CP and/or CPS on an annual basis using one of the > audit criteria specified in the Baseline Requirements. > > * This request is to turn on all three trust bits, and enable EV > treatment for both root certificates. > > CPS section 1.4: Entrust Certificates issued to individuals are > typically used to sign and encrypt e-mail and to authenticate to > applications (client authentication). > Class 1 Certificates is considered to be low assurance, as the > verification method simply confirms that the Subscriber controls the > asserted email address. No verification checks of the Subscriber's > identity are performed. > Class 2 Certificates provide a greater level of assurance over Class 1 > Certificates, because in addition to email address control, basic > verification steps are performed to confirm the identity of the Subscriber. > > CPS 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 pre-pending 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 e-mail address to be included > in the Entrust Certificate. The e-mail address for Entrust Client > Certificates is confirmed using the e-mail 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 less, of course, the domain information. > > 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 URLs > https://bugzilla.mozilla.org/attachment.cgi?id=767483 > https://bugzilla.mozilla.org/attachment.cgi?id=813664 > > * Test Websites > https://validg2.entrust.net/ > https://validec.entrust.net > > * CRL > http://crl.entrust.net/g2ca.crl > http://crl.entrust.net/ec1root.crl > > * OCSP > http://ocsp.entrust.net/ > CPS section 4.4.11: OCSP responses for end-entities issued at least > every 4 days, with max expiration time of 10 days. > > * Audit: Annual audits are performed by Deloitte according to the > WebTrust CA, WebTrust BR, and WebTrust EV audit criteria. > https://cert.webtrust.org/SealFile?seal=328&file=pdf > > * Potentially Problematic Practices > (http://wiki.mozilla.org/CA:Problematic_Practices) > > ** Delegation of Domain / Email validation to third parties > *** Entrust allows third party domain/email verification. All third > party certificate requests are reviewed by Entrust before issuance. > According to Entrust's CPS, all subordinate CAs are required to be > audited annually, whether they are technically constrained or not. Third > Party RAs are also audited annually by a third party auditor. > *** CPS Appendix B: Entrust operated subordinate CAs are managed in > accordance with this CPS or are operated in accordance with their own CP > and/or CPS which meets the minimum requirements of this CPS. > *** CPS Appendix B: Third Party Subordinate CAs are assessed to meet the > requirements of the CP and/or CPS on an annual basis using one of the > audit criteria specified in the Baseline Requirements. > *** 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 four audit standards as > specified in the Baseline Requirements. > > ** Issuing SSL Certificates for Internal Domains > Entrust does issue SSL certificates with internal host names and > reserved IP addresses. Entrust plans to phase this practice out in > accordance with the Baseline Requirements. > > This begins the discussion of the request from Entrust to include the > "Entrust Root Certification Authority - G2" and "Entrust Root > Certification Authority - EC1" root certificates, turn on all three > trust bits for both, and enable EV treatment for both. At the conclusion > of this discussion I will provide a summary of issues noted and action > items. If there are outstanding issues, then an additional discussion > may be needed as follow-up. If there are no outstanding issues, then I > will recommend approval of this request in the bug. > > Kathleen _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
