[cabfpub] [therightkey] Updated Certificate Transparency + Extended Validation plan

[Jeremy Rowley]

The entire point is to disclose the entire universe of public certificates
to the customer.  If the customer doesn't want to use it, the purpose is no
longer being fulfilled. The way we plan on implementing CT will ensure logs
are not irrevocable.  I agree we should make SCTs as small as possible, but
the last I've heard from our team is  they are still at 100 bytes per log.

Jeremy

-----Original Message-----
From: therightkey [mailto:therightkey-bounces at ietf.org] On Behalf Of Adam
Langley
Sent: Tuesday, February 04, 2014 10:52 AM
To: certificate-transparency at googlegroups.com
Cc: therightkey at ietf.org; Ben Laurie; CABFPub
Subject: Re: [therightkey] [cabfpub] Updated Certificate Transparency +
Extended Validation plan

On Tue, Feb 4, 2014 at 12:33 PM, Jeremy Rowley <jeremy.rowley at digicert.com>
wrote:
> Three or four proofs for a 27 month certificate is way too many.  The
number of proofs should be decided based on the customer's risk profile, not
a set number based on certificate lifecycle. Adding 400 bytes per
certificate will make EV certificates unusable by entities concerned with
performance.

The customer doesn't carry the risk: the risk is that we'll be unable to
revoke a log in clients due to the number of certificates that depend on it.

We should make the SCTs as small as possible, the the switch to larger
initcwnds in recent years has released much of the pressure on keeping
certificate sizes below the tradition initcwnd limit.


Cheers

AGL
_______________________________________________
therightkey mailing list
therightkey at ietf.org
https://www.ietf.org/mailman/listinfo/therightkey