[cabfpub] SHA1 options for payment processors
THollebeek at trustwave.com
Tue Mar 8 00:51:37 UTC 2016
For those who are worried about the possibility of stasis, transition is inevitable (and already occurring) because of PCI DSS.
For example, SHA-1 was banned in new point of sale devices about five years ago.
Also, X9.24 part 1, which should finally come out this year, bans any usage of SHA-1 whatsoever under any circumstances. So ATM operators will soon be getting failed audits if they don't transition.
The systems, standards, audits and regulatory requirements here are about two orders of magnitude more complex than the CA/Browser world, which is part of the problem.
From: public-bounces at cabforum.org <public-bounces at cabforum.org> on behalf of Richard Barnes <rbarnes at mozilla.com>
Sent: Monday, March 7, 2016 6:29 PM
To: Ryan Sleevi
Cc: Dean Coclin; CABFPub
Subject: Re: [cabfpub] SHA1 options for payment processors
On Mon, Mar 7, 2016 at 6:18 PM, Ryan Sleevi <sleevi at google.com<mailto:sleevi at google.com>> wrote:
On Mon, Mar 7, 2016 at 7:37 AM, Dean Coclin <Dean_Coclin at symantec.com<mailto:Dean_Coclin at symantec.com>> wrote:
When building security into their devices, some manufacturers included public roots from various CAs as far back as the 1990s. The CA/B Forum did not exist until 2006 and the first set of SSL/TLS Baseline Requirements didn’t become effective until 2012. Most of these manufacturers, who do not participate in the web PKI, were unaware that (1) these roots came under the domain of the Forum and (2) were subject to conditions of the Baseline Requirements. All customers of Symantec were made aware of the SHA-1 deprecation via numerous communication venues including many emails, snail mail, webinars and white papers. These customers are not the device manufacturers, but rather the payment processors (as an example) who use these devices in their payment clearing process.
To be fair, these roots have always been subject to the Browser's policies on root acceptance and behaviour - so the problem was certainly anticipated that, in order to continue to participate in the browser programs' root stores, there did need to be some degree of compliance to browser's policies. This goes back to the very first recognition of CAs - by Mozilla, then Microsoft, then others.
I only provide this to make sure it's clear that even then, there was a distinction between different use cases. This distinction - and the need to comply to the policies of an increasingly disjoint set (Palm, Sun/Oracle, Adobe, etc) that gave rise, in part, to the CA/Browser Forum.
So this problem existed, in some form, since the beginning.
These merchants include small shops, gas stations, dry cleaners, etc. and are located all over the world. While many users of SHA-1 certificates were able to request all they needed prior to the deadline, there were a number that either missed certain certificates, or did not understand that renewal of existing certificates was not permitted. This occurred despite repeated warnings about the SHA-1 deadline.
So these merchants are, in effect, asking the Internet to bear the collective risk of all of their secure communications, and, at least with some of these options, asking anyone who wishes to make secure connections to subsidize their insecurity, by requiring relying parties develop and support mechanisms for blacklists.
I highlight this because you've presented a very emotional justification for this, and so it's important that in examining those very compelling emotional appeals, that we also maintain the broader context.
I don’t have permission to use specific company names at this time, however, we have had extensive discussions with many of them and have explored options such as checking who else might be in device root stores (again, these are made by many manufacturers with a variety of ROMs, firmware, release dates), checking for revocation, checking for expiration, checking for poison extensions, name constrained intermediates, updating root stores, etc. While many use cases were solved by using “retired” roots, there exists a population that is not helped by that solution. The fact of the matter is, many *only* trust one particular Symantec/Verisign root. Of course, we are advising these customers not to use public roots for this purpose but sadly we don’t have a time machine handy to undo what exists today.
And this is really the crux of the matter.
I don't think it's reasonable or fair to ask the Forum to re-open a topic which was extensively discussed and debated, particularly when it would appear (at least in part) to be solely Symantec customers, without more data to share to the conversation.
If we allow ourselves to be swept up in the emotional pleas, then we sacrifice our objectivity, and our ability to reliably set standards that the Internet community moves forward with. Millions of organizations went through transitioning away from SHA-1, some at great expense and effort, and to suggest that we ignore all of that for the few who were unaware or ignored warnings is a difficult proposition that seems to be a smack in the face of all those who did it right.
To that end, if we're even going to entertain the topic, then it simply MUST be necessary for those parties who failed, and are thus asking the entire Internet community to accept an ever-increasing risk, to come to the conversation as full participants, rather than hiding behind a shield of anonymity that may, in part, be motivated by shame for failing to meet the deadlines or in being scared to reveal the technical insecurity of their sytems.
Each payment processor that I’ve spoken with will need anywhere from 3-7 SHA1 certs to cover their existing base of terminals. I was hoping to find one or two general solutions that could help all of them.
I am explicitly opposed to this approach of trying to find a general solution. As I tried to highlight above, such a solution is to ignore the millions of site operators who did the work necessary, and it is to ignore what is a unique opportunity to understand why, in the midst of what was otherwise a safe and orderly transition off of SHA-1, a CA and its users are proposing that all of this be undone.
This very topic was discussed extensively - in our Mountain View F2F as well - that the inability to set a deadline, and stick to it, with respect to SHA-1, will fundamentally undermine the legitimacy of this organization and its ability to set deadlines. Think - if we granted this, as a general exclusion, on the principle that some Symantec customers were inconvenienced, then what about all of the customers of DigiCert, Comodo, Entrust, or any other member or non-member CA in the Forum who moved heaven and hell to make the transition on time. What message would they walk away with? That their CA mislead them about how serious the deadline was - and thus future deadlines can be ignored? That there's flexibility in deadlines, if the CA is persistent enough? That they'll be granted exceptions from deadlines, if their use case is emotionally compelling enough?
There are very real impacts to our ability to collectively make the Internet more secure, and must be taken into context not just for the direct risks of continuing SHA-1 issuance, but also to the overall ecosystem.
To that end, I would reiterate - to have a productive discussion of this, if there is to be a productive discussion at all, these customers need to be able to come forward and publicly discuss their issues, so that we can make an informed, data-driven decision on a case-by-case basis as to how best to mitigate the risks - to the ecosystem, to policies, to these customers - rather than trying to generalize it with a papered-over solution that allows an untold number of SHA-1 certificates to be issued, particularly if it favors a single CA.
I am in complete agreement on this latter point. Any action that is taken here needs to be limited, fully transparent, and ultimately directed toward transition rather than stasis.
Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public