Re: [Trans] What logs are storing (was: The RFC6979 requirement in RFC6962-bis is bad)

The downsides with storing signatures (for SCTs and STHs), which is an
additional storage requirement for something that can be generated
on-the-fly:
* Storage costs and processing: Logs have to use highly-reliable storage,
so every piece of data stored costs more and requires more processing to be
verified.
* Potential corruptions: What would a log do if it finds out it stores a
corrupted signature? It could continue operation by re-signing without
problems, unlike a corruption of the list of entries, where it's clear it's
unhealthy (a safety measure in some log implementations is to hash all
entries up to the last-issued STH and verify root hash, before adding new
entries and producing a new one).

This is a viable solution to the problem of deterministic signatures,
though, so it should be mentioned in -bis.
How about requiring returning the same signature for the same SCT / STH,
without requiring the use of deterministic signature schemes?

On Tue, May 9, 2017 at 12:14 AM, Andrew Ayer <agwa@andrewayer.name> wrote:

> On Tue, 09 May 2017 00:54:38 +0200
> Linus Nordberg <linus@sunet.se> wrote:
>
> > Andrew Ayer <agwa@andrewayer.name> 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.
>
> > 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.
>
> Regards,
> Andrew
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>