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

[Jeremy Rowley]

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 at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Jeremy Rowley
Sent: Tuesday, February 04, 2014 12:00 PM
To: 'Adam Langley'; certificate-transparency at googlegroups.com
Cc: therightkey at 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 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

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