422918 - Add VeriSign Class 3 Public Primary CA - G5 to NSS

Status: RESOLVED FIXED

(NSS :: Libraries, enhancement)

Description

[Frank Hecker]

This bug requests inclusion in the NSS root certificate store of the following root CA certificate, owned by VeriSign:

1) Friendly name: "VeriSign Class 3 Public Primary Certification Authority - G5"
   SHA-1 fingerprint:
4E:B6:D5:78:49:9B:1C:CF:5F:58:1E:AD:56:BE:3D:9B:67:44:A5:E5
   Trust flags: Web sites
   URL:
https://bugzilla.mozilla.org/attachment.cgi?id=304810

The VeriSign Class 3 Public Primary Certification Authority - G5 has been assessed in accordance with the Mozilla project guidelines, and the certificate approved for inclusion per bug 402947.

The remaining steps are as follows:

1) A representative of the CA must confirm that all the data in this bug is correct, and that the correct certificate(s) have been attached. They must also specify what OS they would like to use to perform the verification below.

2) A Mozilla representative creates a test build of NSS with the new certificate(s), and attaches nssckbi.dll to this bug. A representative of the CA must download this, drop it into a copy of Firefox and/or Thunderbird on the OS in question and confirm (by adding a comment here) that the certificate(s) have been correctly imported and that websites work correctly.

3) The Mozilla representative checks the certificate(s) into the NSS store, and marks the bug RESOLVED FIXED.

4) At some time after that, various Mozilla products will move to using a
version of NSS which contains the certificate(s). This process is mostly under
the control of the release drivers for those products.

Comment 1

[Frank Hecker]

Attachment: VeriSign Class 3 Public Primary CA - G5 certificate

Comment 2

[Kai Engert (:KaiE:)]

Should there be a representative of Verisign on the CC list of this bug?
I'm adding jschiavo who I see is cc'ed on some other bugs.

Comment 3

[Kai Engert (:KaiE:)]

Dear Verisign representatives, you have not yet confirmed the information listed in this bug is correct.

I went ahead and included your certificate in a test build anyway.
Please read bug 425469 comment 3 to find the binary roots module for testing and follow Frank's requests given in this tracking bug.

Adding your roots to Mozilla/NSS is blocked pending your confirmation that everything is correct.

Please do not forget to verify the trust flags are correct.

Comment 4

[Rick Andrews]

We have tested with the test build, and everything looks fine. When we use FF to visit a site with an EV cert (www.verisign.com), the server returns this chain: EE->intermediate->cross cert->old root. But FF shows the chain as EE->intermediate->new root, which is the expected behavior. Thank you.

Comment 5

[Rick Andrews]

I just noticed the trust flags are not correct. We need all three set for this root, and only "web sites" is set.

Comment 6

[Frank Hecker]

(In reply to comment #5)
> I just noticed the trust flags are not correct. We need all three set for this
> root, and only "web sites" is set.

In evaluating your request I assumed that the G5 root was used only for issuance of EV SSL certs, through the subordinate CAs established under that root; that's why I specified "web sites" only in the VeriSign entry in the pending list, and in my comments in bug 402947.

If you do in fact issue (or plan to issue) email and code signing certs out of the G5 hierarchy, please point me to the relevant CPS section(s) that discuss this. Also, is this a case of EV certs that could also be used for email or code signing? Or are you referring to non-EV email or code signing certs issued out of the G5 hierarchy?

Final note: You have a similar issue with the new GeoTrust and thawte roots. I explicitly noted that trust bits for those were for SSL only, and no one contradicted me.

Comment 7

[Kai Engert (:KaiE:)]

Should we go ahead and start by adding the root now, with trust flag SSL only?

We could fix the trust flags at a later time.

Comment 8

[Frank Hecker]

If we can't resolve the trust flag issue right now, I suggest going ahead and fixing them later; this is especially true if the request for the email and code signing trust bits is in anticipation of future issuance of those certificates.

As I previously mentioned, in the relevant bugs and other material I have been very upfront about this and the other requests being for web site trust only; it's not as if I sprung this on anybody just now.

Comment 9

[Rick Andrews]

The desire for all the trust flags is for future use. The CAB Forum is talking about EV Code Signing certs, so when that is defined we expect to issue Code Signing certs that chain up to this root. As for mail users, we don't want to limit its use in the future.

Frank asked for a pointer to the relevant CPS section. Our CPS keeper says "The VeriSign EV root is simply a different generation PCA. The CPS does not limit the types of usage under different PCAs. A subscriber certificate under any class of  PCA may be used for Signing, encryption and authentication under the CPS. We don't differentiate in the CPS between Code Signing/S/Mime signing and other signing."

What is Mozilla doing for other CA roots? Just setting the "web sites" trust flag for now?

Comment 10

[Kai Engert (:KaiE:)]

This root was added to NSS for version 3.12 with a checkin noted in bug 425469.
Marking fixed.