[cabfpub] SHA1 options for payment processors

[Richard Barnes]

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