[cabfpub] SHA-1 exception request

Gervase Markham gerv at mozilla.org
Thu Oct 6 15:30:15 UTC 2016

On 03/10/16 15:26, Dean Coclin wrote:
> FD Response: We tested a private root and determined that this would
> not work for all affected clients. Modern POS systems would not have
> the pulled root and would need to manually add the private root. 

Hang on... in the last 12 months, this company has continued to ship
products with a root store based on the one browsers are choosing to
ship, and so have followed our root removal policy blindly? Rick Andrews
was telling me what a dumb idea this was back in the last decade. Please
tell me that isn't so.

And also, you can adopt what is now fairly mainstream technology, and
serve a cert based on the client capabilities as determined by client
HELLO - a new SHA256 one to modern terminals, or an older SHA1 one from
a pulled root to older terminals. This would have been more than
possible if you hadn't waited until 2 weeks before deadline day.

> The
> level of effort involved would be similar to if not greater than just
> upgrading or replacing Non SHA-2 compliant devices.

No, the level of effort involved in reconfiguring your servers is not
comparable to the level of effort involved in replacing 300,000 shipped

> Given the size and diversity of the POS device population there are
> no pulled roots that would remediate a significant portion of the
> 300,000 clients at risk.

We've had this a couple of times now. Who makes these devices, how many
different types are there, and what is the full list of roots in each
model? Presumably you have that data in order to make this statement.

> FD Response: FD initially communicated a June 30th deadline which
> would have provide a four month buffer before final expiry of
> existing certificates.

...under the wholly unrealistic scenario that everyone met the first

> Several large merchants and banks working on remediation plans
> through efforts such as contacting clients, upgrading POS software
> and/or deploying new compliant POS hardware requested that we extend
> the deadline to August 1st, which we did.

So the remaining 25% are all customers of banks not in that set?

> FD Response:  There are valid circumstances that would prevent
> communications from reaching the end user.

If you are one end of a secure connection and you can't communicate
security-related information to the person controlling the other end,
even when given 12 months to do it, you are doing it wrong.

> Most of these clients are small merchants with limited IT industry
> knowledge.  Many of them have bought/sold their businesses,
> inheriting the POS device.  Some have changed banking relationships.
> Others don’t have an active relationship with their POS vendor, or
> for many other reasons, may not even know who administers their POS
> system.

And yet you still accept, validate and process card transactions from
these anonymous and uncontactable people?

You don't need IT industry knowledge to receive a package with a credit
card terminal in it and plug it in, in place of your existing one. What
happens if one model of terminal turns out to have e.g. a broken RNG and
trivially-crackable crypto? Or leaks the private key? Would it take over
a year to replace all those, for the same reasons?

> Symantec: Links to the crt.sh entries were provided at the top of
> each certificate's disclosure in the second email. Each of the
> candidate toBeSigned certificates match the logged certificates they
> replace with the exception of the serial number and validity period.
> Matching was preserved to the extent of using T61String encoding, SGC
> EKU, and BR compliance policy OIDs from our arc rather than the
> CABF's.


> FD Response:  FD proposes an alternative that can highlight the need
> to address this issue without causing a sustained impact that would
> be more disruptive to merchant businesses.
> Beginning in the first week of October, FD is planning to conduct
> what we are calling “Short Burst” upgrades. We will regularly and
> continually upgrade to SHA-2 for short intervals on varying dates and
> times of day.  Non-compliant clients will be unable to process during
> these burst upgrade periods which should induce corrective measures.

Now that is a good idea. We are now six days into October; how's it going?


More information about the Public mailing list