Eran Messeri <[email protected]> wrote Fri, 6 May 2016 12:26:35 +0100:
| > >> But in other cases (e.g. auditing, gossiping), there's no | > >> guarantee that the issuer cert (or issuer public key) is going to be | > >> passed alongside the SCT. | > >> | > >> Do we want to require people to pass the issuer cert (or issuer public | > >> key?) alongside the cert in order to be able to verify the signature on | > >> an SCT? If so, where is the best place to document that concern? | > > | > > That seems like a good idea. Presumably we'd need to add a new | > > TransItem type to carry this information. | > | > Is there a transaction in CT itself where you expect that to happen? | > Can you propose a change to the draft that would make that clear? | > | > Is the clumsiness of needing the issuer key in addition to the cert and | > SCT in order to validate the SCT worth the 32 octets in size it shaves | > off? | > | The reason (I recall) for requiring the issuer key hash and TBSCertificate | was to unify handling of precerts and X.509 certs, such that the SCT | signature is over the same data structure for both cases. | The concern you raise is very valid - the issuer cert would always have to | accompany the leaf cert for clients/auditors to be able to verify the SCT's | signature (note that get-entries returns, in addition to the log entry and | the chain, the SCT issued). | I agree we should make sure the protocol takes it into account - just not | sure what type of clients will have a problem (TLS clients should get a | full chain, auditors get everything from the log). The current incarnation of the CT gossip draft defines two modes of operations for HTTPS servers when taking part in SCT Feedback (draft-ietf-trans-gossip-02 section 8.1.3). In "simple mode" the HTTPS server doesn't have a set of trusted roots and won't deal with anything in the cert chain except the end-entity cert. The argument for this is that it requires less configuration which should increase the likelyhood of adoption. An argument against this, beside the issue brought up by dkg in this thread, is that "simple mode" won't protect against the double-CA-compromise attack. _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
