Inclusion of VeriSign EV root in Firefox 3 betas for testing
Frank Hecker
inclusion of the VeriSign EV root CA certificate in the new version of
NSS to be included in Firefox 3, so that developers and others may test
out the new EV-related functionality in NSS and Firefox 3 beta releases.
Unless anyone has strong and principled objections I'm going to approve
this request. Note that this doesn't constitute final approval of
VeriSign for Extended Validation purposes, since we don't yet have a
final version of the new Mozilla CA certificate policy that addresses EV
certificates. However the general changes to be made to the policy are
clear, even if the language is final, and to my knowledge VeriSign comes
as close to satisfying the proposed revised policy as any other CA. This
includes updating practices to conform to the final 1.0 version of the
CAB Forum guidelines, as noted in the most recent relevant CPS:
http://www.verisign.com/repository/CPS/VeriSignCPSv3.5.pdf
(See Appendices B1 through B4.)
Note that I don't want to unfairly put VeriSign at an advantage
vis-a-vis other CAs in terms of EV support in the Firefox 3.0 final
release. Therefore my priority is to get the 1.1 revision of the Mozilla
CA certificate policy in place as soon as possible and proceed
immediately to consider other CAs who have EV roots they'd like to include.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Frank Hecker
> However the general changes to be made to the policy are
> clear, even if the language is final,
s/final/not final/
Wan-Teh Chang
>
> 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.
I believe this is a new root entirely. If it is chained to an existing root in
NSS, we don't need to add it to NSS.
Wan-Teh
Eddy Nigg (StartCom Ltd.)
--
Regards
Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: star...@startcom.org <xmpp:star...@startcom.org>
Blog: Join the Revolution! <http://blog.startcom.org>
Phone: +1.213.341.0390
Frank Hecker
> 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 Hecker
Not so, as I understand it. See my message I just posted, and blame
blord if I have it wrong :-)
Andrews, Rick
> From: "Eddy Nigg (StartCom Ltd.)" <eddy...@startcom.org>
> Subject: Re: Inclusion of VeriSign EV root in Firefox 3 betas for
> testing
> To: Wan-Teh Chang <w...@google.com>
> Cc: dev-tec...@lists.mozilla.org
>
> Wan-Teh Chang wrote:
> > On 11/7/07, Eddy Nigg (StartCom Ltd.)
> <eddy...@startcom.org> wrote:
> >
> >> 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.
> >>
> >
> > I believe this is a new root entirely. If it is chained to
> an existing root in
> > NSS, we don't need to add it to NSS.
> >
I can confirm that it is an entirely new root. The CN is 'VeriSign Class
3 Public Primary Certification Authority - G5'.
-Rick Andrews
Eddy Nigg (StartCom Ltd.)
> I've received a request from the NSS development team that I approve
> inclusion of the VeriSign EV root CA certificate in the new version of
> NSS to be included in Firefox 3, so that developers and others may test
> out the new EV-related functionality in NSS and Firefox 3 beta releases.
>
> Unless anyone has strong and principled objections I'm going to approve
> this request.
is an entirely new root and not the flagging of an existing root as EV.
The Mozilla CA policy states clearly under section 14 that a CA should
submit a formal request by submitting a bug report
<https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=CA%20Certificates>
into the mozilla.org Bugzilla system, filed against the "CA
Certificates" component of the "mozilla.org" product. The request should
include the following....etc..etc...
In addition to that, a practice and process has been developed which
includes the involvement of the community for the acceptance of a CA
root. This gives the community members the chance to validate the
information and raise eventual issues and concerns. In this, as in any
other case I think it's appropriate to follow the same rules for all. It
is even more important when we are talking about the market leader!
Additionally without Mozilla having formal request which indicates that
the CA in question wants to have the root published in this software at
all, there might be legal concerns as well. Otherwise why not include
this CA root: http://www.verisign.com/repository/roots/pca_certificate.html
CA roots are first of all the property of the CA and by making a formal
request the CA indicates the interest in having the root included in the
software. It also implies to some extend that the CA in question wants
to adhere to the Mozilla CA policy...There are more factors and legalese
involved, but I guess I'm making the point here....
If there is a need to test EV-related functionality in NSS and Firefox 3
beta releases, than there are other CAs which have been admitted
recently which would conform to the "to-be-published" updated Mozilla CA
policy. Should the CA certificate in question be chained to an existing
root nevertheless, than this should be only a minor and formal issue and
you can disregard the said above. In such a case, I'd only have some
technical and practical questions.
Eddy Nigg (StartCom Ltd.)
> 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
this scenario, is it a requirement to have the (EV anabled) CA
certificate in NSS or are there other indicators which could make NSS
aware of it?
Eddy Nigg (StartCom Ltd.)
the root in question. We could simply follow the chain up to the CA root
already in NSS.
Frank Hecker
> Yes, this would be the technical question which I mentioned earlier. In
> this scenario, is it a requirement to have the (EV anabled) CA
> certificate in NSS or are there other indicators which could make NSS
> aware of it?
I think the issue is that the CA cert in question (VeriSign PCA3 G5)
needs to be both specifically known to NSS (i.e., preloaded) and also
marked with EV metadata (i.e., the associated EV policy OID). Otherwise
the CA cert will be unknown to NSS, and NSS will treat it as an
intermediate CA cert chaining up to a separate known root (PCA3 G1).
Note that the VeriSign case is distinct from the case where an existing
root CA cert is simply marked with EV metadata. I don't know which (if
any) CAs plan to take this approach.
Frank Hecker
> the root in question. We could simply follow the chain up to the CA root
> already in NSS.
I gave an example already in my previous message:
<https://www.fnac.com/>. <https://www.paypal.com/> shows this as well.
Also, you can try these in Vista/IE7 to see how they're handled there
vs. XP/IE6.
Eddy Nigg (StartCom Ltd.)
> Eddy Nigg (StartCom Ltd.) wrote:
>
>> Frank, the best test might be, if you could point us to a site signed by
>> the root in question. We could simply follow the chain up to the CA root
>> already in NSS.
>>
>
> I gave an example already in my previous message:
> <https://www.fnac.com/>. <https://www.paypal.com/> shows this as well.
>
Frank Hecker
> http://www.mozilla.org/projects/security/certs/included/
> It seems there are some CAs which would issue from an EV enabled root.
Yes, those are CAs that indicated to Gerv that they would be issuing EV
certs. I haven't yet checked these to confirm that the roots in question
actually have associated EV policy OIDs and are otherwise ready for EV
treatment from a technical standpoint (leaving the policy issues aside
for now).
Note that my goal here is *not* to bump VeriSign to the front of the
line and show them favoritism. My goal is simply to help the NSS team
out with their testing efforts, for a particular EV-related scenario
that needs good testing. I would be glad to entertain requests from
other CAs that want EV treatment for their certs as well, and will do my
best to process those requests in a timely manner.
Eddy Nigg (StartCom Ltd.)
there are no objections from me or anybody else I guess. I still own you
an answer concerning the policy update and intend to this soon.
Andrews, Rick
> From: "Eddy Nigg (StartCom Ltd.)" <eddy...@startcom.org>
> Subject: Re: Inclusion of VeriSign EV root in Firefox 3 betas for
> testing
> Cc: dev-tec...@lists.mozilla.org
>
> Frank Hecker wrote:
> > Eddy Nigg (StartCom Ltd.) wrote:
> >
> site signed by
> >> the root in question. We could simply follow the chain up
> to the CA root
> >> already in NSS.
> >>
> >
> > I gave an example already in my previous message:
> > <https://www.fnac.com/>. <https://www.paypal.com/> shows
> this as well.
> >
> OK, thanks! Looks like it's chained to an existing root....
There appears to be some confusion around this root. Let me try to
clarify:
Microsoft made a significant change in Windows Vista regarding embedded
root certificates: the OS ships with only a small handful of
certificates deemed essential to Windows. That does not include
VeriSign's roots. Instead, Microsoft has built into Vista the ability to
obtain trusted root certificates silently, on demand from Windows
Update. This ability is part of Windows XP as well, although XP shipped
with a large number of roots. On XP or Vista, if the OS ever encounters
a root certificate that it does not have in its cached root store, it
will check with Windows Update to see if it can obtain the root there.
If Windows Update knows about the root, it will return the root
certificate along with any meta-data that goes along with it. For
example, roots that can sign EV certificates are marked with special
meta data, not with any special indication in the certificate itself.
It's important to note that if Windows XP or Vista encounters a root
that is already in its cached root store, it will not check with Windows
Update to see if the meta-data has changed. And if a root is downloaded
from Windows Update, it will remain in the computer's root cache until
it expires.
When VeriSign planned to create a new certificate hierarchy from which
to issue EV SSL certificates, we naturally wanted to use our existing
root as the root of that hierarchy. That root is widely deployed in a
large number of browsers, both on desktops and handheld devices such as
cell phones. These older browsers know nothing of EV and cannot display
green toolbars, yet it is a firm requirement that they should be able to
establish a secure SSL session with EV-protected web sites. They should
not display any warning dialog, such as they might if the web site's
certificate chained up to an unknown, untrusted root.
We needed Microsoft to create the meta-data for our root that would
indicate that it is a root that can issue EV certificates. However,
there was a problem: Microsoft pointed out that Vista, since it did not
ship with our root, would retrieve our root and the associated EV
meta-data; but XP, since it shipped with our root, would not fetch the
EV meta-data from Windows Update. XP users would not be able to see the
green toolbar.
We investigated many ways of getting the root meta-data into Windows XP
systems. Microsoft suggested creating a new root that would carry the EV
meta-data, and cross-sign the new root with our old root. This is the
solution we implemented.
Web servers with a VeriSign EV cert are configured with the end entity
cert and two intermediate CAs: the EV CA and a cross-signed cert. The
chain looks like this:
end-entity int. CA cross-cert
issuer: EV CA -> PCA3-G5 -> PCA3-G5
subject: <www.foo.com> -> EV CA -> PCA3
Hence, old browsers will see this end-entity cert as chaining up to
PCA3, our old root that is already in their browsers. They will accept
it as a trusted chain.
If the IE7 on Vista user has our PCA3-G5 root and then hits this site,
the browser will see that the end-entity cert appears to chain up to two
roots: the old PCA3 root, and the new EV root called PCA3-G5. The path
to the old root is 4 levels deep, and the path to the new root is 3
levels deep. IE7 favors the shorter chain, and thus accepts this cert as
a trusted cert that chains up to an EV-capable root.
I'm sure I've confused a lot of people with this. I can try to go into
more detail if necessary.
-Rick Andrews
--
Rick Andrews __o Phone: 650-426-3401
VeriSign, Inc. _ \>,_ Fax: 650-426-5195
487 E. Middlefield Rd. ...(_)/ (_) URL: www.verisign.com
Mountain View, CA 94043 email: rand...@verisign.com
Frank Hecker
> Since the issue concerning new versus already included root is solved,
> there are no objections from me or anybody else I guess.
Excellent, I'll go ahead and tell the NSS guys to proceed as requested.
> I still own you
> an answer concerning the policy update and intend to this soon.
OK, looking forward to your comments.
Eddy Nigg (StartCom Ltd.)
Andrews, Rick wrote:
> Web servers with a VeriSign EV cert are configured with the end entity
> cert and two intermediate CAs: the EV CA and a cross-signed cert.
If so, wouldn't it be better to formally include the new (EV) root in
NSS in its own right instead of using the cross signed and chained to
the old root?
Andrews, Rick
Yes, I think we need to include the new EV root in NSS, as well as our
older PCA3 root. Web servers still need to be configured with the
intermediate and cross-signed certs so that older browsers that only
know about the older PCA3 root see the EV cert as chaining up to that
trusted root. FF3, if it has the new root in it, should ignore the
cross-cert and conclude that the intermediate CA chains up to the new EV
root.
-Rick
________________________________
From: Eddy Nigg (StartCom Ltd.) [mailto:eddy...@startcom.org]
Sent: Wednesday, November 07, 2007 1:42 PM
To: Andrews, Rick
Cc: dev-tec...@lists.mozilla.org
Subject: Re: Inclusion of VeriSign EV root in Firefox 3 betas
for testing
Hi Andrews,
Andrews, Rick wrote:
Web servers with a VeriSign EV cert are configured with
the end entity
cert and two intermediate CAs: the EV CA and a
cross-signed cert.
If so, wouldn't it be better to formally include the new (EV)
root in NSS in its own right instead of using the cross signed and
chained to the old root?
--
Regards
Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: star...@startcom.org
David E. Ross
> I've received a request from the NSS development team that I approve
> inclusion of the VeriSign EV root CA certificate in the new version of
> NSS to be included in Firefox 3, so that developers and others may test
> out the new EV-related functionality in NSS and Firefox 3 beta releases.
Will this be done only for testing purposes? Or will the certificate be
included in an end-user release without further analysis? Or will the
certificate be subjected to analysis per the final policy revision
before end-user release?
You have indicated that there is no intent to give VeriSign any
advantage over other CAs. If the certificate is included in an end-user
release without further analysis, will other EV certificates also be
included with the same pre-policy analysis?
In the meantime, I second Nigg's concern that a bug report is required.
The same process as already used for other certificates should be
followed, including a review of the CA's audit and a two-week comment
period. All this should be done before any end-user release. However,
testing could be conducted in parallel on an installation from which the
certificate could be removed prior to end-user release if the formal
process is not yet completed.
--
David E. Ross
<http://www.rossde.com/>
Natural foods can be harmful: Look at all the
people who die of natural causes.
Frank Hecker
> Will this be done only for testing purposes? Or will the certificate be
> included in an end-user release without further analysis? Or will the
> certificate be subjected to analysis per the final policy revision
> before end-user release?
My intention is to go back and evaluate VeriSign conformance to the
(revised) Mozilla policy as it relates to EV, same as I would for any
other CA that wants EV treatment. My short-term goal is just to get the
VeriSign cert into NSS for testing with Firefox 3 beta versions. Once I
get agreement on the revised policy then I'll solicit requests from
VeriSign and everyone else who'll be issuing EV certs, and those
requests will be handled in the normal way.
Eddy Nigg (StartCom Ltd.)
Would there be any problem with Verisign making a formal inclusion
request for the root(s) in question?
Andrews, Rick wrote:
> Eddy,
>
> Yes, I think we need to include the new EV root in NSS, as well as our
> older PCA3 root. Web servers still need to be configured with the
> intermediate and cross-signed certs so that older browsers that only
> know about the older PCA3 root see the EV cert as chaining up to that
> trusted root. FF3, if it has the new root in it, should ignore the
> cross-cert and conclude that the intermediate CA chains up to the new
> EV root.
>
> -Rick
--
Regards
Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: star...@startcom.org <xmpp:star...@startcom.org>
Andrews, Rick
________________________________
From: Eddy Nigg (StartCom Ltd.) [mailto:eddy...@startcom.org]
Sent: Wednesday, November 07, 2007 2:54 PM
To: Andrews, Rick
Cc: dev-tec...@lists.mozilla.org
Subject: Re: Inclusion of VeriSign EV root in Firefox 3 betas
for testing
Hi Rick,
Would there be any problem with Verisign making a formal
inclusion request for the root(s) in question?
Andrews, Rick wrote:
Eddy,
Yes, I think we need to include the new EV root in NSS,
as well as our older PCA3 root. Web servers still need to be configured
with the intermediate and cross-signed certs so that older browsers that
only know about the older PCA3 root see the EV cert as chaining up to
that trusted root. FF3, if it has the new root in it, should ignore the
cross-cert and conclude that the intermediate CA chains up to the new EV
root.
-Rick
--
Regards
Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: star...@startcom.org
Eddy Nigg (StartCom Ltd.)
> No problem at all. I'll see if I can do it this afternoon.
--
Regards
Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: star...@startcom.org <xmpp:star...@startcom.org>
Andrews, Rick
I have submitted Bug 402947
<https://bugzilla.mozilla.org/show_bug.cgi?id=402947> to Bugzilla. For
your convenience, here is the text:
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)
-Rick
--
Rick Andrews __o Phone: 650-426-3401
VeriSign, Inc. _ \>,_ Fax: 650-426-5195
487 E. Middlefield Rd. ...(_)/ (_) URL: www.verisign.com
Mountain View, CA 94043 email: rand...@verisign.com
________________________________
From: Eddy Nigg (StartCom Ltd.) [mailto:eddy...@startcom.org]
Sent: Wednesday, November 07, 2007 2:54 PM
To: Andrews, Rick
Cc: dev-tec...@lists.mozilla.org
Subject: Re: Inclusion of VeriSign EV root in Firefox 3 betas
for testing
Hi Rick,
Would there be any problem with Verisign making a formal
inclusion request for the root(s) in question?
Andrews, Rick wrote:
Eddy,
Yes, I think we need to include the new EV root in NSS,
as well as our older PCA3 root. Web servers still need to be configured
with the intermediate and cross-signed certs so that older browsers that
only know about the older PCA3 root see the EV cert as chaining up to
that trusted root. FF3, if it has the new root in it, should ignore the
cross-cert and conclude that the intermediate CA chains up to the new EV
root.
-Rick
--
Regards
Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: star...@startcom.org
Andrews, Rick
(http://www.mozilla.org/projects/security/certs/policy/) says 'a CA
should submit a formal request by submitting a bug report into thecomponent of the "mozilla.org" product.'
There does not appear to be any "CA Certificates" entry in the
"Component" popup, so I used "General".
Eddy Nigg (StartCom Ltd.)
also a URL location provided. I think there are some other things
missing as well, but the responsible person will catch up with you for
whatever is missing at the bug.
In any case it's great that you submitted the request!
Andrews, Rick wrote:
> BTW, Step 14 on the CA certificate policy page
> (http://www.mozilla.org/projects/security/certs/policy/) says 'a CA
> should submit a formal request by submitting a bug report into the
> mozilla.org Bugzilla system, filed against the "CA Certificates"
> component of the "mozilla.org" product.'
>
> There does not appear to be any "CA Certificates" entry in the
> "Component" popup, so I used "General".
>
> -Rick
>
>
--
Regards
Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: star...@startcom.org <xmpp:star...@startcom.org>
Nelson B Bolyard
>> I've received a request from the NSS development team that I approve
>> inclusion of the VeriSign EV root CA certificate in the new version of
>> NSS to be included in Firefox 3, so that developers and others may test
>> out the new EV-related functionality in NSS and Firefox 3 beta releases.
>>
>> this request.
> I would like to raise a few questions here. As Wan-Teh indicated, this
> is an entirely new root and not the flagging of an existing root as EV.
>
> The Mozilla CA policy states clearly under section 14 that a CA should
> submit a formal request by submitting a bug report
> <https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=CA%20Certificates>
> into the mozilla.org Bugzilla system, filed against the "CA
> Certificates" component of the "mozilla.org" product. The request should
> include the following....etc..etc...
>
> In addition to that, a practice and process has been developed which
> includes the involvement of the community for the acceptance of a CA
> root. This gives the community members the chance to validate the
> information and raise eventual issues and concerns. In this, as in any
> other case I think it's appropriate to follow the same rules for all. It
> is even more important when we are talking about the market leader!
>
> Additionally without Mozilla having formal request which indicates that
> the CA in question wants to have the root published in this software at
> all, there might be legal concerns as well. [snip]
Frank, In the past, Gerv rejected all CA cert requests that did not
originate from a representative of the CA itself, citing the policy.
By honoring a request to include the Verisign CA cert, which request did
not originate with a representative of the CA, this is an implicit change
in practice regarding the policy.
I think we should be absolutely consistent with regard to this aspect of
the policy. If we decide, now, that we ARE willing to accept requests
from third parties, then I think we should go back to the recently
rejected requests (in bugzilla) and reopen them and reconsider them.
Note that several requests have been sent to the members of the CABForum,
inviting them (begging them? :) to submit their new root CA requests to
mozilla (through bugzilla), and those requests for requests have been
largely ignored. Most of the CABForum CAs have not yet filed requests
for inclusion of their root CA certs in bugzilla.
I mention this because it may come to pass that, in order for EV to be
perceived by users as working in Firefox, it will be necessary for
mozilla to consider adding certs for CAs that have NOT requested the
addition of their certs. So, I think we should be prepared for the
possibility that the requests simply will not have arrived by the time
FF3 is ready to ship.
Perhaps you should consider asking the CABForum members, again, to apply
for inclusion of their EV roots in mozilla products.
/Nelson
Nelson B Bolyard
> BTW, Step 14 on the CA certificate policy page
> should submit a formal request by submitting a bug report into the
>
> There does not appear to be any "CA Certificates" entry in the
> "Component" popup, so I used "General".
The "FireFox" product does not have a "CA Certificates" component, but
the mozilla.org product does. I moved the bug to the right product and
component. Thanks for filing the request. I hope that more CABForum
members will do likewise soon.
/Nelson
Frank Hecker
> Frank, In the past, Gerv rejected all CA cert requests that did not
> originate from a representative of the CA itself, citing the policy.
>
> By honoring a request to include the Verisign CA cert, which request did
> not originate with a representative of the CA, this is an implicit change
> in practice regarding the policy.
I think this is a moot point now, at least with regard to VeriSign,
since Rick Andrews has now submitted bug 402947.
> Note that several requests have been sent to the members of the CABForum,
> inviting them (begging them? :) to submit their new root CA requests to
> mozilla (through bugzilla), and those requests for requests have been
> largely ignored. Most of the CABForum CAs have not yet filed requests
> for inclusion of their root CA certs in bugzilla.
<snip>
> Perhaps you should consider asking the CABForum members, again, to apply
> for inclusion of their EV roots in mozilla products.
I will do that, once the 1.1 policy is finished. (I hope I can declare
that done very soon, by the end of this week if possible.) Goodness
knows I have more than enough work to do evaluating inclusion requests
from CAs that have explicitly asked to be included. If I invite a CA to
have their EV root be included (or an existing root be marked as
EV-capable), and they don't respond to that invitation, then I likely
won't feel any obligation to do anything about their EV root.
Michael Ströder
> Wan-Teh Chang wrote:
>> On 11/7/07, Eddy Nigg (StartCom Ltd.) <eddy...@startcom.org> wrote:
>>> 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.
>>
>> I believe this is a new root entirely. If it is chained to an
>> existing root in
>> NSS, we don't need to add it to NSS.
>
> Not so, as I understand it. See my message I just posted, and blame
> blord if I have it wrong :-)
Who decided and why that EV meta data can only be added to trust anchors?
Ciao, Michael.
Eddy Nigg (StartCom Ltd.)
> Who decided and why that EV meta data can only be added to trust anchors?
>
one root and different intermediates which sign according to different
procedures. Haven't got to think about it, but if a root must be present
this would imply that most of the times the relevant intermediate CA
certificate signing EV certificates must be also included in NSS.
Frank Hecker
> Who decided and why that EV meta data can only be added to trust anchors?
I'm not sure exactly what you mean here. The particular technical
details of how "EV-ness" is represented in certificates and via
associated metadata were worked out by the various members of the CAB
Forum, and documented in (e.g.) section 7 of the EV guidelines.
Frank Hecker
>> Who decided and why that EV meta data can only be added to trust anchors?
>>
> This is actually a valid question, since at common CA setups there is
> one root and different intermediates which sign according to different
> procedures. Haven't got to think about it, but if a root must be present
> this would imply that most of the times the relevant intermediate CA
> certificate signing EV certificates must be also included in NSS.
I'm not an expert in this by any means, but I think this is addressed by
the section 7 text I referenced earlier: If a root has two subordinates,
one of which issues EV certs and one of which doesn't, then the CA cert
for the first subordinate includes the EV policy OID assigned to that
subordinate (or, as a special case for "in house" subordinates, the
"anyPolicy" OID), and NSS keeps a record of that EV policy OID as
metadata with the root CA cert.
So for subordinate 1 the process looks like this AFAIK:
1. NSS finds that the end entity cert has a policy OID.
2. NSS verifies that the subordinate 1 CA cert has that same policy OID
(or the anyPolicy OID).
3. NSS verifies that the same policy OID is stored as (pre-loaded)
metadata with the (pre-loaded) root CA cert.
4. NSS recognizes the policy OID as indicating "EV-ness" and does
whatever it does to accord EV treatment to the EE cert.
For subordinate 2, even though the end entity cert may have a policy OID
meant to indicate EV-ness, the subordinate 2 CA lacks that policy OID
(or the anyPolicy OID) and so the EE cert will fail the "EV test".
So AFAICT there's no need for NSS to pre-load the subordinate 1 CA cert.
Eddy Nigg (StartCom Ltd.)
> I think we should be absolutely consistent with regard to this aspect of
> the policy. If we decide, now, that we ARE willing to accept requests
> from third parties, then I think we should go back to the recently
> rejected requests (in bugzilla) and reopen them and reconsider them.
>
> inviting them (begging them? :) to submit their new root CA requests to
> mozilla (through bugzilla), and those requests for requests have been
> largely ignored. Most of the CABForum CAs have not yet filed requests
> for inclusion of their root CA certs in bugzilla.
>
> perceived by users as working in Firefox, it will be necessary for
> mozilla to consider adding certs for CAs that have NOT requested the
> addition of their certs. So, I think we should be prepared for the
> possibility that the requests simply will not have arrived by the time
> FF3 is ready to ship.
I'd like to make some of you aware of the latest entry by Rick from
Verisign of the bug 402947. Rick writes, that their EV audit is under
way...meaning that Verisign hasn't finished the process of the first
audit yet. This might give us an indication about why some/many of the
potential issuers of EV certificates haven't yet requested to have their
root(s) marked as such since auditing is still under way.
The inclusion request by Verisign confirms the Mozilla CA policy and
Mozilla's firm commitment to it. I'm very glad to see this happening
now, which sets an example for all CAs with legacy roots in NSS. There
will be no excuse by anybody, being it developer or CA not to undergo
the formal process Mozilla requires.
Eddy Nigg (StartCom Ltd.)
briefly?
--
Frank Hecker
> Verisign of the bug 402947. Rick writes, that their EV audit is under
> way...meaning that Verisign hasn't finished the process of the first
> audit yet. This might give us an indication about why some/many of the
> potential issuers of EV certificates haven't yet requested to have their
> root(s) marked as such since auditing is still under way.
Yes. Just to be clear on this: Since we now have a formal policy
relating to EV, and the policy requires completion of an EV audit per
the guidelines, I will not be approving any CA requests for permanent
upgrades to EV status until/unless the CAs in question finish their
audits and publish the accompanying auditor letters.
However in the meantime as I previously noted I will approve requests
from the NSS team for temporary EV upgrades and related changes in order
to do testing of the NSS EV code (e.g., for Firefox 3 beta). Such
approval does not constitute approval for permanent upgrades, which will
be handled per policy as discussed above.