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

Also, I'm not sure how basing the number of logs based on the lifecycle
actually minimizes the impact of log revocation. If a log containing a
couple thousand 1-year certificates is compromised, the damage from
revocation is about the same as a log containing thousands of 3-year certs.
Unless you plan is to revoke the log and wait for all impacted certificates
to actually expire (giving a 12 month risk), the impact depends on the
number of certificates valid at the time of revocation, not the expiration
date of the certificate.

-----Original Message-----
From: public-bounces@cabforum.org [mailto:public-bounces@cabforum.org] On
Behalf Of Jeremy Rowley
Sent: Tuesday, February 04, 2014 12:00 PM
To: 'Adam Langley'; certificate-transparency@googlegroups.com
Cc: therightkey@ietf.org; 'CABFPub'
Subject: Re: [cabfpub] [therightkey] Updated Certificate Transparency +
Extended Validation plan

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@ietf.org] On Behalf Of Adam
Langley
Sent: Tuesday, February 04, 2014 10:52 AM
To: certificate-transparency@googlegroups.com
Cc: therightkey@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@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@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

_______________________________________________
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public