Eddy Nigg (StartCom Ltd.) wrote re the VeriSign EV CA:
> I'd like to know if this is a root which already exists in the NSS or is 
> chained to an existing root in NSS or if this is a new root entirely.

In this case the answer is "a root which ... is chained to an existing 
root in NSS". Bob Lord explained it all to me a while back, and I'll try 
to convey the situation accurately; if I get the details wrong I'm sure 
someone will correct me.

If you look at the VeriSign CA hierarchy

   http://www.verisign.com/repository/hierarchy/hierarchy.pdf

then the CA we're concerned with here is in the upper right of the 
diagram, "VeriSign Class 3 Public Primary Certification Authority - G5". 
This CA (which I'll call "PCA3 G5" for short) has under it the two 
subordinate CAs ("VeriSign Class 3 Extended Validation SSL CA" and 
"VeriSign Class 3 Extended Validation SSL SGC CA") by which VeriSign is 
issuing EV certificates.

As noted in the diagram, the certificate for PCA3 G5 is not a true 
self-signed root CA cert, but is issued from the existing VeriSign 
Public Primary CA ("PCA3 G1"), which has a self-signed root already in 
NSS. That means that today (i.e., in Firefox 2 and current Firefox 3 
builds) VeriSign's EV SSL certs are recognized as valid SSL certs 
(because a chain exists up to a recognized root), but are not given EV 
treatment. In this context PCA3 G5 is treated as just another 
intermediate CA. (You can see this by going to <https://www.fnac.com/> 
with Firefox 2 and looking at the cert details.)

The proposal for EV testing, as I understand it, is to add the CA 
certificate for PCA3 G5 to the NSS root list, and to mark it with the 
associated EV metadata. Then when the Firefox 3 beta releases encounter 
a certificate issued from either of the two VeriSign EV subordinate CAs, 
the chain processing will stop at PCA G5 (instead of continuing on to 
PCA G1). The EV metadata stored for PCA G5 will then cause NSS and PSM 
to treat the end-entity cert in question as an EV cert, and Firefox will 
present the EV UI.

Note that I think that at least some other CAs are planning to take a 
similar approach to incorporating EV certs into their hierarchy, i.e., 
introducing a new EV "root" signed by an existing root. My understanding 
is that the certificate path processing in these cases can get tricky 
because there two valid paths (up to the existing root and up to the new 
EV "root"); hence the need to get some good testing of these scenarios 
well before Firefox 3 final release.

Does this answer your question?

Frank

-- 
Frank Hecker
[EMAIL PROTECTED]
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Reply via email to