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

[Jacob Hoffman-Andrews <[e-mail]>]

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.

On 05/23/2017 05:42 AM, Eran Messeri wrote:
> Options for dealing with the delayed usability of certificates:
>
>   * Opt-in: servers requires presence of proofs via header / X.509
>     extension [6].
>
This seems like the most plausible option, with the same caveats as HSTS
about first visit. However, if Strict CT is only applied for a small
number of sites that opt in, is it worth the extra ecosystem complexity?
It seems like Strict CT on an opt-in basis would not be a meaningful
substitute for gossip.

> 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.