484901 - Add Verisign's SHA256 root

Status: RESOLVED FIXED

(CA Program :: CA Certificate Root Program, task)

Description

[Jay Schiavo]

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

Comment 1

[Jay Schiavo]

Attachment: Verisign's SHA256 root CA

The attached file contains Verisign's SHA256 root - VeriSign Universal Root Certification Authority.

Comment 2

[Kathleen Wilson]

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

Comment 3

[Kathleen Wilson]

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

Comment 4

[Kathleen Wilson]

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 [e-mail] 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.

Comment 5

[Kathleen Wilson]

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.

Comment 6

[Frank Hecker]

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!

Comment 7

[Kathleen Wilson]

I have filed bug 515470 against NSS for the actual changes.

Comment 8

[Kathleen Wilson]

Confirmed that this root is a Builtin Object Token in Firefox 3.6.