Andrew Ayer <[email protected]> wrote Mon, 8 May 2017 16:14:43 -0700:
> On Tue, 09 May 2017 00:54:38 +0200 > Linus Nordberg <[email protected]> wrote: > >> Andrew Ayer <[email protected]> wrote >> Mon, 8 May 2017 11:11:41 -0700: >> >> > 3. When producing a new STH or SCT, sign it, store the signature, >> > and serve the stored signature instead of re-signing on-the-fly >> > every time the log needs to serve the STH or SCT. Since the log >> > already needs to store information about STHs and SCTs, also >> > storing the signature should not be burdensome. >> >> Why do logs already need to store information about SCTs? > > Technically it's not required, but practically speaking logs need to > return an SCT for an existing entry when someone submits an > already-logged certificate (otherwise the log could be spammed into > oblivion). To construct that SCT, the log needs to know the timestamp > of the existing entry. A logical place to store the signature would be > alongside the timestamp. Ah, I see the confusion. I view the SCT as the data sent as a response to an add-chain request, not the various parts it's being made of. Storing the timestamp together with the cert chain makes a lot of sense. Caching the signature as well is a different thing. (On a side note, our log implementation has recently started mandating caching of SCTs at frontend nodes in order to protect against a "dropping-entries-attack" by a rogue frontend.) >> Do logs already need to store information about STHs because of the >> proposed get-sths API [0][1][2] or something else? > > Even without the get-sths API, the log needs to store the timestamp of > the current STH. That would be a logical place to store the signature. Right. Storing information about the _current_ STH is useful, agreed. _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
