Ben Laurie <[email protected]> wrote Tue, 24 May 2016 11:25:15 +0100: > On 19 May 2016 at 15:56, 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. > > We were reviewing the spec for 6962-bis, and we believe it is not > possible to have more than one SCT for any particular log entry.
I agree. There can be more than one log entry with the same chain though, each of which at submission returned a separate SCT. But that's beside the point so to answer my own question: Yes, all SCT's for every chain, one per entry. :) >> | 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. > > I agree there's a difference. I am curious what architecture makes it > a big difference, though! Here's why adding SCT's to the database is hard in our implementation. - SCT's can not be included in the entry stored in the database Our system doesn't trust its frontend nodes. Therefore our signing nodes refuse to produce an SCT for an entry until they know that the entry has been stored at a configured quorum of storage nodes. Once an entry has been stored it doesn't change. >From this follows that the SCT can not be included in the entry. - SCT's can not easily be added to the database, like in a new table or similar We don't have a database distribution mechanism for anything else than log entries that almost always already are present at all storage nodes. Adding a new type of data is doable but will take some redesign. - One a side note, good we require deterministic signature algorithms Using an SCT as a unique key seems hard at first, until you realise that 6962-bis mandates deterministic signatures. This is fortunate if your key-value store isn't multi-value, which ours is not (because complicated if you want to write once and never change, only append). Design documents for catlfish, the database and one of the database backends below. Happy to talk more about this. - https://git.nordu.net/?p=catlfish.git;a=blob;f=doc/design.txt - https://git.nordu.net/?p=plop.git;a=blob;f=doc/db.md - https://git.nordu.net/?p=plop.git;a=blob;f=doc/permdb.md _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
