490895 - Add SHA1 version of Verisign's PCA1-G1, PCA2-G1, and PCA3-G1 roots

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: 

Add SHA1 version of the Verisign  PCA3 G1:  O=Verisign, Inc., OU=Class 3 Public Primary Certification Authority. The version of the root currently in the NSS root store uses MD2. We are replacing this with a rehashed version that uses SHA1. The new SHA-1 root has the same name and public key but a different serial number and a slightly longer validity period - one day. 



Reproducible: Always

Comment 1

[Jay Schiavo]

Also including SHA1 versions for the following Verisign roots currently using MD2:

 PCA2 G1:  O=Verisign, Inc., OU=Class 2 Public Primary Certification Authority
 PCA1 G1:  O=Verisign, Inc., OU=Class 1 Public Primary Certification Authority

Comment 2

[Jay Schiavo]

Attachment: PCA3-G1 SHA1 root

This is the SHA1 version of our PCA3-G1 root used to sign SSL certs.

Comment 3

[Jay Schiavo]

Attachment: PCA2-G1 SHA1 root

Comment 4

[Jay Schiavo]

Attachment: PCA1-G1 SHA1 root

Comment 5

[Kathleen Wilson]

Please clarify this request.

The title is: Add SHA1 version of Verisign PCA3-G1 root 

However, you have attached PCA1-G1 SHA1, PCA2-G2 SHA1, and PCA3-G3 SHA1

Is your intent to request inclusion of all three of these roots?

Comment 6

[Jay Schiavo]

Yes, our intent for this request is for inclusion of all three of these roots as they include roots we use for issuing our client certificates.

Comment 7

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

Attached is the initial information gathering document that summarizes the current inclusion requests for five VeriSign-brand roots as per bugs #409235, #484901, and #490895. I am grouping these together because they are all represented by the same CP, CPS, and audit.

Jay, Please carefully review this document for accuracy and completeness. Please also provide further information or clarification for the items that are highlighted in yellow within the document.

Comment 8

[Kathleen Wilson]

As per the discussion at  

http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/092212e4e21b1458#

The recommendation is to leave the old MD2 roots included in NSS, while adding these SHA-1 versions of the roots.

Comment 9

[Eddy Nigg (StartCom)]

Kathleen, I'm not sure if that's the recommendation concerning a MD2 root. I'll follow up on the mailing list.

Comment 10

[Kathleen Wilson]

Update from the discussion:

It is not necessary to retain the older cert when the newer cert does not have identical notBefore and notAfter dates.
 
In this case, the MD2 roots expire on 2028-08-01, and the new roots expire on 2028-08-02, so the new roots would take precedence in NSS, and the old roots may be removed.

Comment 11

[Kathleen Wilson]

Update in the discussion, from VeriSign:
Hold on please - we would like the MD2 roots to remain alongside the
SHA1 roots. The reason is that we have issued several intermediate CAs
from the MD2 root which bear the serial number of the MD2 root in
their AKI extension. When we created the SHA1 roots, we added one day
to the validity period and kept the DN and key the same, but we gave
it a different serial number (that is our practice). We discovered too
late that Firefox uses the AKI to find the issuer, and if it's not
found, Firefox does not fall back to other methods (like using the
Issuer DN, as other browsers do). Hence we need the MD2 roots to
remain in Firefox until customers renew and replace their SSL certs
signed by intermediates that contain the AKI extension pointing to the
MD2 root. We expect that might take several years.

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

> We discovered too late that Firefox uses the AKI to find the issuer, and 
> if it's not found, Firefox does not fall back to other methods (like 
> using the Issuer DN, as other browsers do). 

That was fixed quite some time ago.  I'm not sure which versions of the 
browser have the fix.  Perhaps the fix has only gone into FF 3.x browsers
and other equally recent browsers.  

However, since the proposed change to the root certs list will only affect
new browsers issued after this date, and those new browsers do not have the
problem described above, it should not be necessary to retain the MD2 certs.

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

The Authority Key ID fix was the subject of bug 384459.
The fix first appeared in these Mozilla product releases:
- FireFox     3.0.0.0
- Thunderbird 2.0.0.21
- SeaMonkey   1.1.15
- Camino      1.6.7

Comment 14

[Jay Schiavo]

Here is the updated Audit report for 2008, which includes EV: https://cert.webtrust.org/SealFile?seal=304&file=pdf  

We were asked to provide a description and/or diagram of the CA Hierarchy of
this root: The VeriSign Universal Root CA has not yet issued any
intermediate or subordinate CA certificates.  It may be used to issue
Subordinate CA certificates for SSL, Code Signing, OFX, and Client
Authentication.  It will also be used to sign CRLs.

Verisign was asked if the Verisign Universal Root Certificate Authority root CA has any subordinate CAs that are operated by external third parties? - The answer is no.

Verisign was asked if this root has been involved in cross-signing with another root? - The answer is no.

CRLs for end-entity SSL certs for the following roots were requested:

- Verisign Universal Root Certificate Authority - We haven't issued any certificates from this Root so it has yet to issue a CRL.

- Verisign Class 3 Public Primary Certificate Authority - G4 - We haven't issued any certificates from this Root so it has yet to issue a CRL.

- Verisign Class 3 Public Primary Certificate Authority (PCA3 - G1.5 SHA 1
Version)- http://crl.verisign.com/pca3.crl 

- Verisign Class 1 Public Primary Certificate Authority (PCA1 - G1 SHA 1
Version)- http://crl.verisign.com/pca1.crl 

- Verisign Class 2 Public Primary Certificate Authority (PCA2 - G1 SHA 1
Version)- http://crl.verisign.com/pca2.crl 

It was also requested if OCSP is provided under these roots:

- Verisign Universal Root Certificate Authority - answer is no

- Verisign Class 3 Public Primary Certificate Authority (PCA3 - G1.5 SHA 1
Version) - answer is Yes

- Verisign Class 1 Public Primary Certificate Authority (PCA1 - G1 SHA 1
Version)- answer is No

- Verisign Class 2 Public Primary Certificate Authority (PCA2 - G1 SHA 1
Version) - answer is No

Also for the SHA1 version of PCA3 - Need to know the max time until OCSP responders are updated to reflect end-entity revocation. (EV guidelines require 'OCSP responses from this service MUST have a maximum expiration time of 10 days.' - answer is 7 days.

Comment 15

[Kathleen Wilson]

Thank you for the information.

Please also respond to the other highlighted sections in the information gathering document:
1) Checklist for subordinate CAs operated by third parties. https://wiki.mozilla.org/CA:SubordinateCA_checklist
Which of these roots have sub-CAs that are operated by third parties?  Do they issue certs within their own company only? (OnSite agreement?) Or do they issue certs to other companies (Affiliate agreement?)
2) Test sites/certs
Test website (of an EV-SSL cert chaining up to the PCA3-G1 SHA1 root)
Test website (of SSL cert chaining up to the Universal Root) – I suspect this will be problematic as you haven’t issued any sub-CAs from this root yet.  However, this would be needed for testing of inclusion.
Test/sample certs  chaining up to PCA1 G1 SHA1 and PCA2 G1 SHA1
3) Review and comments on the relevence of the Potentially Problematic Practices listed in http://wiki.mozilla.org/CA:Problematic_Practices


> Here is the updated Audit report for 2008, which includes EV:
> https://cert.webtrust.org/SealFile?seal=304&file=pdf

Is the ECC (PCA3-G4) root covered by any of the audits in this seal file?

I see that this seal file contains three audit reports and the corresponding management assertions:
1)	WebTrust for CA -- In regards to this request, this audit covers
a.	VeriSign Universal Root Certification Authority (bug #484901)
b.	VeriSign Class 1 Public Primary Certification Authority – VeriSign, Inc (PCA1 G1 SHA1)  (bug #490895)
c.	VeriSign Class 2 Public Primary Certification Authority – VeriSign, Inc (PCA2 G1 SHA1) (bug #490895)
d.	VeriSign Class 3 Public Primary Certification Authority – VeriSign, Inc (PCA3-G1 SHA1) (bug #490895)
2)	WebTrust for CA for the VeriSign ECA
a.	This audit is specifically for the VeriSign DOD External Certification Authority, which is not part of this request.
3)	WebTrust for EV In regards to this request, this audit covers
a.	VeriSign Class 3 Public Primary Certification Authority – VeriSign, Inc (PCA3-G1 SHA1) (bug #490895)

I did not find mention of the ECC root in the audit report or management assertions:
VeriSign Class 3 Public Primary Certificate Authority - G4 (bug #409235)

> CRL for end-entity certs
http://crl.verisign.com/pca1.crl
http://crl.verisign.com/pca2.crl
http://crl.verisign.com/pca3.crl 
The NextUpdate for these CRLs is 4 months. However, according to the CPS the “CRLs for end-user Subscriber Certificates are issued at least once per day.” 
Perhaps there are different URLs for the CRLs for the end-entity certs chaining up to these roots?

> OCSP
>  - Verisign Class 3 Public Primary Certificate Authority (PCA3 - G1.5 SHA 1
> Version) - answer is Yes

Please provide the OCSP Responder URL

Comment 16

[Jay Schiavo]

Here are a couple of updates to the questions above:

The Roots do not issue end-entity certs.  They only issue CRLs and SubCA
certificates.  Our SubCAs sign new CRLs daily (or more frequently).  Here
are some examples:

Class 1: http://crl.verisign.com/IndC1DigitalID.crl
Class 2: We have no active SubCAs under this Root.
Class 3: http://crl.verisign.com/SVRSecure2005.crl

URL for OCSP: http://ocsp.verisign.com

Comment 17

[Kathleen Wilson]

Thanks for the info.

> Our SubCAs sign new CRLs daily (or more frequently).  

Yes, that is what I am looking for – the CRLs for subCAs chaining to the roots in this request.

> Here are some examples:
> Class 1: http://crl.verisign.com/IndC1DigitalID.crl

Issuer CN = VeriSign Class 1 Individual Subscriber CA – G2
Based on this, I think that the issuer of this CRL chains up to the PCA1 G2 root. However, the root under discussion is this request is VeriSign Class 1 Public Primary Certification Authority – VeriSign, Inc (PCA1 G1 SHA1). Can you provide the URL to a CRL of a subCA of the PCA1 G1 SHA1 root?

> Class 2: We have no active SubCAs under this Root.

Will there be active subCAs under the VeriSign Class 2 Public Primary Certification Authority – VeriSign, Inc (PCA2 G1 SHA1) root?  If not, is there any reason to proceed with the request to include this root?

> Class 3: http://crl.verisign.com/SVRSecure2005.crl

Issuer CN = VeriSign Class 3 Secure Server CA
It looks like this is a CRL for the end-entity certs chaining up to VeriSign Class 3 Public Primary Certification Authority (PCA3-G1 SHA1).

NextUpdate is 2 weeks.

CPS section 4.9.7 indicates that CRLs for end-user Subscriber Certificates are issued at least once per day.

Why is NextUpdate 2 weeks, and not closer to daily?

> URL for OCSP: http://ocsp.verisign.com

Thanks.

Comment 18

[Jay Schiavo]

Here is a test site using a certificate issued by our SHA256 root:

https://ptnr-verisign256.bbtest.net

As we are not using this root publically yet, we did not issue this using an intermediate root, which we will do in our production environment.

Comment 19

[Jay Schiavo]

Under problematic practices, one of the items asked about by Mozilla is some of our roots issue out SubCAs operated by external third parties. For customers we create private subcas for that are signed by one of our roots - we host and control the subCA. Plus, for validation, we do upfront validation and delegate RA functionality out to them. This is all covered in our CPS.  There are some additional documents that our CPS references that can only be shared under NDA as they include our trade secrets with regards to our processes. We could provide certain pieces of the relevant sections once under NDA if necessary.

Comment 20

[Jay Schiavo]

Here is some additional information from the questions posed by Kathleen:

- What is the URL for the CRL of the subCA of the PCA1 G1 SHA1 root?

Verisign: The commonName of the SubCA ends with "G2", but it really is issued by PCA1 G1 Root. The CRL pointer again: http://crl.verisign.com/IndC1DigitalID.crl 

- Will there be active subCAs under the VeriSign Class 2 Public Primary
Certification Authority - VeriSign, Inc (PCA2 G1 SHA1) root?  If not, is
there any reason to proceed with the request to include this root?

Verisign: We won't be adding any new CAs that are signed by this Root (PCA2 G1). We do feel these roots should be included because these roots enable our customers to read their archived S/MIME mail.  There are business requirements to maintain 10 years or more of access to email.  Our customers paid a premium in their choice of these roots to get the value of being imbedded in browsers with a long
validation period. Removing these roots will "break" S/MIME in the eyes of most customers, even though technical workarounds could be implemented.   The customer would be required to fully understand and manage roots, which we know today is not realistic.  Given the huge number of terabytes of archived S/MIME mail worldwide we feel very strongly on these roots being included.

- For the CRL for the end-entity certs chaining up to VeriSign Class 3 Public Primary Certification Authority (PCA3-G1 SHA1). NextUpdate is 2 weeks.

CPS section 4.9.7 indicates that CRLs for end-user Subscriber Certificates are issued at least once per day. Why is NextUpdate 2 weeks, and not closer to daily?

Verisign: CRLs are issued at least once per day (they are actually issued more often than that).  They have a validity period of 2 weeks.

Comment 21

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Jay, please review this version of the Information Gathering document for accuracy and completeness.

Comment 22

[Jay Schiavo]

Here are our comments on the Information Gathering Document:

For the VeriSign Class 3 Public Primary Certification Authority - G4 (ECC) and the VeriSign Universal Root Certification Authority (SHA256) Roots we would also like to enable all trust bits, not just Websites and Code Signing. 

We also want to make the  VeriSign Class 3 Public Primary Certification Authority - G4 and the VeriSign Universal Root Certification Authority EV capable, but will submit a separate bug for that.

For the SHA1 versions for the G1 PCA Roots, we would like you to leave in the MD2 roots alongside the SHA-1 roots, because we've issued intermediates with AKIs that point to the MD2 versions.

This document states that the G4 root was not covered in our webtrust audit - per KPMG, our annual WebTrust for CAs reports for Verisign cover the effectiveness of CA controls including the CA key > generation process based on the WebTrust for CAs criteria.  Each audit cycle, KPMG tests various CA key generation ceremonies and identify specific production CAs in their reports.

Comment 23

[Jay Schiavo]

Attachment: Intermediate CA cert (binary DER) that chains up to the PCA1-G1 root

Example of a cert that chains up to the PCA1-G1 root

Comment 24

[Kathleen Wilson]

Thanks for the updates.

I am not able to open the sample cert attached in comment #23. Could you attach in different format?

Comment 25

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 390566 [details]
Intermediate CA cert (binary DER) that chains up to the PCA1-G1 root

This attachment is an ordinary binary DER cert. 
I've changed the MIME content type so that Firefox will attempt to "import" it when you download it, unless you "shift click" on the link to download it as a disk file.

Comment 26

[Kathleen Wilson]

Thanks Nelson.

Jay, I don’t seem to have recorded a url to a website whose EV-ssl cert chains up to the PCA3-G1 SHA1 root. Would you please provide this?  Note that it can be a test website.

Comment 27

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 28

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

[Kathleen Wilson]

Jay, please note that now that the discussion phase has begun, it is important that you provide the url to a website whose EV-ssl cert chains up to the PCA3-G1 SHA1 root. 

This needs to be provided ASAP, because folks use the test website to review the EV-SSL end-entity cert when evaluating the CA request and providing feedback.

Comment 30

[Jay Schiavo]

Here is an example of a site using an ev cert chaining up to PCA3 - G1: https://www.hp.com

Comment 31

[Kathleen Wilson]

Someone from VeriSign needs to respond to the questions that have been posted in the discussion thread as soon as possible.  Please post VeriSign's responses into the discussion.

In regards to the EV-SLL cert, when I view the website cert for https://www.hp.com/ I find that the cert chains up to the following root:

Class 3 Public Primary Certification Authority
Sha1: 74:2C:31:92:E6:07:E4:24:EB:45:49:54:2B:E1:BB:C5:3E:61:74:E2
Signature Algo: PKCS #1 MD2 With RSA Encryption

However, the root we are reviewing for inclusion is (PCA3-G1 SHA1):
Class 3 Public Primary Certification Authority – VeriSign, Inc  
sha1:  A1:DB:63:93:91:6F:17:E4:18:55:09:40:04:15:C7:02:40:B0:AE:6B
Signature Algo: PKCS #1 SHA-1 With RSA Encryption

I tried removing the MD2 root, to see if the website’s cert would chain up to the PCA3-G1 SHA1 root, but it did not – the website just failed to connect because it could not find the appropriate root in my browser.  I do have the PCA3-G1 SHA1 root imported.

Before we can close the discussion, we will need a url to a website whose EV-SSL cert chains up to the PCA3-G1 SHA1 root.

Comment 32

[Rick Andrews]

After internal discussions, we don't feel it's necessary to EV-enable the PCA3-G1 SHA-1 root. Please drop that part of the request. 

Regarding the question above, www.hp.com no longer serves the purpose because they recently renewed and their new cert chains up to a different root. Please use https://shop.spiegel.de. With the PCA3-G1 SHA-1 root in your trust store, you should see this cert chain up to that root.

Comment 33

[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 three new root certificates, as follows:

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.
Note: I am not recommending approval for the PCA2 G1 SHA1 root, because VeriSign has no active subCAs under this root and this root was only used for email.

VeriSign Class 3 Public Primary Certification Authority (PCA3-G1 SHA1), 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 these roots.

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.
* OCSP is provided for the PCA3-G1 SHA1 root, with maximum expiration time 7 days.

Based on this assessment I recommend that Mozilla approve the request to add the VeriSign Class 1 Public Primary Certification Authority (PCA1 G1 SHA1) and the VeriSign Class 3 Public Primary Certification Authority (PCA3-G1 SHA1) root certificates. Enabling the email trust bit for the PCA1 G1 SHA1 root, and enabling all three trust bits for the PCA3-G1 SHA1 root.

Comment 34

[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 #33, 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 1 Public Primary Certification Authority (PCA1 G1 SHA1) (email)

* VeriSign Class 3 Public Primary Certification Authority (PCA3 G1 SHA1) (web sites, email, code signing)

NOTE: I'm accepting Kathleen's recommendation not to approve the PCA2 G1 SHA1 root.

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 35

[Kathleen Wilson]

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

Comment 36

[Rick Andrews]

I'd like a clarification about PCA2 G2 SHA1. Kathleen's recommendation was to not approve this because "VeriSign has no active subCAs under this root and this root was only used for email."

We have active CAs under PCA2 G2 MD2 (same key as PCA2 G2 SHA1). The MD2 version will remain in the NSS trust store, correct? Our reason for wanting to add the PCA2 G2 SHA1 version was to prepare for the day when MD2 is broken and mozilla decides to remove it from the trust store. Users will still need to be able to read their old mail.

Can we reconsider this before the other changes are made?

-Rick

Comment 37

[Kathleen Wilson]

The PCA2 G1 SHA1 root cert did meet all the requirements and was included in the audit. With the exception that VeriSign did not provide a test cert, and did not explain what the hierarchy could be.

The response I got from VeriSign for both was:

VeriSign: We have no active SubCAs under this Root.

VeriSign: We won't be adding any new CAs that are signed by this Root (PCA2 G1). We do feel these roots should be included because these roots enable our customers to read their archived S/MIME mail.  There are business requirements to maintain 10 years or more of access to email.  Our customers paid a premium in their choice of these roots to get the value of being imbedded in browsers with a long validation period. Removing these roots will "break" S/MIME in the eyes of most customers, even though technical workarounds could be implemented.   The customer would be required to fully understand and manage roots, which we know today is not realistic.  Given the huge number of terabytes of archived S/MIME mail worldwide we feel very strongly on these roots being included.

Comment 38

[Rick Andrews]

Kathleen, I'm confused by what you said in Comment #33: "Note: I am not recommending approval for the PCA2 G1 SHA1 root, because VeriSign has no active subCAs under this root and this root was only used for email."

That sounds to me like you and Frank did not approve it for inclusion.

Comment 39

[Kathleen Wilson]

Yes, that is correct that we did not approve PCA2 G1 SHA1 for inclusion. As I stated again in Comment #37 VeriSign did not provide a test cert, and did not explain what the hierarchy could be. The reasons given by VeriSign for not providing this information made it sound like the root was already obsolete.

What I was trying to say in Comment #37 is that I'm of the opinion that if VeriSign does provide the requested information that all of the requirements will have been met, and I can recommend approval for this root.

Comment 40

[adundas]

Kathleen,  I have contacted the various team members to get a consensus on this.  VeriSign now supports your decision not to include the PCA2 G1 SHA1 root.  The documented use situations for this specific root are correct.  There are several SubCAs that chain to the existing PCA2 G1 MD2 root, but there have not been newly issued credentials for several years.

Comment 41

[Kathleen Wilson]

The following two root certificates have been added to NSS 3.12.8. The change is now waiting for Mozilla products to pick up this version of NSS. This process is mostly under the control of the release drivers for those products.

VeriSign Class 1 Public Primary Certification Authority (PCA1 G1 SHA1) 
VeriSign Class 3 Public Primary Certification Authority (PCA3 G1 SHA1)

Comment 42

[Kathleen Wilson]

I have confirmed that the following root certs are Builtin Object Tokens in Firefox 3.6.12. 

Friendly Name: VeriSign Class 1 Public Primary Certification Authority
SHA1:  CE:6A:64:A3:09:E4:2F:BB:D9:85:1C:45:3E:64:09:EA:E8:7D:60:F1 

Friendly Name: VeriSign Class 3 Public Primary Certification Authority
SHA1:  A1:DB:63:93:91:6F:17:E4:18:55:09:40:04:15:C7:02:40:B0:AE:6B