Re: [Trans] Mutability of Certificate Signatures

[Andrew Ayer <[e-mail]>]

On Mon, 5 Jun 2017 22:42:08 +0300
Eran Messeri <[e-mail]> wrote:

> I think that the suggestion to fix this by defining as misbehaviour
> the presentation of an incorrectly-signed certificate chain in
> get-entries is the right one.
> Reasoning:
> - An SCT is useless to an attacker without a valid signature over the
> certificate/precertificate: The collusion described above is only
> harmful if a CA an a log are compromised, and even then, all it
> enables is for the CA to wash its hands of a particular certificate
> (which wouldn't be accepted by TLS clients without a valid signature).
> - It is pretty straightforward for a monitor to validate that all
> chains presented in get-entries are valid chains.
> - If we can't solve it properly for precertificates, then having
> different security guarantees for different kinds of entries  would
> be confusing, at best.
> 
> The upside of the change to only use the TBSCertificate + Issuer key
> hash in the log entry is that it's much easier to reconstruct the
> input for SCT signature validation: The same code is used for certs
> and precertificates.

You raise a good point: since there are far more TLS clients than
monitors, it makes more sense to fix this problem by adding complexity
to monitors than to TLS clients.  So I agree that defining this as
misbehavior and having monitors check is the right solution.

Let's make sure we agree what monitors need to check for certificates
(mutatis mutandis for precertificates):

1. The tbs_certificate in the x509_entry_v2 TransItem structure returned
by get-entries must be byte-for-byte identical to the TBSCertificate
portion of the leaf_certificate in the corresponding X509ChainEntry
structure returned by get-entries.

2. The issuer_key_hash in the x509_entry_v2 TransItem structure returned
by get-entries must correspond to the public key of the issuer of the
leaf_certificate in the corresponding X509ChainEntry structure returned
by get-entries.

3. The signature of the leaf_certificate in the X509ChainEntry
structure returned by get-entries must be a valid signature from the
key of its issuer.

How should a monitor get the issuer public key to perform checks 2 and
3? The obvious way is to look at the first item in the X509ChainEntry's
certificate_chain if the certificate is not self-signed, and at the
certificate itself if it is self-signed.

Unfortunately, if the logged certificate is a non-self-signed trust
anchor accepted by the log, then certificate_chain is empty and there
is no way to get the issuer public key.  So a log could evade
responsibility by making the certificate with a mutated signature a
trust anchor.

The inability to always get the issuer public key has been an
inconvenience for me when monitoring RFC6962 logs. Sometimes I end up
with a certificate and all I know about its issuer is its subject, when
ideally I would like to know its public key as well (since a CA is
uniquely identified by its subject and public key).  (I suspect crt.sh
has the same problem, based on some weird things I've observed there.)
I previously considered this a mere inconvenience, but now I see it as a
security problem.

I think that the TimestampedCertificateEntryDataV2 structure should
contain the full public key of the issuer instead of just its hash.
That way, monitors are guaranteed access to the issuer public key, and
it's easy to get.  Step 2 above could be eliminated, and step 3 becomes
simpler (no need to parse the issuer certificate to extract the public
key).

Thoughts?

Regards,
Andrew