[cabfpub] SHA1 options for payment processors

Thu Mar 10 17:30:00 UTC 2016

Thank you. Let me add some more details to answer some of the questions and comments. See below…

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

On Mon, Mar 7, 2016 at 7:37 AM, Dean Coclin <Dean_Coclin at symantec.com <mailto:Dean_Coclin at symantec.com> > wrote:

Background:

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.

 >>Well yes, but given that the CA/B Forum doesn’t include these other actors, their exposure to these rules is limited. Not trying to make an excuse, just reality. Anyway going forward, I can assure you that at least for this ecosystem, browser roots will not be the preferred approach.

 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 very much doubt small merchants have a clue about this “collective risk”. All they know is they have a terminal to use to swipe cards. Wasn’t trying to be emotional, just presenting the facts. Just to clarify, the certificates are not for merchants but rather they payment processors. There are tens of thousands (and in some cases hundreds of thousands) of merchants that are affected here because their terminals won’t be able to connect to a server that has a SHA-2 certificate.

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.

As I said earlier, there are legacy reasons why these are Symantec customers but that shouldn’t have a bearing into finding a solution. What if this related to Western Digital customers that are exclusive to Comodo? I don’t understand this rationale.

Regarding coming forward, if the Forum were willing to offer concrete solutions, then I’m sure those that need this in a big way will come forward with their request. Otherwise, why would a vendor come forward to plead their case only to be told, “you messed up, you should have done this a long time ago, you are putting users at risk, we can’t help you and oh by the way, get ready for negative press, thank you very much”. This is why I put forth some options to consider. If you are saying the forum is willing to consider one or more of these options, I think you hear rather quickly from them. 

Having said that, I asked one of the payment processor trade associations (FS-ISAC) to chine in on behalf of their members:

“Who are the payment processors in the PPISC?”

“The PPISC is a council within FS-ISAC that focuses on acquiring card payment processing. In reports of processing metrics in the US, the PPISC members represent 11 out of the top 12 processors with trillions of US dollars of payments processed every year. In other regions, these companies also have significant processing operations. Businesses worldwide depend on the PPISC member companies for payment processing.”

“It is not the payment processors procrastinating or otherwise refusing to update to more secure certificates. Rather the fact that the vast number of legacy point of sale devices deployed from various manufacturers, coupled with the associated cost that the customer will have to bear to upgrade.

The shift to EMV was announced years in advance. It was assumed that the EMV liability shift would have “encouraged” merchants to upgrade, yet the adoption rate of EMV capable terminals left many older POS devices deployed in the smaller merchant space. These small businesses  will absorb the cost of the upgrade to the certificates or stop accepting card payments.”

We may also hear from another trade association shortly.

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 think I answered most of this in my previous email which provided history and background. Again, if the forum can say that “if you come forward, we will help you find a solution” then I think a productive discussion is worthwhile.  For example, it sounds like a blacklisted intermediate could be a solution (haven’t heard any negatives yet) but the reluctance is this was not meant to be used in this use case. Sure, I get that. But when circumstances are presented which affect a large population such as this, we have to be creative and not rule any out. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160310/7e920804/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/20160310/7e920804/attachment-0001.p7s>