[cabfpub] SHA1 Deprecation Ballot

[Rob Stradling]

Ben, some comments inline...

On 13/03/14 00:36, Ben Wilson 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.

As written, I think that if these proposed legacy exceptions apply 
anywhere, then they apply pretty much everywhere.

XP SP2 meets (a), (b) and (d) (where "substantial" means whatever the 
reader wants it to mean).

As for (c), surely SHA-1 cert signatures are a "known security risk" to 
either everybody or nobody.  If everybody, (c) is never met.  If nobody, 
then there's no reason to deprecate SHA-1 at all!

> 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).

There's no mention of CRLs or OCSP responses here, which logically means 
that SHA-1 is still permitted in 2016 and beyond.

I don't think this proposed Section 9.8 should stipulate the permitted 
algorithms.  Instead, reference Appendix A.

Incidentally, Appendix A needs an overhaul.  The "Validity period 
beginning on or before 31 Dec 2010 and ending on or before 31 Dec 2013" 
columns don't need to be there any longer.

> 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.

"re-keys" and "renewals" are Subscriber Certificates.  CRLs and OCSP 
response are not Subscriber Certificates, although "...to sign 
Subscriber Certificates (including...corresponding CRLs or OCSP 
responses" kinda suggests that they are!

I suggest: Delete the ")", and change "renewals," to "renewals)".

> *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 <mailto: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 <http://pb.com> cert -
> https://bugzilla.mozilla.org/show_bug.cgi?id=966350 ), and is the way
> forward for these sorts of 'legacy' issues.
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.