[cabfpub] SHA1 Deprecation Ballot

Ryan Sleevi sleevi at google.com
Thu Mar 13 00:48:54 UTC 2014


I would have trouble supporting that ballot.


On Wed, Mar 12, 2014 at 5:36 PM, Ben Wilson <ben at digicert.com> wrote:

> After discussions earlier today with Doug, here is where I think we were:
> 9.8  Signature Algorithms
>
> Effective as of January 1, 2015, the maximum validity of a Subscriber
> Certificate signed with SHA-1 shall be 15 months, unless the CA documents
> that the Subscriber Certificate (and corresponding CRL or OCSP response) is
> for a system or software that:
>
> (a) is used by either the Applicant or a substantial number of Relying
> Parties;
>
> (b) will fail to operate if the Certificate, OCSP Response, or CRL is not
> signed with the SHA-1 algorithm;
>
> (c) does not contain known security risks to Relying Parties; and
>
> (d) is difficult to patch or replace without substantial economic outlay.
>
> Effective as of January 1, 2016, CAs SHALL sign all Subscriber
> Certificates using one of the following algorithms:  SHA-256, SHA-384,
> SHA-512, P-256, P-384, P-521, DSA 2048 (with prime q of 224 or 256 bits),
> or DSA 3072 (with prime q of 256 bits).  A CA MAY use the SHA-1 algorithm
> to sign Subscriber Certificates (including for re-keys, renewals, and
> corresponding CRLs or OCSP responses) beyond January 1, 2016, provided that
> the CA has documented that the system or software meet the four criteria
> above.
>
>
>
>
>
>
>
> *From:* public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] *On
> Behalf Of *Ryan Sleevi
> *Sent:* Wednesday, March 12, 2014 5:46 PM
> *To:* Eddy Nigg (StartCom Ltd.)
>
> *Cc:* CABFPub
> *Subject:* Re: [cabfpub] SHA1 Deprecation Ballot
>
>
>
>
>
>
>
> 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 roots.
>
>
>
> 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: <http://lists.cabforum.org/pipermail/public/attachments/20140312/597f9b09/attachment-0003.html>


More information about the Public mailing list