On Fri, Jan 25, 2013 at 10:02 AM, Emilia Kasper <ekas...@google.com> wrote: > > On Thu, Jan 24, 2013 at 10:18 PM, Trevor Perrin <tr...@trevp.net> wrote: >> >> Maybe there should be some other X.509v3 critical extension, allowing >> the TBSCertificate to contain a reference to the issuer's public key? >> That might be easier than modifying revocation systems? > > What we could do, I think, is stick the TBSCertificate issuer's public key > under the SCT signature. Keep in mind the goal, for us, is to bind the > TBSCertificate that appears in the log to the certificate the TLS client > sees.
I'd put it a bit differently: an end-entity cert or TBSCert is not a fully self-contained object, it depends on some context from its cert chain. So in addition to binding the end-entity cert or TBScert into the SCT and MerkleTreeLeaf, you may need to bind some of this context, to ensure that log monitors and TLS clients are seeing the same things. Issuer public keys are an important piece of context, because in some revocation protocols, like OCSP, they determine who can revoke the cert. So I think the TBSCert vs. full cert distinction is a bit of a red herring. Even if you bind a full cert, I think you still want to bind its issuer public key. Otherwise you're relying on the cert's signature to bind the issuer public key, which seems like an unusual, possibly unsafe use of crypto (though correct me if I'm wrong!) Anyways, is there other context from the cert chain that needs binding? What about: - Issuer keys or names from other certs in the chain? - The end-entity cert's signatureAlgorithm? - Name constraints? - Certificate policies? - Anything else? Trevor _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
