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.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
