[cabfpub] SHA1 options for payment processors

Dean Coclin Dean_Coclin at symantec.com
Mon Mar 7 08:37:04 MST 2016


OK, let me provide some more background here that will hopefully help clear up some of the issues you identified:

 

As we are highlighting here, many non-browser customers have use cases which can only work with SHA-1 based publicly trusted certificates and the applications which use these devices are not fully prepared to migrate to SHA-2. These include devices such as payment terminals, point of sale and ATM machines as well as cable and set top boxes. Other CAs may also be getting these requests but given 

Symantec’s legacy in the industry (from Verisign), we probably are hearing about this more than others.

 

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. 

 

Issue:

Despite great efforts to reduce the number of affected devices (including using removed public roots), there are a significant number of non-browser devices that continue to face this issue. Replacing the devices affected is taking time due to the distributed nature of the equipment which can be located in corporations, stores, and homes. Much like the way consumers can purchase a telephone handset and plug it into their home, merchants can buy payment terminals from a variety of sources and utilize them for payment processing. 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. 

 

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.

 

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. The processors are aggressively replacing terminals but given the sheer numbers, it’s taking time to do so. In addition, the distributed nature of merchants and terminals doesn’t lend itself to an easy upgrade. Think about a charity that rolls out the credit card machine for their annual auction and then stores it for the rest of the year. This is just one example of the challenges they are facing in instituting the global upgrade.

 

Lastly, I’ve been asked this request as Symantec but have also been approached by industry reps as CA/B Chair. But this post is from Symantec. 

 

I hope this is helpful.

 

Dean Coclin

Symantec

 

From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Monday, March 07, 2016 2:05 PM
To: Dean Coclin <Dean_Coclin at symantec.com>
Cc: CABFPub <public at cabforum.org>
Subject: Re: [cabfpub] SHA1 options for payment processors

 

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 <mailto:questions at cabforum.org>  and having someone repost on their behalf to public at cabforum.org <mailto: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 <mailto: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 <mailto: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/d565ec2d/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5747 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20160307/d565ec2d/attachment-0001.bin 


More information about the Public mailing list