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

[Magnus Ahltorp <[e-mail]>]

6 June 2017 21:28 Jacob Hoffman-Andrews <[e-mail]> wrote:

> I'll echo what Filippo said and say that fast issuance (order of minutes) is important, and anything that breaks fast issuance for new sites (or for sites moving between providers) is a problem. In the long run, getting a certificate will be part of standing up a web site just as much as getting DNS and hosting are today. Are we willing to ask the web to accept a delay of 24 hours for any new site? I think that would be a big step backwards.

Well, that depends on the assurance level, doesn't it? For domain-validated certificates, sure, but those are next to worthless anyway. It would be hard to hold a CA responsible for issuing them, so the need for logging them is really small.

> > Certificate is used immediately, only with SCT: Clients accept certificates only with SCTs for a limited duration; after that an inclusion proof must be accompanied [4].
> > [4] That requires auditing logs asynchronously, since an attacker with persistent access could keep getting new SCTs issued, or some clients may not have fresh STHs because they missed some updates.
> 
> This seems potentially promising but I think it has some flaws. Would this auditing be done by the logs themselves, or by monitors? IIUC, logs are allowed to produce infinite SCTs for the same cert once they've logged it, and they don't have to produce the list of SCTs they've signed. So the only party that could meaningfully audit for excessive SCT generation would be the log itself, which is the party we're trying to defend against.

If we are talking about "limited duration" of SCTs, we are talking about the age of the timestamp in the SCT. Each timestamp that is used to generate an SCT is required to be logged in the log. That is what the log is logging, cert+timestamp.

/Magnus