[cabfpub] SHA1 options for payment processors

[Ryan Sleevi]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160307/e2daa579/attachment-0003.html>