On Tue, 6 Jun 2017 18:27:51 +0100 Eran Messeri <[email protected]> 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 _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
