[cabfpub] SHA1 options for payment processors

Tue Mar 8 00:57:27 UTC 2016

While this addresses one part of Dean's request, it's worth noting he
listed examples outside the financial services industry, such as cable and
set top boxes as also being potential beneficiaries from a 'generalized
exception' approach.

Which is unsurprising - once you have a generalized mechanism, a whole
variety of use cases come forward; much as we've unfortunately seen with
things like certificate blacklists being proposed as a 'consequence free'
means to misissue, when they were designed from the start to prevent and
mitigate misissuance in the first place.

So I think we still need specific parties to come forward before the Forum
before being willing to entertain the discussions.

On Mon, Mar 7, 2016 at 4: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.
>
>
> 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.
>
>
> -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: <http://lists.cabforum.org/pipermail/public/attachments/20160307/67e9c53c/attachment-0003.html>