Hi, I like that -- if you're not gossiping SCT plus full chain, gossip SCT plus the input needed for producing the real unique key of the log, i.e. the merkle tree leaf. Making it mandatory should not complicate the gossip protocol much, but I'll investigate.
Regarding your first point for why an SCT alone is not useful, I'm not sure that I understand how a log could drop such a reqeust. If a log doesn't reply to a request it's supposed to support it's misbehaving, isn't it? And SCT's are certainly signed so the log can indeed be held accountable. I agree that implementing a "best effort" get-entry-by-sct request is trivial -- try verifying the SCT against all entries until you find the match, return the match. Using the timestamp as a hint of where to start looking is probably a good optimisation. It might even be efficient. Eran Messeri <[email protected]> wrote Thu, 19 May 2016 18:07:01 +0100: > Back to dkg's original question, I'd suggest gossiping the MerkleTreeLeaf > (RFC6962) / TransItem containing TimestampedCertificateEntryDataV2 > (RFC6962-bis). > > For each of the protocols, that's the data structure necessary to validate > the signature in the SCT *and* to audit the log (because these data > structures themselves are not signed they cannot be the only thing that's > gossiped). > > IMHO gossiping only the SCT is not very useful, even if logs offer > get-entry-by-sct: > * A log could deny / drop such a request (as it's not signed), in which > case the client's recourse is a download of the entire log. > * Without the data covered by the signature, there's no meaningful > auditing: the entity holding the SCT does not know which certificate hasn't > been incorporated into the log. > > Re get-entry-by-sct, as it does complicate implementation, one option is to > make this API optional (which is a particularly viable approach as it can > be implemented by a log mirror based on data from a log that does not > implement it). > > Eran > > > On Thu, May 19, 2016 at 3:56 PM, Linus Nordberg <[email protected]> wrote: > >> Ben Laurie <[email protected]> wrote >> Wed, 18 May 2016 18:30:37 +0100: >> >> | On 18 May 2016 at 17:23, Linus Nordberg <[email protected]> wrote: >> | > Ben Laurie <[email protected]> wrote >> | > Fri, 13 May 2016 15:56:44 +0100: >> | > >> | > | Actually, it seems to me that the simplest answer is to allow lookups >> | > | in logs based on SCT alone. Then the SCT can be validated using the >> | > | retrieved chain. >> | > >> | > That seems odd. From a logs point of view, an SCT is not a persistent >> | > object. >> | > >> | > I don't know about other implementations but catlfish would not be able >> | > to efficiently find an entry in the database given only an SCT. >> | >> | Are you saying there's some technical barrier to doing this, or just >> | that as it stands you wouldn't be able to? >> >> I was being inprecise. I should have said that it would require some >> redesign. >> >> >> | It seems to me that the log could easily save SCTs it issued alongside >> | the cert chains it issued them for. >> >> All SCT's for every chain, I presume, if there's going to be any point >> in offering a lookup with an SCT as input? This would complicate things >> at least in our design. I'm sure it could be solved at the price of more >> complexity. >> >> >> | And that it could easily create an index based on those SCTs. >> >> >> | Note that 6962-bis already requires you to return SCTs in some lookups... >> >> You meen get-entries? I don't see how that's relevant. An SCT can be >> generated given the data in leaf_input. No need to store it, unless you >> wanted to for caching of course (we do that on frontend nodes). There's >> a big difference between doing this and indexing on SCT's though. >> >> _______________________________________________ >> Trans mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/trans> > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
