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