[cabfpub] Application for SHA-1 Issuance

[Andrew Ayer]

Thanks, Dean, for adding the CC.  Here are my questions for TSYS.  I
also have some concerns regarding the answer to question 9 that both
TSYS and Symantec should consider carefully.

Question 3

Has using a pulled root been tried yet, or are you speculating
what would happen if a pulled root were used?

One option, if some clients are receiving updates and others aren't, is
to serve different certificate chains depending on the TLS handshake.
If the handshake indicates support for SHA-2, you serve a SHA-2
certificate from a trusted root.  Otherwise, you serve a SHA-1
certificate from a pulled root.  Facebook and CloudFlare use this
technique successfully.

Facebook and CloudFlare use custom code, but Apache has
out-of-the-box support for selecting certificates based on key
algorithm, so you could serve a SHA-2 ECDSA certificate to clients
that support ECDSA, and a SHA-1 RSA certificate (from a pulled
root) to clients that don't.  This would work as long as the
clients that don't support ECDSA recognize the pulled root.  See:
https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatefile

Has this technique been tried yet?  If not, could it be?


Question 7

"11/30/2015 - Symantec report of remaining SHA1 certs sent internally by TSYS"

Did this report include the certificates for the four FQDNs in
this application?  If not, why not?

If it did, why did TSYS not obtain SHA-1 certificates for these FQDNs
between November 30 and December 31?  Other organizations stockpiled
long-lived SHA-1 certificates before the sunset to allow themselves
extra time to migrate away from SHA-1.  Was TSYS aware of this
possibility?


Question 9

"One thing you will notice is the validity date extends to Feb 10,
2017. In the payment industry, 31 December is an absolutely horrible
time to make a change as it represents one of the peak times for traffic."

Although the "Post Jan 2016 SHA-1 Issuance Request Procedure" version
1.1 mandates an expiration of December 31, 2016 or earlier, I think a
later expiration is fine.  The risk to the public from SHA-1 manifests
during issuance and a later expiration date does not affect this risk.
In fact, it would be better for TSYS to have some extra time than it
would be to invoke this procedure again.

A more serious problem with this request is that every TBSCertificate
uses a brand new key pair that first appeared in certificate
transparency logs only a few days ago.  An explanation for why new key
pairs are needed has not been provided as required by the Request
Procedure.  Also troubling is that every TBSCertificate contains
inexplicable gibberish in the Subject OU (e.g.
"TDS-2-Dallas-SCA-v2PmB4cxayEu") that does not appear in any
certificate known to exist before 2016.  Furthermore, the order of
extensions is different from pre-2016 certificates for these FQDNs.

As Peter Bowen explained in
<https://cabforum.org/pipermail/public/2016-April/007188.html>, making
the TBSCertificate as similar as possible to one that existed prior
to the SHA-1 sunset greatly minimizes the risk of a collision attack.
(This implies reusing a key pair, since the Subject Public Key Info
comprises the bulk of a TBSCertificate.)  However, the TBSCertificates
in this request look nothing like certificates known to exist prior
to the sunset, and the introduction of gibberish in the subject OU is
exactly what one might see if this request were exploiting a
collision.  (I'm sure there's an innocuous explanation for the
gibberish, but considering the risk to the public, any request for SHA-1
issuance must be above suspicion.)

This appears fixable.  I found the following unexpired certificates
for these FQDNs in CT:

 * ssl1.tsysacquiring.net, logged in 2015: https://crt.sh/?sha256=C741F74C12594139191F80734A57B0A4847F3CF2BD048E433EA76F858927F1C1
 * ssl1.vitalps.net, logged in 2014: https://crt.sh/?sha256=a432185e24201d7ab954870193d3f4b2d077b8fd521da76773fed0623236b27f
 * ssl2.vitalps.net, logged in July 2016, notBefore in 2014: https://crt.sh/?sha256=1b5546e8d29ec8734dca953e29da8df757122cd169ceadb364a10c3670f7d15c
 * ssl3.vitalps.net, logged in July 2016, notBefore in 2015: https://crt.sh/?sha256=49d022ab09592a9c4139e9e958438fe905e745e1a48bac72355b0108b9e4a088

Two of these certificates were logged before the sunset, and the other
two have a notBefore date prior to the sunset.  TSYS should reuse the
keys and subjects from these certificates, or from one of the other
pre-2016 certificates that can be found by searching crt.sh for these
FQDNs.  Symantec should make the TBSCertificates as similar as possible
to these pre-2016 certificates, including in the order of extensions.
Ideally, the only differences would be in validity and serial number.
It would also help to provide evidence that the keys for
ssl2.vitalps.net and ssl3.vitalps.net were generated prior to 2016.

Following these recommendations would make this request a lot less
risky, more in line with the letter and spirit of the "Existing
Certificate Information" section of the Request Procedure, and
presumably more likely to be approved by the Application Software
Suppliers. However, as the request currently stands, I think the
Application Software Suppliers should reject it.

Regards,
Andrew