1418148 - Comodo: USERTrust, USERTrust ECC Certification Authority, Certificate signature algorithm does not match TBS signature algorithm

Status: RESOLVED WONTFIX

(CA Program :: CA Certificate Compliance, task)

Description

[chris]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171112125346

Steps to reproduce:

The following non-compliant certificate was discovered during an audit of the CCADB.

https://crt.sh/?id=12722435&opt=cablint

Comment 1

[Gervase Markham [:gerv]]

Rob and Robin: also yours, I believe.

Gerv

Comment 2

[Ryan Sleevi]

Gerv: I suggest considering this whole swath of bugs as WONTFIX. As the Signature algorithm encoding necesssarily is not covered by the Signature itself, anyone can mutate it without invalidating the Signature. As such, mismatches cannot categorically he attributed to the CA.

Comment 3

[Rob Stradling]

Ryan is correct that Certificate.signatureAlgorithm is not covered by the Signature itself.  However, TBSCertificate.signature _is_ covered by the Signature, and it's a mismatch between that field and the actual Signature that Chris has correctly identified.

WHAT WENT WRONG?
We constructed the TBSCertificate for this cross-certificate (https://crt.sh/?id=12722435) on April 15th 2013.  We made the mistake of setting TBSCertificate.signature to ecdsa-with-SHA384, whereas it should have been set to sha1WithRSAEncryption.  We signed the TBSCertificate (using sha1WithRSAEncryption) on the same day.

WHY WASN'T THIS MISTAKE SPOTTED IMMEDIATELY?
To defend against making this sort of mistake, our procedure is to first sign the TBSCertificate with a dummy private key, and then to manually review the resulting "test profile" using the "openssl x509" command-line tool.  Only after confirming that all of the fields look correct do we proceed to signing the TBSCertificate with the real issuing CA's private key.

Unfortunately, there was a bug in OpenSSL at that time.  "openssl x509" displayed "sha1WithRSAEncryption" for both the Certificate.signatureAlgorithm field and the TBSCertificate.signature field, which hid the mistake from the eyes that performed the manual review.

WHEN WAS THIS MISTAKE SPOTTED?
During the week that followed, we noticed the mistake, and so we reissued the cross-certificate (https://crt.sh/?id=12716435) on April 22nd 2013.  We assumed human error during the April 15th 2013 manual review rather than pointing the finger at OpenSSL.

FIXING OPENSSL
Some time later I eventually spotted that there was a bug in OpenSSL.  I contributed a fix, which was committed on January 22nd 2015 and just made it into OpenSSL 1.0.2 (by a matter of hours!):
https://git.openssl.org/?p=openssl.git;a=commit;h=004efdbb41f731d36bf12d251909aaa08704a756

REVOCATION?
We have observed that some clients don't complain about signature algorithm mismatches of this sort.  We have also observed that some CAs have run into problems when revoking one of several peer cross-certificates.  Therefore, we do not plan to revoke https://crt.sh/?id=12722435.

OTHER INFORMATION
The incorrect cross-certificate (https://crt.sh/?id=12722435) did not leave the lab until the CCADB disclosure requirement came into force.

Comment 4

[Gervase Markham [:gerv]]

That seems like a pretty clear and reasonable explanation, and the patch is classic :-)

Gerv