Rick Andrews Reporter
	Description • 17 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8

Please accept this VeriSign EV root certificate for inclusion in Firefox:
-----BEGIN CERTIFICATE-----
MIIE0zCCA7ugAwIBAgIQGNrRniZ96LtKIVjNzGs7SjANBgkqhkiG9w0BAQUFADCB
yjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJp
U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW
ZXJpU2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzUwHhcNMDYxMTA4MDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJpU2ln
biwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJp
U2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y
aXR5IC0gRzUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvJAgIKXo1
nmAMqudLO07cfLw8RRy7K+D+KQL5VwijZIUVJ/XxrcgxiV0i6CqqpkKzj/i5Vbex
t0uz/o9+B1fs70PbZmIVYc9gDaTY3vjgw2IIPVQT60nKWVSFJuUrjxuf6/WhkcIz
SdhDY2pSS9KP6HBRTdGJaXvHcPaz3BJ023tdS1bTlr8Vd6Gw9KIl8q8ckmcY5fQG
BO+QueQA5N06tRn/Arr0PO7gi+s3i+z016zy9vA9r911kTMZHRxAy3QkGSGT2RT+
rCpSx4/VBEnkjWNHiDxpg8v+R70rfk/Fla4OndTRQ8Bnc+MUCH7lP59zuDMKz10/
NIeWiu5T6CUVAgMBAAGjgbIwga8wDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8E
BAMCAQYwbQYIKwYBBQUHAQwEYTBfoV2gWzBZMFcwVRYJaW1hZ2UvZ2lmMCEwHzAH
BgUrDgMCGgQUj+XTGoasjY5rw8+AatRIGCx7GS4wJRYjaHR0cDovL2xvZ28udmVy
aXNpZ24uY29tL3ZzbG9nby5naWYwHQYDVR0OBBYEFH/TZafC3ey78DAJ80M5+gKv
MzEzMA0GCSqGSIb3DQEBBQUAA4IBAQCTJEowX2LP2BqYLz3q3JktvXf2pXkiOOzE
p6B4Eq1iDkVwZMXnl2YtmAl+X6/WzChl8gGqCBpH3vn5fJJaCGkgDdk+bW48DW7Y
5gaRQBi5+MHt39tBquCWIMnNZBU4gcmU7qKEKQsTb47bDN0lAtukixlE0kF6BWlK
WE9gyn6CagsCqiUXObXbf+eEZSqVir2G3l6BFoMtEMze/aiCKm0oHw0LxOXnGiYZ
4fQRbxC1lfznQgUy286dUV4otp6F01vvpX1FQHKOtw5rDgb7MzVIcbidJ4vEZV8N
hnacRHr2lVz2XTIIM6RUthg/aFzyQkqFOFSDX9HoLPKsEdao7WNq
-----END CERTIFICATE-----

This CA is currently used to sign certificates for SSL-enabled servers, and may in the future be used to sign certificates for digitally-signed executable code objects.

The CP is at http://www.verisign.com/repository/CPS/VeriSignCPv2.5.pdf
The CPS is at http://www.verisign.com/repository/CPS/VeriSignCPSv3.5.pdf

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:
n/a
Actual Results:  
n/a

Expected Results:  
n/a

n/a

	Nelson Bolyard (seldom reads bugmail)
	Comment 1 • 17 years ago

I confirm that this is an enhancement request.
Moving to the right product and component.

	Frank Hecker Assignee
	Comment 2 • 17 years ago

I'm marking this bug as technically blocked by bug 399214, since the bug presumes that we have a formal policy in place relating to EV certs. However in the interests of time I'll go ahead and ask any questions I'll need to ask anyway.

	Frank Hecker Assignee
	Comment 3 • 17 years ago

(In reply to comment #0)
> 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)

OK, here's my main question: The audit report in question appears to be VeriSign's WebTrust for CAs audit report for the year ending November 30, 2006:

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

This audit doesn't address EV stuff (naturally enough, since it pre-dates adoption of the EV guidelines). Has VeriSign in fact completed a supplemental audit according to the WebTrust EV audit criteria and, if so, is there a published report from VeriSign's auditors attesting to that fact?

	Frank Hecker Assignee
	Comment 4 • 17 years ago

Some more questions: We currently collect various bits of information about the CAs and CA certificates we include, and have public pages where we're posting these:

http://www.mozilla.org/projects/security/certs/included/
http://www.mozilla.org/projects/security/certs/pending/

We've found this is useful both for our own purposes and also for the benefit of people who want to know more about the CAs whose certificates we're pre-loading.

Here's a template we use for collecting CA-related information. I've partially filled out the template based on information from Verisign's public site and related sources, but would appreciate it if you could fill in the remaining blanks.


CA Details
----------

(note that this refers to "CA" in the sense of the overall organization)

CA Name: VeriSign

Website: http://www.verisign.com/

One Paragraph Summary of CA, including the following:
 - General nature (e.g., commercial, government, academic/research, nonprofit)
 - Primary geographical area(s) served: worldwide
 - Number and type of subordinate CAs

VeriSign is a major commercial CA with worldwide operations and customer base.

Audit Type (WebTrust, ETSI etc.): WebTrust

Auditor: KPMG

Auditor Website: http://www.kpmg.com/

Audit Document URL(s): https://cert.webtrust.org/SealFile?seal=304&file=pdf
[Would also like reference to WebTrust EV audit if it exists]

Certificate Details
-------------------
(To be completed once for each certificate)

Certificate Name: VeriSign Class 3 Public Primary Certification Authority - G5

Summary Paragraph, including the following:
 - End entity certificate issuance policy, i.e. what you plan to do with the 
   root

Subordinate CAs under this root issue Extended Validation SSL certificates

Certificate HTTP URL (on CA website): http://www.verisign.com/support/roots.html
[Is there a direct URL to download just the PCA3-G5 root?]

Version: 3

SHA1 Fingerprint: 4e b6 d5 78 49 9b 1c cf 5f 58 1e ad 56 be 3d 9b 67 44 a5 e5

MD5 Fingerprint: [?]

Modulus Length (a.k.a. "key length"): [2048?]

Valid From (YYYY-MM-DD): 2006-11-07

Valid To (YYYY-MM-DD): 2036-07-16

CRL HTTP URL: [?]

OCSP URL: [?]

Class (domain-validated, identity-validated or EV): EV

Certificate Policy URL: http://www.verisign.com/repository/CPS/VeriSignCPv2.5.pdf

CPS URL:
http://www.verisign.com/repository/CPS/VeriSignCPSv3.5.pdf

Requested Trust Indicators (email and/or SSL and/or code): SSL

	Rick Andrews Reporter
	Comment 5 • 17 years ago

Here's the current WebTrust Audit document

	Rick Andrews Reporter
	Comment 6 • 17 years ago

Our EV audit is under way. We have met with the auditors and we know they have met with our authentication team in the US and are with our authentication team this week in Europe.

Webtrust covers from Dec. 01, previous year to November 30, current year. KPMG should wrap up the audit most likely before Thanksgiving weekend. VeriSign's audit team would receive the draft on the final week of November. If no adjustment is needed for the draft then we would receive the final report probably first or second week of December. As soon as VeriSign management puts their signature on the final report, then we can publish them. We probably won't see it until the end of the year. 

	Frank Hecker Assignee
	Comment 8 • 17 years ago

Note that I've added this VeriSign certificate to the "pending" list:

http://www.mozilla.org/projects/security/certs/pending/#VeriSign

The main issue at this point is completion of the EV audit. Based on its 2006 date the audit referenced in the pending entry (as attached to this bug) was presumably against the draft guidelines. Also, it's CA-supplied and at present doesn't have any independent verification as to its genuineness.

Other minor issues:

1. I can't figure out what the URL for the CRL is. The table at

  http://www.verisign.com/repository/crl.html

is very out of date, and the list at

  http://crl.verisign.com/

doesn't have any context to tell which CRL goes with which CA.

2. I presume the OCSP URL is http://oscp.verisign.com/, but haven't confirmed this.

	Kaspar
	Comment 9 • 17 years ago

(In reply to comment #8)

> Other minor issues:
> 
> 1. I can't figure out what the URL for the CRL is. The table at
> 
>   http://www.verisign.com/repository/crl.html
> 
> is very out of date, and the list at
> 
>   http://crl.verisign.com/
> 
> doesn't have any context to tell which CRL goes with which CA.

It's http://EVIntl-crl.verisign.com/EVIntl2006.crl, as can be determined by looking at a current EV certificate (e.g. at https://www.paypal.com; note that EVIntl-crl.verisign.com is a CNAME pointing to crl.verisign.net).

> 2. I presume the OCSP URL is http://oscp.verisign.com/, but haven't confirmed
> this.

http://EVIntl-ocsp.verisign.com (which again is a CNAME pointing to ocsp.verisign.net)

	Jay Schiavo
	Comment 10 • 17 years ago

Adding this document that contains the EV OIDs for Verisign, GeoTrust and thawte as well as download link for all our roots.

	Kai Engert (:KaiE:)
	Comment 11 • 17 years ago

Independent of approval process, for technical testing purposes: Could you please supply an https:// URL to an example SSL server (customer or demo) that uses a server cert issued (directly or through intermediates) by this root? Should you request multiple roots to be enabled for EV, please provide one example URL for each root. Thank you.

	Rick Andrews Reporter
	Comment 12 • 17 years ago

An example of an EV cert signed under this root can be found at https://www.verisign.com

	Nelson Bolyard (seldom reads bugmail)
	Comment 13 • 17 years ago

Putting G5 in the bug subject to make it searchable

	Nelson Bolyard (seldom reads bugmail)
	Comment 14 • 17 years ago

The subject name of the certificate in this request (line wrapped here) is:

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

	Frank Hecker Assignee
	Comment 15 • 17 years ago

Added the "VeriSign Class 3 Public Primary CA - G5" as an attachment. (This was taken from the certificate data included in the original bug report.)

	Frank Hecker Assignee
	Comment 16 • 17 years ago

I've updated the VeriSign Class 3 Public Primary CA - G5 entry in the pending list to incorporate the above corrections/additions, and marked it as complete:

http://www.mozilla.org/projects/security/certs/pending/#VeriSign

I'll now proceed to evaluate the request and render a preliminary decision.

	Frank Hecker Assignee
	Comment 17 • 17 years ago

I have now completed my review of VeriSign's application for adding a root CA certificate for the VeriSign Class 3 Public Primary Certification Authority - G5 to support EV use, per the official Mozilla CA certificate policy at:

http://www.mozilla.org/projects/security/certs/policy/

I apologize for any delays on my part in doing the review.

Here follows my final assessment. If anyone sees any factual errors, please
point them out.

NOTE: My comments here are confined to the request relating to VeriSign Class 3 Public Primary CA - G5; they are not intended as a general judgment on VeriSign and its other CAs. Also note that because of the cross-signing scheme implemented by VeriSign, certificates issued under the VeriSign Class 3 Public Primary CA - G5 hierarchy are actually already recognized as valid in Mozilla products, based on the presence of prior VeriSign roots. (See more on this below.) The effect of this request is specifically to enable recognition of VeriSign-issued EV certificates by adding VeriSign Class 3 Public Primary CA - G5 as a separate trust anchor for that part of the overall VeriSign CA hierarchy in which EV certificates are issued.

Section 4 [Technical]. I'm not aware of any technical issues with certificates
issued by VeriSign Class 3 Public Primary CA - G5, or of instances where this CA 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 [Relevancy and Policy]. VeriSign in general and VeriSign Class 3 Public Primary CA - G5 in particular appear to provide a service relevant to Mozilla users; VeriSign is a commercial CA operating in United States and
serving customers worldwide, and VeriSign Class 3 Public Primary CA - G5 was established specifically to support VeriSign issuance of new Extended Validation certificates.

Policies for VeriSign CAs, including VeriSign Class 3 Public Primary CA - G5, are documented in the following CPS and CP:

http://www.verisign.com/repository/CPS/VeriSignCPSv3.5.pdf
http://www.verisign.com/repository/CPS/VeriSignCPv2.5.pdf

* Email: Email certificates are not issued under the VeriSign Class 3 Public Primary CA - G5 hierarchy, and the email trust bit will not be enabled for this root.

* SSL: For EV SSL certificates issued under the VeriSign Class 3 Public Primary CA - G5 hierarchy, VeriSign validates identity and domain ownership using procedures consistent with the EV guidelines. (See Appendix B1 of the VeriSign CPS and sections 1.3.1, 1.4.1.3, and 3.2.2 in the VeriSign CP.) Only EV certificates are issued under the VeriSign Class 3 Public Primary CA - G5 hierarchy, so verification procedures for other types of VeriSign-issued certificates are not relevant for this request.

* Code: Code signing certificates are not issued under the VeriSign Class 3 Public Primary CA - G5 hierarchy, and the code signing trust bit will not be enabled for this root.

Section 8-10 [Audit]. VeriSign has successfully completed independent audits using the WebTrust for CAs criteria and the WebTrust EV criteria. The
audits were done by KPMG. Attestation of the successful completion of the WebTrust audit is in the form of a standard WebTrust report available at

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

and a separate WebTrust EV report available at

https://bugzilla.mozilla.org/attachment.cgi?id=287877

(Note that since the latter document was supplied by VeriSign itself, final approval of this request will be contingent on verification by KPMG that this document is valid.)

Note that the WebTrust EV audit was done against the draft version of the
EV guidelines.

Section 13 [Certificate Hierarchy]. This particular request is for the VeriSign Class 3 Public Primary CA - G5 root. The CA hierarchy under this root is used only for the issuance of EV certificates. End entity certificates are issued by subordinate CAs operated and controlled by VeriSign.

Note that for compatibility reasons VeriSign has implemented a cross-signing scheme involving the VeriSign Class 3 Public Primary CA - G5. In this scheme, if applications not supporting EV functionality (e.g., Firefox 2 and earlier) encounter VeriSign EV certificates then they will end up treating the CA as a subordinate CA under the existing VeriSign Class 3 Public Primary CA root.

Other: VeriSign issues CRLs for end-entity certificates at least once a day (see section 4.9.7. of the VeriSign CPS). VeriSign also operates an OCSP responder.

Based on the above information, I am minded to approve the addition of the VeriSign Class 3 Public Primary CA - G5 root CA certificate in NSS and thence in Firefox and other Mozilla-based products, and enabling of the VeriSign Class 3 Public Primary CA - G5 root CA certificate for EV use. Before I do so, I'm opening up a period of public discussion of this request in the mozilla.dev.tech.crypto newsgroup [1].

[1] The mozilla.dev.tech.crypto newsgroup is accessible via NNTP-capable
newsreaders at:

  news://news.mozilla.org/mozilla.dev.tech.crypto

via email by subscribing to the associated mailing list:

  https://lists.mozilla.org/listinfo/dev-tech-crypto

and via the web at:

  http://groups.google.com/group/mozilla.dev.tech.crypto/topics

	Nelson Bolyard (seldom reads bugmail)
	Comment 18 • 17 years ago

According to http://www.mozilla.org/projects/security/certs/pending/ 
as of this date, the status of this request is: Information confirmed complete	

	Frank Hecker Assignee
	Comment 19 • 17 years ago

The comment period has ended, and there are no outstanding issues and
questions, so I'm formally approving the VeriSign request to add the Class 3 Public Primary CA - G5 root to NSS and to mark it as suitable for EV use. I've filed bug 422918 against NSS and bug 422921 against PSM to make the actual code changes required.

	Frank Hecker Assignee
	Comment 20 • 17 years ago

My apologies, I forgot to note the following: In comment #17 I mentioned that final approval was contingent on contacting KPMG directly to confirm the authenticity of the VeriSign-supplied WebTrust EV document. I did in fact contact KPMG and got this confirmed, so the contingency was removed.

	Kai Engert (:KaiE:)
	Comment 21 • 17 years ago

Can you please file another bug against NSS (and assign it to me) once the additional trust flags are approved? Thanks.

	Frank Hecker Assignee
	Comment 22 • 16 years ago

Since the associated NSS and PSM actions are completed, I'm resolving this bug as FIXED. If VeriSign wants the trust bit for object signing enabled, that can be submitted as a new request.