Re: [Trans] Write-up of the "Strict CT" variant

[Ryan Sleevi <[e-mail]>]

On Wed, Jun 7, 2017 at 10:36 AM, Magnus Ahltorp <[e-mail]> wrote:
>
> But, in the same sentence, Jacob wrote: "IIUC, logs are allowed to produce
> infinite SCTs for the same cert once they've logged it", which is what I
> based my answer on. If the log disregards all rules and doesn't care about
> being discovered as a bad log, surely it wouldn't care about whether it was
> allowed to produce many SCTs for the same cert or not. Which means that
> restricting that wouldn't solve that problem.
>

I think there may be some disconnect here still, unfortunately.

For example, in your response, you note "and doesn't care about being
discovered about a bad log". The concerns raised - with respect to the
production of SCTs and the deferring of inclusion proof fetching on the
basis of that timestamp - were to highlight that it creates a scenario in
which a bad log would not be discovered using the scheme, as proposed. This
is why it was highlighted that 'someone' would have to examine the SCTs
produced - including those _before_ the 'must include inclusion proof' time
- so make sure that those SCTs were, in fact, logged. Which brings us back
to the original problem, of clients checking inclusion proofs of SCTs
asynchronously/out-of-band (and/or gossiping them), which suggests that a
solution of stapled inclusion proofs (with a 'grace period') doesn't solve
the client-checking problem, and the (original) discussion of stapled
inclusion proofs (with no grace period) is operationally unviable, because
it means a certificate cannot be deployed until the inclusion. These were
all motivating design factors in both the original and subsequent designs
of 6962 and 6962-bis, but were perhaps not articulated clearly as such.