30.04 KB, application/pdf
23.50 KB, application/msword
1.69 KB, application/x-x509-ca-cert
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20071008 Firefox/22.214.171.124 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20071008 Firefox/188.8.131.52 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
I confirm that this is an enhancement request. Moving to the right product and component.
Assignee: nobody → hecker
Status: UNCONFIRMED → NEW
Component: General → CA Certificates
Ever confirmed: true
Product: Firefox → mozilla.org
QA Contact: general → ca-certificates
Version: unspecified → other
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.
Status: NEW → ASSIGNED
Depends on: 399214
(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?
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
Here's the current WebTrust Audit document
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.
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.
(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)
Adding this document that contains the EV OIDs for Verisign, GeoTrust and thawte as well as download link for all our roots.
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.
An example of an EV cert signed under this root can be found at https://www.verisign.com
Putting G5 in the bug subject to make it searchable
Summary: Please accept VeriSign EV root certificate for inclusion → Add VeriSign G5 EV root certificate
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
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.)
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.
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, 184.108.40.206, 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 .  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
According to http://www.mozilla.org/projects/security/certs/pending/ as of this date, the status of this request is: Information confirmed complete
Whiteboard: EV → EV Information confirmed complete
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.
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.
Can you please file another bug against NSS (and assign it to me) once the additional trust flags are approved? Thanks.
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.