Re: [Trans] Mutability of Certificate Signatures

[Eran Messeri <[e-mail]>]

On Tue, Jun 6, 2017 at 6:00 PM, Andrew Ayer <[e-mail]> wrote:

> 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.
>
Correct.

>
> 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.
>
Correct.

>
> 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.
>
Correct.

>
> 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.
>
Yes, the chain must be valid, so the first item in the chain (after the
logged leaf) should be the issuer certificate.

>
> 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.
>
Correct - but then the monitor should be able to verify it was a trust
anchor at the point it was logged (maybe the output of get-trust-anchors
should  be signed?).

>
> 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.
>
Could you elaborate? Is that a security problem from a CT perspective - as
in, could enable a log to avoid responsibility for something it logged, or
from a WebPKI perspective, where some certificates can be in circulation
but their issuer unknown?
I'm trying to better understand under which circumstances such certificates
would end up in the log - when would a log add a non-self-signed
certificate as a trust anchor?

>
> 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
>