On Wed, Jun 7, 2017 at 10:36 AM, Magnus Ahltorp <[email protected]> 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.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
