[cabfpub] SHA1 options for payment processors

Ryan Sleevi sleevi at google.com
Mon Mar 7 06:05:20 MST 2016


Can you clarify whether you've been asked as chair of the CA/Browser Forum,
or as Symantec's representative?

For example, with the WorldPay issuance recently, the solution that was
ultimately implemented clearly favored Symantec's interests, in that other
CAs (who, perhaps, have removed roots already capable of addressing this
problem) were not given an opportunity to participate and explore in this
system. If you are approaching on behalf of these organizations, perhaps it
would be more beneficial to specifically contribute who in the "payment
processor ecosystem" is indicating a need, so that other CAs may be able to
reach out and explore solutions that do not require any of your four
proposed solutions - which would seem the best of all worlds.

With respect to blacklisting, I think it's truly unfortunate that the
mechanism designed to address CA incompetence, malfeasance, or direct
misissuance is now being proposed as a solution that would allow CAs to
continue to offer a defective, insecure product - and to outsource the
costs of the maintenance of that product onto all relying parties. That is,
just as it's clear that preventing SHA-1 misissuance affects more than just
the TLS Web ecosystem, due to CAs encouraging disparate use cases to use a
trust anchor shared with web use cases, it's also clear that permitting
SHA-1 issuance affects, and puts at risk, more than just browser users. For
example, consider the vast ecosystem of server to server communication that
actually does intend to talk to the 'public' web (such as the many tools
using libcurl, wget, or their programming language's built in HTTPS
fetching capabilities) - none of these ecosystems would be able to
effectively, at scale, blacklist.

If we are to accept that, as the Forum, we entertain cases other than TLS
issuance, it would seem natural that, as a Forum, we would also have to
entertain the risks that certain practices pose to the non-browser
community, and balance our risk calculus appropriately.

So, to that end, I think it would be useful if someone has a use case for a
SHA-1 certificate - whether they're a direct customer of Symantec's or
expressing concern to you, as chair of the Forum - that the concerns be
shared in a public venue (such as by posting to questions at cabforum.org and
having someone repost on their behalf to public at cabforum.org)

When someone poses such a request, it would be useful to understand:
  a) Who the existing CA is
  b) When their current certificates expire
  c) What trust anchors their devices/clients support. If they're unable to
answer this, an understanding as to why they can't answer this
  d) When they first became aware of the SHA-1 sunset.
  e) Were they notified by their CA, or did they discover it through other
means
  f) When did they begin transitioning from SHA-1
  g) When do they anticipate finishing transitioning from SHA-1
  h) How many domains they would need reissued for SHA-1

Your approach, both with WorldPay and now with this topic again, is
operating on an assumption that the only way to satisfy these users is to
violate the Baseline Requirements and browsers' root program requirements.
That assumption, however, doesn't have the (public) evidence behind it, nor
have we gotten to an understanding of how we arrived here.

In posing the questions above, this helps better inform the Forum, so as to
evaluate options that may be provided by other CAs' non-BR compliant roots,
thus ideally avoiding the debate entirely. Further, it also helps to better
understand the nature and situation surrounding how this issue came to be a
critical issue that you've now brought to the Forum several times on
unnamed parties' behalf, so that we can see what opportunities there are,
in the future, to improve the situation for the inevitable deprecations
that will come.

On Sun, Mar 6, 2016 at 12:51 PM, Dean Coclin <Dean_Coclin at symantec.com>
wrote:

> I’ve been asked by the payment processor ecosystem to explore some options
> for assisting with the SHA-1 issue. The scope of this problem is quite
> large but there may be a few options for dealing with it which need vetting
> by this community. I’ll outline them below and *would appreciate some
> constructive feedback*:
>
>
>
> 1. Issue and then immediately revoke a new SHA-1 certificate.
>
> >>It turns out some payment terminals don’t check for revocation and this
> would fix a large percentage of them for one North American company.
>
>
>
> 2. Issue a cert with a poison critical extension
>
> >>Some terminals may work with this but we won’t know until it can be
> tested. This requires issuing a new SHA-1 cert with this extension.
> Browsers would see the extension and not allow this certificate to be used.
>
>
>
> 3. Issue a cert from a new, name constrained intermediate
>
> >> Same as #2 from a testing perspective. Browsers could blacklist this
> intermediate.
>
>
>
> It would be interesting to get feedback from not only the community at
> large but specifically browsers to know what to expect from a proposed
> ballot.
>
>
>
> Thanks,
>
> Dean
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160307/54a2a6bc/attachment.html 


More information about the Public mailing list