TSYS Application for SHA-1 Issuance

[Nick Lamb]

As we might have expected, following Symantec's goof last week, they have now initiated a formal application on behalf of TSYS

https://cabforum.org/pipermail/public/2016-July/007999.html

I haven't been able to find the "version 1.1" process referred to in that post, version 1.0 was proposed by Andrew Whalley of Google back in June. Unless version 1.1 changes things significantly, the purpose of publishing the to-be-signed certificates (tbsCertificates) is to obtain feedback on their contents, so that the risk being taken is understood in advance of signing.

These appear to be essentially the same identities as for the mis-issued certificates from the earlier thread. They are in most respects other than the use of SHA-1 unremarkable (it seems to me -- I encourage others, particularly those with a lot of ASN.1 knowledge, to inspect for themselves) but one thing stands out to me

All of the certificate subjects have either TDS-2-Ashburn-SCA-bbL6gMDyTZU8 or
TDS-2-Dallas-SCA-v2PmB4cxayEu as the OU

The trailing part of each name appears to be gibberish. It seems very unlikely to me that there really is a "business unit" or "department" or even a meeting room at TSYS named bbL6gMDyTZU8. So presumably this value serves some other purpose.

IF prior SHA-1 certificates for TSYS FQDNs also had this unusual characteristic it might be less surprising (though I would still wonder what it was for) but looking back in crt.sh I can't see such gibberish in older certificates for TSYS FQDNs.

e.g. this one, issued in 2015 and expired earlier this year has the unremarkable OU = TDS-NewYork
https://crt.sh/?id=14854100

Does anyone know already of an explanation for the gibberish OU values in the to-be-signed certificates disclosed in this application ? If not, I believe that Mozilla should ask TSYS to explain these values or, if they cannot be justified, that it should request the application start fresh with a subject DN that matches one issued _prior_ to the 2016 moratorium as a show of good faith.

[Gervase Markham]

On 17/07/16 18:41, Nick Lamb wrote:
> All of the certificate subjects have either
> TDS-2-Ashburn-SCA-bbL6gMDyTZU8 or TDS-2-Dallas-SCA-v2PmB4cxayEu as
> the OU

Symantec have provided a response to this point on the CABF list (where
they wish formal discussion of the TSYS request to take place, which is
not unreasonable). If you are dissatisfied with the answer and wish to
prolong the conversation, I would be happy to forward mails to the CABF
list when requested.

Gerv

[Nick Lamb]

On Tuesday, 19 July 2016 14:03:47 UTC+1, Gervase Markham wrote:
> Symantec have provided a response to this point on the CABF list (where
> they wish formal discussion of the TSYS request to take place, which is
> not unreasonable). If you are dissatisfied with the answer and wish to
> prolong the conversation, I would be happy to forward mails to the CABF
> list when requested.

I would hope everyone is dissatisfied with their answer so far. Ryan Sleevi seems to be on top of this and I don't have anything to add to what he's written to TSYS, if he's able to wrestle a more satisfactory explanation out of them that'd be nice. Otherwise my position remains that Mozilla should ask TSYS to come back with tbsCertificates that lack the gibberish.

Unlike regular day-to-day SHA-256 issuance, we have every reason to assume that new SHA-1 issuance is actively targeted by adversaries intending a Merkle–Damgård chosen prefix attack. As a result, all the values in the tbsCertificate should as much as possible have a transparently obvious purpose so that there can be no suspicion that this tbsCertificate is part of an attack. Re-using most values from older certificates which pre-date any practical attack is a good way to achieve this. The claim that this new gibberish is an "independent cryptographically created identity value" is not transparent.

There is good news here in this application. These certificates are issued from an Symantec intermediate which, as far as I can see, is signed with pathlen:0 - thus a chosen prefix attack cannot produce a working CA certificate. And TSYS, unlike a random SSL applicant on some discount certificate site, has quite a reputation to lose if their application is hijacked to obtain a forged certificate. Nevertheless it makes sense for us to be cautious - allowing these exemptions does impose a risk to the web PKI that ordinary relying parties (e.g. Firefox users) see no direct benefit from.

[js...@letsencrypt.org]

> I would be happy to forward mails to the CABF list when requested.

I'm also happy to forward mail to the CABF list. I'd also like to remind everyone that it's easy to get direct posting access to the CABF list:

https://cabforum.org/wp-content/uploads/CA-Browser-Forum-Bylaws-v.-1.4.pdf
> Any person or entity that wishes to participate in the Forum as an Interested Party may do so by providing their name, affiliation (optional), and contact information, and by agreeing to the IPR Agreement attached as Exhibit A (indicating agreement by manual signing or digitally signing the agreement).

> Interested Parties may participate in Forum activities... by posting to the Public Mail List

I'd encourage folks who post here regularly to also become Interested Parties on CABF.