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
