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: [email protected] [mailto:[email protected]] On Behalf Of Jeremy Rowley Sent: Tuesday, February 04, 2014 12:00 PM To: 'Adam Langley'; [email protected] Cc: [email protected]; '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:[email protected]] On Behalf Of Adam Langley Sent: Tuesday, February 04, 2014 10:52 AM To: [email protected] Cc: [email protected]; Ben Laurie; CABFPub Subject: Re: [therightkey] [cabfpub] Updated Certificate Transparency + Extended Validation plan On Tue, Feb 4, 2014 at 12:33 PM, Jeremy Rowley <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/therightkey _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
