On 28/07/14 19:00, Brian Smith wrote:
On Fri, Jul 25, 2014 at 3:11 PM, Kathleen Wilson <[email protected]> wrote:
<snip>
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.
I am not so sure. If the websites are using a cert chain like:
EE <- intermediate-1024 <- root-1024
then you are right. But, if the websites are using a cert chain like these:
EE <- intermediate-2048 <- root-1024
EE <- intermediate-2048 <- intermediate-1024 <- root-1024
Then it is likely that many of the websites may not update enough of
the cert chain to make the use of 1024-bit certificates to go away.
The particular case that Hubert mentioned at the start of this thread is
the "USERTrust Legacy Secure Server CA": 2 intermediate certs containing
the same Name and Public Key, one signed by a 1024-bit root and the
other signed by a 2048-bit root. i.e...
EE <- intermediate-2048 <- root-1024
EE <- intermediate-2048 <- root-2048
USERTrust Legacy Secure Server CA ceased issuing certs in September
2012, but many of those certs still have significant lifetime remaining.
All of the certificate holders were initially instructed to configure
their servers to serve the chain up to the 1024-bit root.
Since then, despite efforts to persuade certificate holders to
reconfigure their servers to serve the chain up to the 2048-bit root, a
significant proportion of the certificate holders have left their server
configuration unchanged.
I can see the attraction of bundling the second intermediate cert
(signed by the 2048-bit root) with Firefox and/or NSS, especially given
that Firefox/NSS doesn't attempt to fetch "missing" intermediates using
AIA->caIssuers URLs.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
