[cabfpub] SHA1 Deprecation Ballot

Ryan Sleevi sleevi at google.com
Wed Mar 12 16:46:09 MST 2014

On Wed, Mar 12, 2014 at 4:36 PM, Eddy Nigg (StartCom Ltd.) <
eddy_nigg at startcom.org> wrote:

> On 03/12/2014 02:51 PM, From Doug Beattie:
> So, at this time, I’m in favor of:
> -          Specifying shorter max validity periods for SHA-1 SSL
> certificates (1-year starting Jan 2015?)
> -          Setting end dates for the creation of any new Root and
> Subordinate CAs with SHA-1
> -          Defining clear messaging to the user community regarding SHA-1
> -          Setting target dates for the next set of changes for improved
> security/performance (RSA-4096/ECC/SHA-512/etc)
> I’m against:
> -          Specifying an exact date at which no SHA-1 certificates can be
> issued globally
> -          Specifying the detailed legacy exceptions for using SHA-1
> after the sunset date
> Here it starts again...this is exactly what I'm afraid of and thought we
> should avoid. I prefer an exact date binding for all, clear limits when and
> for how long.
A "Strong +1" to Eddy's remarks.

I think if a CA is going to issue these 'legacy' certificates, it should be
exactly the same process as handling other legacy practices - eg: 1024-bit

It gets treated as a BR violation, it's a qualified finding, and, most
importantly for Root Store Operators/Browsers, precisely *because* it's a
qualified finding, that practice gets disclosed to the Operators.

Chrome's plan continues to remain aggressive - disallowing certain
algorithms/key sizes if their issuance date is after their sunset-grace
period, outright rejecting them if their validity period exceeds the
sunset-fail period, and eventually outright removing support entirely. As
such, a CA that (continues) to issue such certs would not (ultimately) be
causing outright risk to *current* versions of Chrome users.

However, such a qualified finding *would* be a point of concern for overall
trustworthiness, and *does* highlight that the CA is engaged in practices
for specific customers that may be dangerous overall, and that's exactly
the kind of thing a qualified finding can highlight. It's entirely possible
(read: probable) that it would not be an immediate cause for removal, but
would be something to work closely with the CA to ensure the BR violations
cease on an appropriate timeline.

This is the same way Operators are already handling legacy roots, and are
already handling 1024-bit certs (eg: Symantec's BR-violating issuance of a
pb.com cert - https://bugzilla.mozilla.org/show_bug.cgi?id=966350 ), and is
the way forward for these sorts of 'legacy' issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140312/0dea811c/attachment-0001.html 

More information about the Public mailing list