Re: [Trans] Mutability of Certificate Signatures

[Andrew Ayer <[e-mail]>]

On Tue, 6 Jun 2017 18:27:51 +0100
Eran Messeri <[e-mail]> wrote:

> [...]
>
> >
> > 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?).

Could you elaborate?  How does the monitor being able to verify it was
a trust anchor at time of logging help?  Regardless, the monitor is
unable to perform checks 2 and 3 if it can't get the issuer public key,
and so the attack which started this email thread can still be performed.

> >
> > 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 mean from the CT perspective: that is, the log can still perform
the attack we're trying to prevent.

> 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 don't know, but I have seen such certificates added as "roots" in
existing RFC6962 logs.  It's also interesting that RFC6962-bis changed
the language from "root" to "trust anchor" which suggests this
practice was intended to be explicitly supported.  What was the motivation
behind this language change?  It would certainly fix the problem if
trust anchors were required to be roots - that is, self-signed.

Regards,
Andrew