Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct

[Rob Stradling <[e-mail]>]

On 24/07/15 12:09, Ben Laurie wrote:
<snip>
>     But say we enhance CT so clients can demand STHs *with* cert
>     inclusion proofs from the web servers they talk to - as I suggested
>     in the meeting today, and which I believe Ben Laurie mentioned is
>     already in the works.  Then any Web client that does this will be
>     proactively protected from MITM attacks involving faked, forked, or
>     otherwise bad log entries.  And the client doesn’t have to
>     compromise its privacy by gossiping with anyone.
<snip>
> 2. Our original design for CT did indeed have certs served along with an
> STH and an inclusion proof. Unfortunately, CAs categorically rejected
> this approach because of the latency it introduced in the certificate
> issuance process. Personally, I think it would be a better approach. Now
> CAs are more accepting of CT, perhaps it would be worth revisiting the
> question with them?

I think we need to make this approach available as an option.  We should 
retain the lower-latency option (i.e. SCTs) too though.

TRAC ticket 10 already aims to do this.

DV certs are typically validated and issued quickly.  For EV certs and 
name-constrained Sub-CA certs, the process can take days/weeks/months, 
so added latency in issuance may be less of a concern.

When OCSP Stapling and/or the CT TLS extension are used to convey "CT 
objects" to TLS clients, the TLS server could send SCTs for the first 
few hours, then switch to sending inclusion proofs / STHs once the log 
has generated them.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online