[cabfpub] [therightkey] Updated Certificate Transparency + Extended Validation plan
jeremy.rowley at digicert.com
Tue Feb 4 19:06:04 UTC 2014
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.
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.
From: therightkey [mailto:therightkey-bounces at ietf.org] On Behalf Of Adam
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>
> 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
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.
therightkey mailing list
therightkey at ietf.org
Public mailing list
Public at cabforum.org
More information about the Public