[Trans] Mutability of Certificate Signatures

[Andrew Ayer <[e-mail]>]

In RFC6962-bis, the input to the Merkle Tree leaf hash
includes the TBSCertificate and the hash of the issuer key.
The certificate signature is not included in the leaf hash.
Consequentially, it is possible for a log to alter or remove
the signature without violating the append-only property of the log.
The tree's root hash would remain the same, and the log could still
produce valid inclusion proofs for the corresponding SCT.

This enables the following attack: if a misissued certificate is
included in a log, an attacker could compromise or collude with the log
operator to alter or remove the certificate's signature. Then the log
no longer contains cryptographic proof that the CA misissued the
certificate.  The CA indicated by issuer_key_hash could plausibly claim
that it didn't issue the certificate.  Meanwhile, the log operator
could claim the invalid signature came from a submitter, and blame its
presence on a bug in the log's certificate acceptance code, something
which has already happened with two RFC6962 logs and was not considered
sufficiently bad by Chrome to warrant distrust[1].

Note that this problem also exists in RFC6962 with pre-certificates,
but not with certificates as the Merkle Tree leaf hash includes the full
certificate.

This could be fixed without changing the protocol by adding language
that says that if a log cannot produce a full (pre-)certificate with a
valid signature that matches the TBSCertificate and issuer_key_hash in
the Merkle Tree leaf, then it must be considered misbehavior equivalent
to violating the append-only property.

However, it seems unfortunate that we can't simply rely on the Merkle
Tree to ensure the immutability of crucial data - that is the whole
point of a Merkle Tree, after all.  Auditors would need to perform
an additional, complicated step.  Furthermore, if a log has a
legitimate bug that causes certificates with invalid signatures to be
accepted by accident, the log would have to be distrusted.

Unfortunately, we can't simply include a whole pre-certificate in
the Merkle Tree leaf hash, as it is impossible to reconstruct from
the final certificate.  (We could put the pre-certificate signature in
an extension in the final certificate, but that seems undesirable.)

Any thoughts?  Since this is a correctness issue, I think it needs a
resolution before RFC6962-bis is finalized.

Regards,
Andrew

[1] https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/Itoq0YUZTlA