536318 - EV enable VeriSign SHA256 root certificate

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; GTB6.3; .NET CLR 2.0.50727; InfoPath.1; MS-RTC LM 8)
Build Identifier: Mozilla 3.5

This request is to EV enable the following VeriSign, GeoTrust, and thawte ECC and SHA256 roots that were just accepted into the Mozilla root program:

- VeriSign Universal Root Certification Authority root certificate (SHA256 root)
- VeriSign Class 3 Public Primary Certification Authority - G4 root certificate (ECC root)
- GeoTrust Primary Certificate Authority - G2 (ECC root)
- GeoTrust Primary Certificate Authority - G3 (SHA256 root)
- thawte Primary Root CA – G3 (SHA256 root)
- thawte Primary Root - G2 (ECC root)


Reproducible: Always

Comment 1

[Jay Schiavo]

Corresponding bugs for adding these roots are:

- VeriSign Universal Root Certification Authority root certificate (Bug 484901)
- VeriSign Class 3 Public Primary Certification Authority - G4 root certificate (Bug 409235)
- GeoTrust Primary Certificate Authority - G2 (Bug 409236)
- GeoTrust Primary Certificate Authority - G3 (Bug 484899)
- thawte Primary Root CA – G3 (Bug 484903)
- thawte Primary Root - G2 (Bug 409237)

Comment 2

[Kathleen Wilson]

Since VeriSign, GeoTrust, and thawte have different CP/CPS and audit documents, I am going to separate this request into three. I'll keep this one for VeriSign, and create two other separate requests for GeoTrust and thawte.

Comment 3

[Kathleen Wilson]

For the GeoTrust EV-enablement request, see bug #539255
For the thawte EV-enablement request, see bug #539257

In this bug we will focus on the request to EV enable the following VeriSign ECC and SHA256 root certificates that are currently included in NSS.

- VeriSign Universal Root Certification Authority root certificate (SHA256
root)
Inclusion Bug #484901

- VeriSign Class 3 Public Primary Certification Authority - G4 root certificate
(ECC root)
Inclusion Bug #409235

Comment 4

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

The attached document summarizes the information that has been gathered and
verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Matthew Middleton:  This bug is properly assigned to mozilla.org 
component CA Certificates, and to Kathleen Wilson.  Please don't 
mess with these bugs.

Comment 6

[Tony Berman]

Attachment: Response to initial information request

Attached are responses to initial information gathering

Comment 7

[Tony Berman]

Attachment: Updated response to information request

Please refer to this updated version of the response and ignore the previous version. Thanks Tony

Comment 8

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 9

[Kathleen Wilson]

This request has been added to the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Now that you have a request in the Queue for Public Discussion, you are
directly impacted by the time it takes to work through the queue. The goal is
to have each discussion take about two weeks. However, that time varies
dramatically depending on the number of reviewers contributing to the
discussion, and the types of concerns that are raised. If no one reviews and
contributes to a discussion, then a request may be in the discussion for
several weeks. When there are not enough people contributing to the discussions
ahead of yours, then your request will sit in the queue longer.

How can you help reduce the time that your request sits in the queue?

You can help by reviewing and providing your feedback in the public discussions
of root inclusion requests, or by asking a knowledgeable colleague to do so.

Participating in other discussions is a great way to learn the expectations and
be prepared for the discussion of your request.

Please see: https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Comment 10

[Tony Berman]

A test site is now available for the "VeriSign Class 3 Public Primary Certification Authority - G4":
https://ecc-test-valid.verisign.com

Comment 11

[Tony Berman]

The latest EV Web Trust audit for includes the VeriSign Universal root CA. Please can you proceed with enabling this root for EV. https://cert.webtrust.org/SealFile?seal=304&file=pdf 

Thanks
Tony

Comment 12

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 13

[Kathleen Wilson]

Please provide a url to a website whose EV SSL cert chains up to this root. The test site, https://ssltest26.bbtest.net/, has an expired cert.

Comment 14

[Tony Berman]

https://ssltest26.bbtest.net has been updated and shoud now be valid.

Comment 15

[Kathleen Wilson]

According to my notes: "A Class 3 intermediate CA will be created under this root for EV issuance."
Has this intermediate CA been created yet?  If yes, would you please update the website cert to chain up to the intermediate CA?

Also, Is OCSP available in this hierarchy? If not, when will it be?

We can proceed with the discussion, but before actual approval of EV-enablement, 
Symantec will need to successfully run this test:
https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version

Comment 16

[Tony Berman]

We will work creating an intermediate Ca to sign the cert on this test site. i do not yet have an e.t.a for that.

Comment 17

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 18

[Kathleen Wilson]

I am now opening the first public discussion period for two requests from Symantec/VeriSign:

#536318 - EV enable VeriSign SHA256 root certificate

#602107 - Turn on the code signing and email trust bits for the VeriSign Class 3 Public Primary Certification Authority - G5

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 “Symantec/VeriSign EV and Trust Bit Change Request”

Please actively review, respond, and contribute to the discussion.

Comment 19

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Within this document, recently updated text is highlighted in green.

Comment 20

[Kathleen Wilson]

The public comment period for this request is now over.

Symantec has the following action items:

1) Create the EV issuing intermediate CA.

2) Perform the EV testing described here:
https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version

3) Update this bug to provide the URL to a test website whose EV SSL cert chains up to this root.

After this bug has been updated to indicate completion of these action items, I will check the provided test website and then recommend approval in this bug to enable EV for the “VeriSign Universal Root Certification Authority” root certificate.

Comment 21

[Kathleen Wilson]

Reminder, this request is to enable EV for the "VeriSign Universal Root Certification Authority" root certificate. 

As per Comment #20, the discussion of this request was completed, and this request is only waiting on successful completion of EV Testing.

Comment 22

[Rick Andrews]

We've completed our testing with Minefield and 

There is no warning when loading the page (expected)
End Entity chains up to given root cert (expected)
Green bar is not present (not expected)

Comment 23

[Rick Andrews]

BTW, here's the contents of the test_ev_roots file we used:

1_fingerprint 36:79:CA:35:66:87:72:30:4D:30:A5:FB:87:3B:0F:A7:7B:B7:0D:54
2_readable_oid 2.16.840.1.113733.1.7.23.6
3_issuer MIG9MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAyMDA4IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxODA2BgNVBAMTL1ZlcmlTaWduIFVuaXZlcnNhbCBSb290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5
4_serial

Comment 24

[Kathleen Wilson]

Attachment: test_ev_roots.txt

Try using the attached test_ev_roots.txt file and also using an appropriate CA hierarchy (with an intermediate certificate). EV treatment will only be given if the requirements in the EV Guidelines are met.

Comment 25

[Rick Andrews]

OK, we've added the intermediate and enabled OCSP, and tested with firefox-4.0b8pre.en-US.win32 (Minefield) and the new test_ev_roots.txt file that you provided. Testing was successful. We can hit the site without warnings or errors, and we see the green toolbar.

Comment 26

[Kathleen Wilson]

Attachment: Screenshot showing EV treatment

Comment 27

[Kathleen Wilson]

As per Comment #20, the public discussion for this request resulted in approval being on hold until the CA completed EV testing.
As per Comment #25, the CA has successfully completed EV testing, and I confirmed this in Comment #26.

This request has been evaluated as per Mozilla’s CA Certificate 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 enable EV treatment for the “VeriSign Universal Root Certification Authority” root certificate.

Section 4 [Technical]. I am not aware of instances where Symantec has knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report.

Section 6 [Relevance and Policy]. Symantec appears to provide a service relevant to Mozilla users. Symantec acquired the VeriSign Authentication Services and root certificates, and is a major commercial CA with worldwide operations and customer base.

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 in English.

CP: http://www.verisign.com/repository/vtnCp.html
CPS: http://www.verisign.com/repository/CPS/

Section 7 [Validation]. Symantec appears to meet the minimum requirements for subscriber verification, as follows:

* Email: From CPS section 3.2.2: “Where a domain name or e-mail address is included in the certificate Symantec authenticates the Organization’s right to use that domain name either as a fully qualified Domain name or an e-mail domain.” Email certificates may be Class 1, 2, or 3. All must at least meet the requirements of Class 1. For Class 1 certs CPS section 3.2.3 says: “No identity authentication. 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.”

* SSL: According to CPS section 1.4.1 only Class 3 certificates issued to organizations can be used for SSL and Code Signing. Additionally high assurance with extended validation certificates are Class 3 certificates issued by Symantec in conformance with the Guidelines for Extended Validation Certificates. According to CPS section 3.2.2 Symantec verifies that the organization has the right to use the domain name to be included in the certificate.

* Code: According to CPS section 1.4.1 Organizational Certificates are issued to organizations after authentication that the Organization legally exists and that other Organization attributes included in the certificate are authenticated e.g. ownership of an Internet or e-mail domain. Further information is provided in CPS section 3.2.2 regarding the use of third party identity proofing services and other methods to confirm organizational existence, and the use of telephone or postal mail to confirm the authorization of the certificate subscriber to submit the application on behalf of the organization.

Section 18 [Certificate Hierarchy]
This root has internally-operated intermediate certificates. 

* EV Policy OID: 2.16.840.1.113733.1.7.23.6

* CRL: 
http://crl.ws.symantec.com/universal-root.crl
http://EVSecureSHA256-crl.ws.symantec.com/EVSecureSHA256.crl
CPS Appendix B1, Section 26: For EV Certificates: 
 (A) CRLs are be updated and reissued at least every seven (7) days, and the nextUpdate field value SHALL NOT be more than ten (10) days; 
 
* OCSP
http://ocsp.ws.symantec.com
http://EVSecureSHA256-ocsp.ws.symantec.com
CPS Appendix B1, Section 26: For EV Certificates: 
 (B) Symantec’s Online Certificate Status Protocol (OCSP) is updated at least every four (4) days, and with a maximum expiration time of ten (10) days 

Sections 11-14 [Audit]. 
Symantec is audited according to the WebTust CA and WebTrust EV criteria, and audit statements are posted on the webtrust.org website.
 https://cert.webtrust.org/ViewSeal?id=304

Based on this assessment I intend to approve this request to enable EV treatment for the “VeriSign Universal Root Certification Authority” root certificate.

Comment 28

[Kathleen Wilson]

As per the summary in Comment #27, and on behalf of Mozilla I approve this request from Symantec to enable EV treatment for the following root certificate:

** “VeriSign Universal Root Certification Authority”, enable EV.

I will file the PSM bug for the actual changes.

Comment 29

[Kathleen Wilson]

I have filed bug #872288 against PSM for the actual changes.