[cabfpub] Proposal of a SHA-1 exception procedure

Dean Coclin Dean_Coclin at symantec.com
Fri Jun 24 16:39:34 UTC 2016

Thanks to all the participants on yesterday’s call regarding this topic. We now have a clear and apparently final position from several browsers.

I think it was a good discussion among all parties and I’m sorry we didn’t get to the other topics on the agenda but I felt we needed to iron this out before proceeding.


The remaining unknown is Apple’s position with respect to the treatment of CAs that abide by the Google proposal. Geoff mentioned they were still evaluating it. It would be good to get some closure on this quickly as several processors have impending deadlines and have indicated a need to come forward soon. I don’t think Apple’s intended deprecation of SHA-1 in their own systems is necessarily relevant to the processors themselves.


Lastly, I produced a draft of the minutes but would like to listen to the recording one more time to insure I captured everything. I expect to have this completed over the weekend and will publish a draft then.




From: Eric Mill [mailto:eric at konklone.com] 
Sent: Monday, June 20, 2016 10:20 PM
To: Dean Coclin <Dean_Coclin at symantec.com>
Cc: Ryan Sleevi <sleevi at google.com>; CABFPub <public at cabforum.org>
Subject: Re: [cabfpub] Proposal of a SHA-1 exception procedure


The entity name has some direct utility in putting 3 through 8 in context, and making those answers more useful in understanding why companies ended up in the situations they did. For example, an answer to question 7 ("When and how did the Subscriber first become aware of the SHA-1 sunset?") of "August 2015" would be a lot different coming from AT&T than from a regional payment processor. Follow-on proposals to address each of them would likely be different.


But more concerning is the downside to declaring the entity name a secret -- once you do that, then it starts making sense to keep the answers to #2 (description of the infrastructure) and #9 (the certificate itself) a secret, since the certificate could probably be traced back to the entity through the hostnames or other metadata. Similarly, the respondent is likely to give more minimal answers to #3 through #8 in the interest of redacting details that might point to their identity. 


Making identifying oneself a requirement of obtaining a certificate removes disincentives to filing a full and complete report of why the multi-year, multi-stage SHA-1 deadline didn't work out for their piece of critical infrastructure.


It's not surprising that payment processors are reluctant to provide their names, and legal departments will be a barrier. But if it's truly critical that an organization receive SHA-1 certificates to continue operations, that barrier shouldn't be insurmountable.


On Mon, Jun 20, 2016 at 12:02 PM, Dean Coclin <Dean_Coclin at symantec.com <mailto:Dean_Coclin at symantec.com> > wrote:

Eric- I get that. Lessons learned is a great tool for future deprecations. But what I think the processor industry doesn’t understand is how the particular name of the applicant helps toward that end. What difference does it make if the applicant name is Chase, TSYS, Worldpay, or Blueswipe?  It seems the valuable answers to help future deprecations are those to questions 3-8 (i.e. what steps have been taken, impact, expected transition time, awareness, etc). How does the specific entity name address your goal?



From: Eric Mill [mailto:eric at konklone.com <mailto:eric at konklone.com> ] 
Sent: Saturday, June 18, 2016 11:25 AM
To: Dean Coclin <Dean_Coclin at symantec.com <mailto:Dean_Coclin at symantec.com> >
Cc: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> >; CABFPub <public at cabforum.org <mailto:public at cabforum.org> >
Subject: Re: [cabfpub] Proposal of a SHA-1 exception procedure


On Fri, Jun 17, 2016 at 6:35 PM, Dean Coclin <Dean_Coclin at symantec.com <mailto:Dean_Coclin at symantec.com> > wrote: 


>>I think this is the crux of the issue which will require dissecting this sentence. First, “That includes the necessary disclosures and information so that we can gather information necessary to avoid such situations in the future”: This is great and  I don’t think anyone has an issue with gathering this information so the CA/B Forum and root store operators can avoid future issues. The second part, “while having the necessary transparency for us effectively accepting, on behalf of the Internet trust ecosystem, the security risks” focuses on the security risks which I thought were ameliorated by the cryptanalysis. Is this not true?


The cryptanalysis ameliorates risks associated with the basic technical weaknesses that prompted the SHA-1 deprecation. It doesn't speak to any risks associated with how long it has taken the ecosystem to migrate away from SHA-1.


Those risks are just as real, especially since continued issuance of SHA-1 signatures by any one actor creates risk for all actors. And they'll be just as real when it's time to deprecate SHA-2, or to deal with practical quantum computing. To the extent the SHA-1 deprecation is a dry run for future migrations, the cryptanalysis is less important than the business analysis -- an analysis the entire community needs access to.


-- Eric



konklone.com <https://konklone.com>  | @konklone <https://twitter.com/konklone> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160624/34e34725/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5723 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160624/34e34725/attachment-0001.p7s>

More information about the Public mailing list