Closed Bug 484901 Opened 11 years ago Closed 10 years ago
Add Verisign's SHA256 root
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) Build Identifier: Please accept the attached VeriSign root certificate for inclusion into Mozilla's NSS database. This CA will be used to sign certificates for SSL-enabled servers, and may in the future be used to sign certificates for digitally-signed executable code objects. Name of the CA certificate is VeriSign Universal Root Certification Authority Link to VeriSign's CPS - http://www.verisign.com/repository/CPS/ Link to VeriSign's CP - http://www.verisign.com/repository/vtnCp.html Attestation of our conformance to the stated verification requirements can be found here: http://www.verisign.com/repository/index.html (Click on the "AICPA/CICA WebTrust for Certification Authorities Audit Report" link) Reproducible: Always
The attached file contains Verisign's SHA256 root - VeriSign Universal Root Certification Authority.
Assignee: nobody → kathleen95014
Component: Security → CA Certificates
Product: Firefox → mozilla.org
QA Contact: firefox → ca-certificates
Version: unspecified → other
Accepting this bug. I will begin the Information Gathering and Verification phase soon as described in https://wiki.mozilla.org/CA:How_to_apply In the meantime, please provide the information listed in https://wiki.mozilla.org/CA:Information_checklist
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Hi Jay, There is another Verisign request in the queue for public discussion at https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion http://www.mozilla.org/projects/security/certs/pending/#VeriSign https://bugzilla.mozilla.org/show_bug.cgi?id=409235 Does it make sense to combine these two requests into one public discussion? Or are they sufficiently different that they should be discussed separately? For this request, please provide the information for this root as was provided for the other root in the Information Gathering Document. Note that the potentially problematic practices list has grown, so please review the new list at http://wiki.mozilla.org/CA:Problematic_Practices Thanks, Kathleen
I am now opening the first public discussion period for three requests from VeriSign: #409235 – Add VeriSign Class 3 Public Primary Certificate Authority - G4 (ECC) root certificate and enable all three trust bits. #484901 – Add VeriSign Universal Root Certification Authority (SHA256) root certificate and enable all three trust bits. #490895 – Add 3 roots: VeriSign Class 1 Public Primary Certification Authority (PCA1 G1 SHA1), enable email trust bit. VeriSign Class 2 Public Primary Certification Authority (PCA2 G1 SHA1), enable email trust bit. VeriSign Class 3 Public Primary Certification Authority (PCA3-G1 SHA1), enable all three trust bits, and enable EV. For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding email@example.com mailing list. http://www.mozilla.org/community/developer-forums.html https://lists.mozilla.org/listinfo/dev-security-policy news://news.mozilla.org/mozilla.dev.security.policy The discussion thread is called “VeriSign Root Inclusion Request” Please actively review, respond, and contribute to the discussion.
Whiteboard: In public discussion
The public comment period for this request is now over. This request has been evaluated as per sections 1, 5 and 15 of the official CA policy at http://www.mozilla.org/projects/security/certs/policy/ Here follows a summary of the assessment. If anyone sees any factual errors, please point them out. To summarize, this assessment is for the request to add a new root CA certificate for VeriSign Universal Root Certification Authority and enable all three trust bits. Section 4 [Technical]. I am not aware of any technical issues with certificates issued by VeriSign, or of instances where they have knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report. Section 6 [Relevancy and Policy]. VeriSign appears to provide a service relevant to Mozilla users: It is a commercial CA operating in United States and serving customers worldwide. Policies are documented in the documents published on their website and listed in the entry on the pending applications list; the main documents of interest are the CP and CPS, which are both provided in English. http://www.verisign.com/repository/vtnCp.html http://www.verisign.com/repository/CPS/ Section 7 [Validation]. VeriSign appears to meet the minimum requirements for subscriber verification, as follows: * Email: The absolute minimum verification is for Class 1 individual. CPS section 3.2.3, Class 1: There is a limited confirmation of the Subscriber’s e-mail address by requiring the subscriber to be able to answer an e-mail to that address. At enrollment time, the customer gives VeriSign an email address to be included in the certificate. VeriSign sends an email containing a link to that address. If the user clicks on the link, they are directed to a page to pick up the certificate. * SSL: According to VeriSign’s CPS, all SSL certificates are both domain and organization validated. VeriSign authenticates the Organization’s right to use the domain name either as a fully qualified Domain name or an e-mail domain. * Code: According to VeriSign’s CPS, only Class 3 certificates can be issued for code signing. The CPS describes the steps taken to verify the identity of the certificate subscriber. Section 8-10 [Audit]. Section 8-10 [Audit]. VeriSign’s audits have been performed within the past year by KPMG, and the audit reports are posted on cert.webtrust.org. The WebTrust CA audit report explicitly covers this root. Section 13 [Certificate Hierarchy]. VeriSign’s roots sign intermediate CAs, which sign end-entity certificates. VeriSign’s CA hierarchy diagram is provided on their website: http://www.verisign.com/repository/hierarchy/hierarchy.pdf Other: * VeriSign issues CRLs for end-entity certificates at least once a day (see section 4.9.7. of the VeriSign CPS). They have a validity period of 2 weeks. ** No CRL exists yet for this root because VeriSign is not yet actively issuing certificates from this root. Based on this assessment I recommend that Mozilla approve this request to add the VeriSign Universal Root Certification Authority root certificate to NSS and enable all three trust bits.
To Kathleen: Thank you for your work on this request. To the representatives of VeriSign: Thank you for your cooperation and your patience. To all others who have commented on this bug or participated in the public discussion: Thank you for volunteering your time to assist in reviewing this CA request. I have reviewed the summary and recommendation in comment #5, and on behalf of the Mozilla project I approve this request from VeriSign to include the following root certificate in Mozilla, with trust bits set as indicated: * VeriSign Universal Root Certification Authority (web sites, email, code signing) Kathleen, could you please file the necessary bugs to effect the approved changes? When those bugs are completed please change the status of this bug to RESOLVED FIXED. Thanks in advance!
Whiteboard: In public discussion → Approved
I have filed bug 515470 against NSS for the actual changes.
Whiteboard: Approved → Approved - awaiting NSS
Confirmed that this root is a Builtin Object Token in Firefox 3.6.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: Approved - awaiting NSS
You need to log in before you can comment on or make changes to this bug.