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-boun...@cabforum.org [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley Sent: Tuesday, February 04, 2014 12:00 PM To: 'Adam Langley'; certificate-transpare...@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-boun...@ietf.org] On Behalf Of Adam Langley Sent: Tuesday, February 04, 2014 10:52 AM To: certificate-transpare...@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.row...@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 pub...@cabforum.org https://cabforum.org/mailman/listinfo/public _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
