[cabfpub] SHA1 Deprecation Ballot

Ben Wilson ben at digicert.com
Mon Mar 3 18:05:12 UTC 2014


I agree with your view.  I’m just trying to get the “what-ifs” out in the open for discussion.  

Several times in the past the Forum has been criticized for not doing enough to consider the whole ecosystem.  

I’m just giving everyone heads-up on a potential future issue.



From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi
Sent: Friday, February 28, 2014 1:57 PM
To: Ben Wilson
Subject: Re: [cabfpub] SHA1 Deprecation Ballot




Why do you believe that Microsoft's review is the only way to discover "Application X" and its existence? Why wouldn't we, within the CA/B Forum, except either member CAs (or CAs affected by but not members) to mention "Application X" exists?


Likewise, it seems reasonable to presume that "Application X" is not a common scenario to begin with - otherwise, we expect CAs would already be talking about "Application X" and its impact to their issuance practices.


As such, it seems like the scope of "Application X" is going to be so minimal, that it would be entirely reasonable/preferable/better for the Internet to let "We still issue SHA-1 for Application X" to be a qualified finding during an Audit (presuming, of course, that such timelines are incorporated within the audit framework in a timely manner), and then allow Root Programs to make a decision about "Application X"?


I see no reason to hold up the entire progress based on a hypothetical "Application X". And if such a blanket exception to security needs to be carved out, Root Programs are perfectly capable of doing so - as they have already done for other such "Application X" exceptional scenarios (eg: RSA-1024 bit certs for certain applications - such as Symantec's issuance of a pb.com certificate that conflicts with the BRs in https://bugzilla.mozilla.org/show_bug.cgi?id=966350 )


On Thu, Feb 27, 2014 at 4:59 PM, Ben Wilson <ben at digicert.com> wrote:

Let’s say we adopt this as a guideline.  Then, what if we want to fine-tune it based on Microsoft’s July 2015 review of progress made?  How can we amend the guideline and put that amendment in place before January 1, 2016?  (Let’s say that based on Microsoft’s review, it appears that Application X and its users need more time.  Won’t a CA that is providing SSL services for Application X say that six months is not enough time for the CAB Forum to adopt an exception and for it to change its code and certificate issuance processes to allow an exception for Application X and its users)?  In other words, don’t we need feedback from Microsoft prior to July 2015 in order to put an amendment in place?   If we adopt this provision, won’t we need to revisit it in about 12 months? 



From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Doug Beattie
Sent: Thursday, February 20, 2014 11:55 AM
To: ben at digicert.com; public at cabforum.org

Subject: Re: [cabfpub] SHA1 Deprecation Ballot




While this may be obvious to most of us, we should explicitly state that all CA certificates in the hierarchy up to, but not including the publicly trusted root, must also not be SHA-1.





From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Wednesday, February 19, 2014 3:02 PM
To: public at cabforum.org
Subject: [cabfpub] SHA1 Deprecation Ballot


I’m not sure whether I’ve captured it all, but here is a rough draft of a possible ballot for the Baseline Requirements. 


Effective immediately CAs SHOULD begin migrating away from using the SHA-1 hashing algorithm to sign SSL/TLS and code signing certificates.   


Beginning January 1, 2016, CAs SHALL NOT use the SHA-1 hashing algorithm to sign SSL/TLS or code signing certificates.


Please provide your comments, edits, etc., 





Public mailing list
Public at cabforum.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140303/e0d170bf/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5453 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140303/e0d170bf/attachment.p7s>

More information about the Public mailing list