[cabfpub] SHA1 options for payment processors

Dean Coclin Dean_Coclin at symantec.com
Sun Mar 13 19:45:27 UTC 2016

Let me get this straight: I offer to bring an affected party to a forum call and Google declines to participate because some minutes have been posted late? I don’t understand how an offer to essentially “depose” a witness in real time would be met with a “no, it’s not transparent so we will not participate”. These minutes can be verbatim text since we have a recording to work from. This is not an attempt to invoke any non-disclosure, it was merely a good faith effort to enable the CA/B community to ask questions in real time. Having said that, no parties have offered to do this. However, it may be possible to get a spokesperson from one of the trade associations that represents payment processors. If there is interest in that, I can see about scheduling it. 


From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Thursday, March 10, 2016 9:12 PM
To: Dean Coclin <Dean_Coclin at symantec.com>
Cc: CABFPub <public at cabforum.org>
Subject: Re: [cabfpub] SHA1 options for payment processors




On Thu, Mar 10, 2016 at 6:00 PM, Dean Coclin <Dean_Coclin at symantec.com <mailto:Dean_Coclin at symantec.com> > wrote:


>>I don’t think I asked for a “guarantee”, only an expression of assistance. To date, the communication has been fairly negative which doesn’t exude much faith from the requestors.


Understanding the scope of the problem, the nature of how the problem came to be, the nature of what's being requested, and the time frame in which the process will work are all key facets to determining whether or not an exception can or should be granted.


Again, I want to reiterate - without public discussion, there can simply be no exception from our end, and any CA that issues is at risk of action, including distrust, in order to protect users from that CA.


But I’m curious what “solution” will be explored given all the information I’ve provided. I don’t know what other information you expect to gain by talking directly to the end users. The “what, when, why and how” asked in the initial email have been answered.


They have not. I appreciate your view that it has been, but you can't show answers to the specific questions enumerated, then it doesn't help understand either the present situation or how to avoid this.


I welcome and appreciate if parties who are affected can reply to the specific set of questions posed, but without that, there really is no further room for discussion.


All you’re missing is the “who”.   It could be Big Bank of the East or Contoso Corp. How does that help determine a solution? Are you saying the name of the company will dictate the solution? 


I think having a party to directly communicate with, rather than a CA who directly financially benefits, is a reasonable request.


I think it's relevant to the public interest to know specifically which parties are requesting an exception that places the global Internet at risk.


I think it's relevant to be able to ask follow-up questions to the named party, rather than through an intermediate who would benefit from arbitrarily delaying the conversation, is beneficial. For example, WorldPay was granted by Mozilla because of the exigent circumstances that prevented any reasonable public discussion or debate. It's certainly reasonable to expect that future customers may benefit from this. It's hard not to view the objection to having those parties come forward as, in part, a means of delaying the opportunity to explore a solution to them until the only solutions viable are ones that benefit the CA and place users at risk.


I am well aware that this may be seen as "tinfoil hat", but the precise reason is we're talking about global trust. Transparency is necessary here. And given that, as it has been in the past with other deprecations, that it's consistently Symantec approaching the Forum and Browsers for such exceptions, it's reasonable to need to transparently understand why this keeps happening to Symantec customers.


Whatever the solution is, all parties will agree to publish the cert in CT and other lists (as previously mandated by Mozilla) so everyone will know the domain.  Having said that, I will see what I can do to have a “guest speaker” join our call next week as a first step.


I'm sorry, I simply must object to this. It fails to achieve the necessary public discussion and debate. The Forum is quite bad at publishing minutes already, there is a delay between one to two weeks, and no external parties can participate in those discussions - either in seeing exactly what's been said or in replying with reasonable and timely follow-ups.


To that end, if there is a party scheduled for the call, I must regrettably remark that we will participate in the discussion. It needs to be public and transparent, to which only the list presently affords that.


On a similar topic, today I was on a call with another affected party that was using a SHA-1 cert for server to server communication in a mission critical application in which the cert expires next week. No browser is involved.


Yet every browser is put at risk. Further, every non-browser user of TLS is also put at risk - from your wget and curl to your PHP and Python. You keep spinning the story to avoid this very key, critical detail.


Again, these folks aren’t attune to this issue as those in this forum and thought that since it didn’t involve browsers, they could get a SHA-1 certificate this year. His argument was that he could get a SHA-1 code signing cert, why not server to server. He was shocked to learn that we couldn’t do that and has no idea how to solve this for one of the largest banks in the world. I bring this up only to highlight the extent of this issue.


Unfortunately, you failed to highlight the extent of the risk.


Thank you.


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

More information about the Public mailing list