This request from Symantec is to include the following 4 root certificates and enable the Email trust bit for them. 1) Symantec Class 1 Public Primary Certification Authority - G6 2) Symantec Class 2 Public Primary Certification Authority - G6 3) Symantec Class 1 Public Primary Certification Authority - G4 4) Symantec Class 2 Public Primary Certification Authority - G4 These Symantec-brand root certs will eventually replace the VeriSign-brand class 1 and 2 root certs that are currently included in NSS. The G6 root certs are SHA-256, and the G4 root certs are ECC.
The request is documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=833986 And in the pending certificates list: https://wiki.mozilla.org/CA:PendingCAs Summary of Information Gathered and Verified: https://bug833986.bmoattachments.org/attachment.cgi?id=8798532 * Root Certificate Download URLs: https://www.symantec.com/content/en/us/enterprise/verisign/roots/PCA_1_G6.pem https://www.symantec.com/content/en/us/enterprise/verisign/roots/PCA_2_G6.pem https://www.symantec.com/content/en/us/enterprise/verisign/roots/Symantec_Class_1_Public_Primary_Certification_Authority_G4.pem https://www.symantec.com/content/en/us/enterprise/verisign/roots/Symantec_Class_2_Public_Primary_Certification_Authority_G4.pem * The primary documents such as CP and CPS are provided in English. CA Document Repository: https://www.symantec.com/about/profile/policies/repository.jsp CP Document: https://www.symantec.com/content/en/us/about/media/repository/stn-cp.pdf CPS Document: https://www.symantec.com/content/en/us/about/media/repository/stn-cps.pdf * CA Hierarchy: These root certs will be used to sign Class 1 and Class 2 subordinate CAs for SMIME and Client Auth purposes. SubCA keys will operate at Symantec or Symantec Affiliate sites. * This request is to turn on the Email trust bit for these root certs. ** CP and CPS section 3.2.2: Where a domain name or e-mail address is included in the certificate Symantec or an Affiliate authenticates the Organization’s right to use that domain name either as a fully qualified Domain name or an e-mail domain. ** CP and CPS section 3.2.3: *** Class 1 -- No identity authentication. Limited confirmation that the certificate subscriber has access to the email address. Symantec performs a challenge-response type of procedure in which Symantec sends email to the email address to be included in the certificate, containing unpredictable information such as a randomly generated PIN/Password unique to the owner of the email address. The owner of the email address (the subscriber of the certificate) demonstrates control over the email address by using the information within the email, to then proceed with accessing a portal with the unique information sent in the email, to download and install the certificate. *** Class 2 -- Authenticate identity by: Manual check performed by the enterprise administrator customer for each subscriber requesting a certificate, “in which the subscriber receives the certificate via an email sent to the address provided during enrollment” or Passcode-based authentication where a randomly-generated passcode is delivered out-of-band by the enterprise administrator customer to the subscriber entitled to enroll for the certificate, and the subscriber provides this passcode at enrollment time or Comparing information provided by the subscriber to information contained in business records or databases (customer directories such as Active Directory or LDAP. * EV Policy OID: Not Requesting EV treatment and not requesting the Websites trust bit for these root certs. * Test Certs: An example cert chaining up to each root is provided as attachments in https://bugzilla.mozilla.org/show_bug.cgi?id=833986 * CRL URLs: http://crl.ws.symantec.com/pca1-g6.crl http://crl.ws.symantec.com/pca2-g6.crl http://crl.ws.symantec.com/pca1-g4.crl http://crl.ws.symantec.com/pca2-g4.crl * Audit: Annual audits are performed by KPMG according to the WebTrust criteria. https://www.symantec.com/content/en/us/about/media/repository/Symantec-STN-WTCA-2015.pdf https://www.symantec.com/content/en/us/about/media/repository/1_symantec_stn_wtca_6-15-2016.pdf * Potentially Problematic Practices: (http://wiki.mozilla.org/CA:Problematic_Practices) ** Delegation of Domain / Email validation to third parties - CPS section 1.3.2: Third parties, who enter into a contractual relationship with Symantec or an affiliate, may operate their own RA and authorize the issuance of certificates by a STN CA. Third party RAs must abide by all the requirements of the STN CP, the relevant CPS and any Enterprise Service Agreement entered into with Symantec. RAs may, however implement a more restrictive practices based on their internal requirements. ** Allowing external entities to operate subordinate CAs -- CPS section 1.3.1: Symantec enterprise customers may operate their own CAs as a subordinate CA to a public STN PCA. Such a customer enters into a contractual relationship with Symantec to abide by all the requirements of the STN CP and the STN CPS. These subordinate CAs may, however implement more restrictive practices based on their internal requirements. This begins the discussion of this request from Symantec to include the following four Symantec-brand root certificates, and turn on the Email trust bit for all of them. 1) Symantec Class 1 Public Primary Certification Authority - G6 2) Symantec Class 2 Public Primary Certification Authority - G6 3) Symantec Class 1 Public Primary Certification Authority - G4 4) Symantec Class 2 Public Primary Certification Authority - G4 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. Regards Kathleen Wilson and Aaron Wu _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
