409235 - add Verisign's G4 ECC root certificate

Status: RESOLVED FIXED

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

Description

[Jay Schiavo]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Build Identifier: 

Please accept the attached VeriSign root certificate for inclusion in Firefox. 

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 Class 3 Public Primary Certificate Authority - G4

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

Steps to Reproduce:
1.
2.
3.

Comment 1

[Jay Schiavo]

Attachment: File contains VeriSign's ECC root for inclusion in FireFox

The attached file contains VeriSign's root ECC certificate.

Comment 2

[David E. Ross]

Please note that certificates go into Mozilla's NSS database, which is used by a number of Mozilla products and such derived products as SeaMonkey.  A reference to Firefox is incorrect.  I'll leave this to Hecker to correct the Summary.  

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Putting G4 in the subject of this RFE to make it searchable.
The subject name for the certificate attached to this bug is:

CN=VeriSign Class 3 Public Primary Certification Authority - G4,
OU="(c) 2007 VeriSign, Inc. - For authorized use only",
OU=VeriSign Trust Network,O="VeriSign, Inc.",C=US

Comment 4

[Jay Schiavo]

This root is included in our current CPS at http://www.verisign.com/repository/CPS/. The ECC root is a Class 3 PCA (generation four). We don't list  all our roots in the CPS, but we do refer to the PCAs generally. This covers the ECC root under our current CPS as it is a PCA, even though it is not specifically mentioned. The same Class 3 procedures would apply.

Comment 5

[Jay Schiavo]

Attachment: Letter from KPMG regarding Verisign's ECC roots

The attached email is from KPMG stating that our annual WebTrust for CAs reports for the VeriSign, Thawte and GeoTrust brands (most recently covering the period ending November 30, 2007) cover the effectiveness of CA controls including the CA key generation process based on the WebTrust for CAs criteria.

Comment 6

[Frank Hecker]

Accepting this bug and putting it into the queue with the other CA requests. At present I cannot say for certain exactly when we will be able to process this.

Comment 7

[Rick Andrews]

I have set up a public-facing web server with this root and an SSL cert signed by it (also with an ECC key). The url is https://ecc-test-valid.verisign.com. I'm not sure if the name is in DNS yet, so you can also hit it at https://205.180.234.250.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

FYI, If I add the following entries to my etc/hosts file:

205.180.234.250 ecc-test-valid.verisign.com
205.180.234.252 ecc-test-valid.thawte.com
205.180.234.253 ecc-test-valid.geotrust.com

and then download and import the root CA cert which is attached to this bug 
into my cert DB and mark it trusted for SSL, and then visit the test URL 
given above in this bug (https://ecc-test-valid... ),
it works for me.  :)

If I view the server and root CA certs in the cert viewer (by click on the 
browser's lock icon in the lower right hand corner of the window chrome),
the browser has no trouble displaying them.

Comment 9

[Kathleen Wilson]

Attachment: Root CA as .cer file

Comment 10

[Frank Hecker]

Reassigning to Kathleen Wilson to do information gathering.

Comment 11

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

I have been asked to do the information gathering and verification for this request as per http://wiki.mozilla.org/CA:Information_checklist.  The attached document provides a summary of the information that has been gathered and verified so far. I have the following questions and request for further information:

1) Can you provide a public URL to the CRL for this root?

2) If applicable, please provide OCSP responder URL. (I don’t think this is applicable)

3) The requested Trust Bits for this root are Websites (SSL/TLS) and Code Signing.  Not email.  Correct?

4) Please provide a certificate hierarchy diagram and/or description for the sub-CA’s (current or planned) for this root.

a) List or description of subordinate CAs operated by the CA organization associated with the root CA. (For example, this might include subordinate CAs created to issue different classes or types of end entity certificates: Class 1 vs. class 2 certificates, qualified vs. non-qualified certificates, SSL certificates vs. email certificates, and so on.)
For internally-operated subordinate CAs the key is to confirm that their operation is addressed by the relevant CPS, and that any audit covers them as well as the root.

b) For subordinate CAs operated by third parties, if any: 
General description of the types of third-party subordinates that exist, and what the general legal/technical arrangements are by which those subordinates are authorized, controlled, and audited.
(For example, contractual arrangements should require third-party subordinates to operate in accordance with some CPS/CP. Technical arrangements might include name constraints, not allowing them to create their own subordinates, etc.) 

c) List any other root CAs that have issued cross-signing certificates for this root CA


Thanks,
Kathleen

Comment 12

[Rick Andrews]

1) Can you provide a public URL to the CRL for this root?
Not at this time, since we do not actively issue certificates from this root. We're trying to get this root in Firefox in anticipation of a market in the near future.

2) If applicable, please provide OCSP responder URL. (I don’t think this is
applicable)
This is not applicable since this is a root certificate. We will provide OCSP Responder URLs for certificates signed by this root.

3) The requested Trust Bits for this root are Websites (SSL/TLS) and Code
Signing.  Not email.  Correct?
Correct.

Comment 13

[Rick Andrews]

4) Please provide a certificate hierarchy diagram and/or description for the
sub-CA’s (current or planned) for this root.

a) List or description of subordinate CAs operated by the CA organization
associated with the root CA. (For example, this might include subordinate CAs
created to issue different classes or types of end entity certificates: Class 1
vs. class 2 certificates, qualified vs. non-qualified certificates, SSL
certificates vs. email certificates, and so on.)
For internally-operated subordinate CAs the key is to confirm that their
operation is addressed by the relevant CPS, and that any audit covers them as
well as the root.
Planned sub-CAs:
  Class 3 Secure Server CA (standard SSL certificates)
  Class 3 Secure Intranet Server CA (intranet SSL certificates)
  Class 3 Extended Validation SSL CA (EV SSL certificates)
  Class 3 Code Signing (EV and non-EV Code Signing certificates)
  OnSite Administrator CA - Class 3 (Enterprise portal Admin certificates)
  Class 3 Open Financial Exchange CA - G2 (OFX SSL certificates)
  Time Stamping Authority CA (time stamping certificates)
  Class 3 Mobile CA (authentication of servers in the mobile space)
  Class 3 WLAN CA (for Microsoft RADIUS/IAS servers)
  Class 3 Organizational CA (S/MIME certs for organizations)

b) For subordinate CAs operated by third parties, if any: 
General description of the types of third-party subordinates that exist, and
what the general legal/technical arrangements are by which those subordinates
are authorized, controlled, and audited.
(For example, contractual arrangements should require third-party subordinates
to operate in accordance with some CPS/CP. Technical arrangements might include
name constraints, not allowing them to create their own subordinates, etc.) 
This is n/a for this root.

c) List any other root CAs that have issued cross-signing certificates for this
root CA
This is n/a for this root.

Comment 14

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 15

[Kathleen Wilson]

The information gathering phase of this request is complete. Assigning bug to Frank so he can proceed with the next phase.

I will update the pending list to include this root. There will be a slight delay before the changes are visible.

Thanks,
Kathleen

Comment 16

[Frank Hecker]

Re-assigning this bug to Kathleen Wilson, since she'll the person actively working on it.

Comment 17

[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 18

[Rick Andrews]

Concerning the fact that this root is not mentioned in our current WebTrust audit: VeriSign's representative responsible for Audits told me that the ECC root "is not within the scope of WTCA since it is not issuing any certs, and it would be easily added to the scope for this year's WTCA audit which starts soon."

Comment 19

[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 Class 3 Public Primary Certificate Authority - G4  (ECC) 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 the SHA256, PCA1 G1 SHA1, PCA2 G1 SHA1, and PCA3-G1 SHA1 roots.
** I did not find explicit reference to the ECC root (VeriSign Class 3 Public Primary Certificate Authority - G4) in the audit. 
** VeriSign has committed to include this ECC root in their upcoming WTCA audit, and provide the updated audit report to Mozilla as soon as it is ready.

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 ECC 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 Class 3 Public Primary Certificate Authority - G4  (ECC) root certificate to NSS and enable all three trust bits.

Comment 20

[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 #19, 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 Class 3 Public Primary Certificate Authority - G4 (ECC) (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 21

[Kathleen Wilson]

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

Comment 22

[Kathleen Wilson]

ACTION VeriSign: VeriSign has committed to include this ECC root in their upcoming WTCA audit, and provide the updated audit report to Mozilla as soon as it is ready. 

Calling this action item out separately, so this bug doesn't get closed until the action item is also completed.

Comment 23

[Kathleen Wilson]

I have confirmed that this root is now a Builtin Object Token in Firefox 3.6. However, this bug will remain open until VeriSign has completed their action item as per Comment #22.

Jay, Please update this bug when VeriSign has completed the action item.

Comment 24

[Kathleen Wilson]

Tony or Jay, Do you have an update on the action item?

ACTION VeriSign: VeriSign has committed to include this ECC root in their
upcoming WTCA audit, and provide the updated audit report to Mozilla as soon as
it is ready.

Comment 25

[Kathleen Wilson]

I have confirmed that VeriSign's recent WTCA audit includes this ECC root, "VeriSign Class 3 Public Primary Certificate Authority - G4"

https://cert.webtrust.org/SealFile?seal=304&file=pdf

Comment 26

[Peter Bachman]

4C 79 B5 9A 28 9C 76 31 64 F5 89 44 D0 91 02 DE 

ECC Root using P384 Elliptic Curve secp384r1 ( 1.3.132.0.34 )

This curve, based on recent information since 2010 is no longer considered to be "safe".

http://safecurves.cr.yp.to/

Comment 27

[Rick Andrews]

Thanks for the pointer, Peter. Symantec chose to use the NIST curves for a variety of reasons, but maybe the most important was that it was felt that the NIST curves would be most widely supported by all browsers and other TLS clients.

Which "safe" curves on the SafeCurves page are supported by Mozilla?