[cabfpub] SHA1 options for payment processors

Erwann Abalea Erwann.Abalea at docusign.com
Mon Mar 7 10:13:02 UTC 2016


Proposed solutions 1 and 2 may technically work, but if they do, it means the payment processor ecosystem users are already at risk today. Scary.
Proposed solution 3 may not need a technically constrained CA certificate if browsers are willing to distrust this CA certificate. Maybe you thought of issuing certificates that didn’t respect the name constraints?

If 1 and/or 2 can work, maybe another solution can work: issue certificates for a different name and see if payment processor accepts them. Browsers shouldn’t.

Anyway, expecting trust out of these dirty hacks is a dangerous bet.

Erwann Abalea

Le 6 mars 2016 à 21:51, Dean Coclin <Dean_Coclin at symantec.com<mailto:Dean_Coclin at symantec.com>> a écrit :

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.

Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160307/b4852208/attachment-0003.html>

More information about the Public mailing list