[cabfpub] SHA1 options for payment processors

[Richard Barnes]

On Mon, Mar 7, 2016 at 7:51 PM, Tim Hollebeek <THollebeek at trustwave.com>
wrote:

> 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.
>
While I agree that people do appear to pay attention to PCI-DSS, their
compliance deadlines are ... generous.  SSLv3 was deprecated by NIST in
2014, and the PCI deadline for removing it isn't until June 30, *2018*.
I'm having trouble finding explicit PCI-SSC guidance on SHA-1, but given
that SHA-1 got the same treatment in early 2015, I'm not optimistic.

Those are deadlines, but so far out that they might as well be stasis.


> 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.
>
To be clear, though, none of these standards, audits, or regulations would
have prohibited these organizations from upgrading to modern crypto sooner.

--Richard



>
> -Tim
>
> ------------------------------
> *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> wrote:
>
>>
>>
>> On Mon, Mar 7, 2016 at 7:37 AM, Dean Coclin <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.
>>
>>
>>>  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.
>
> --Richard
>
>
>
>>
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>> <http://scanmail.trustwave.com/?c=4062&d=0o7e1pXIv0x_EERHxnLgy1Fb_HsdGi1MMVF8Y7CAJQ&s=5&u=https%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2fpublic>
>>
>>
>
> ------------------------------
>
> 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...
URL: https://cabforum.org/pipermail/public/attachments/20160307/4b636a9d/attachment.html