On 7/4/14, 6:27 AM, Hubert Kario wrote:
The newly released NSS 3.16.3 doesn't include 1024 bit CA certificates
any more[1]. This will of course impact users of servers that still use
it.
<snip>
That's why I think that we should ship the intermediate CA certificates
to make Firefox continue to interoperate with such sites.
Hubert and all,
I apologize for my delay in responding to this. I was on a 3-week family
vacation, and am still trying to catch up.
Thank you for your consideration and input on this topic. I don't yet
have an answer, but I wanted to let you all know that we have been
looking into this.
== Background ==
We have begun removal of 1024-bit roots with the following 2 bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=936304
-- Remove Entrust.net, GTE CyberTrust, and ValiCert 1024-bit root
certificates from NSS
https://bugzilla.mozilla.org/show_bug.cgi?id=986005
-- Turn off SSL and Code Signing trust bits for VeriSign 1024-bit roots
There are two more sets of 1024-bit root changes that will need to follow:
https://bugzilla.mozilla.org/show_bug.cgi?id=986014
-- Remove Thawte 1024-bit roots
https://bugzilla.mozilla.org/show_bug.cgi?id=986019
-- Turn off SSL and Code Signing trust bits for Equifax 1024-bit roots
Note that in the future we may have to take similar action for SHA1
roots, or for other old roots that are being replaced with new and more
compliant roots (e.g. baseline requirements). So, there will be an
ongoing need to transition servers from using old cert chains to new
cert chains.
== Problem ==
Some web server administrators have not updated their web servers to
provide a new intermediate certificate signed by a newer root, even
though the CA has implored them to do so. For those websites, users may
get the Untrusted Connection error when the old root is removed.
== Possible Solution ==
One possible way to help mitigate the pain of migration from an old root
is to directly include the cross-signed intermediate certificate that
chains up to the new root in NSS for 1 or 2 years. With classic NSS path
building, the path with the newer issuer is taken, so path validation
will go through the (newer) cross-signed intermediate certificate. With
mozilla::pkix all paths are considered until path validation succeeds.
Therefore, directly including the cross-signed intermediate certificate
for a while could provide a smoother transition. Presumably over that
time, the SSL certs will expire and the web server operators will
upgrade to the new cert chains.
This does not mean that we would begin including intermediate certs upon
request. We would only consider using this approach as a way to provide
a smoother transition when we remove a root certificate. Mozilla would
determine when it is necessary to include an intermediate certificate
for the purpose of removing a root certificate.
== For this batch of root changes ==
We are still investigating if we should use this possible solution for
this batch of root changes. Please stay tuned and continue to share data
and test results that should be considered.
== Side note ==
3 - https://www.ssllabs.com/ssltest/analyze.html?d=groupon.my
The SSL cert for https://www.groupon.my/ is a 2-year cert that was
created on July 23, 2012, and expires on October 22, 2014, so hopefully
they plan to update their SSL cert and chain soon.
The intermediate cert on this site (USERTrust Legacy Secure Server CA)
expires on November 1, 2015, so I expect that the new SSL cert will not
be issued by this intermediate cert. So the website operator will have
to update the entire cert chain -- which they should do whenever they
update their SSL cert.
Thanks,
Kathleen
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
