<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 4, 2014 at 11:06 AM, Jeremy Rowley <span dir="ltr"><<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also, I'm not sure how basing the number of logs based on the lifecycle<br>
actually minimizes the impact of log revocation. If a log containing a<br>
couple thousand 1-year certificates is compromised, the damage from<br>
revocation is about the same as a log containing thousands of 3-year certs.<br>
Unless you plan is to revoke the log and wait for all impacted certificates<br>
to actually expire (giving a 12 month risk), the impact depends on the<br>
number of certificates valid at the time of revocation, not the expiration<br>
date of the certificate.<br>
<div class="im HOEnZb"><br></div></blockquote><div><br></div><div>The "impact" is only present if a single SCT is acceptable.</div><div><br></div><div>Increasing the number of SCTs decreases the impact of log revocation, as the probability that any given certificate will be directly affected by a single revocation (which is far, far less common one would hope) decreases relative to the number of distinct logs it is logged in.</div>
<div><br></div><div>Further, a 1 year certificate that is renewed every year has a greater chance to respond to any revocation events than a 3 year certificate, which will not be re-issued for 3 years, and thus is unable to respond to any revocation events (as unlikely as they may be) that happen in the interim.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im HOEnZb">
-----Original Message-----<br>
From: <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>] On<br>
</div><div class="HOEnZb"><div class="h5">Behalf Of Jeremy Rowley<br>
Sent: Tuesday, February 04, 2014 12:00 PM<br>
To: 'Adam Langley'; <a href="mailto:certificate-transparency@googlegroups.com">certificate-transparency@googlegroups.com</a><br>
Cc: <a href="mailto:therightkey@ietf.org">therightkey@ietf.org</a>; 'CABFPub'<br>
Subject: Re: [cabfpub] [therightkey] Updated Certificate Transparency +<br>
Extended Validation plan<br>
<br>
The entire point is to disclose the entire universe of public certificates<br>
to the customer.  If the customer doesn't want to use it, the purpose is no<br>
longer being fulfilled. The way we plan on implementing CT will ensure logs<br>
are not irrevocable.  I agree we should make SCTs as small as possible, but<br>
the last I've heard from our team is  they are still at 100 bytes per log.<br>
<br>
Jeremy<br>
<br>
-----Original Message-----<br>
From: therightkey [mailto:<a href="mailto:therightkey-bounces@ietf.org">therightkey-bounces@ietf.org</a>] On Behalf Of Adam<br>
Langley<br>
Sent: Tuesday, February 04, 2014 10:52 AM<br>
To: <a href="mailto:certificate-transparency@googlegroups.com">certificate-transparency@googlegroups.com</a><br>
Cc: <a href="mailto:therightkey@ietf.org">therightkey@ietf.org</a>; Ben Laurie; CABFPub<br>
Subject: Re: [therightkey] [cabfpub] Updated Certificate Transparency +<br>
Extended Validation plan<br>
<br>
On Tue, Feb 4, 2014 at 12:33 PM, Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>><br>
wrote:<br>
> Three or four proofs for a 27 month certificate is way too many.  The<br>
number of proofs should be decided based on the customer's risk profile, not<br>
a set number based on certificate lifecycle. Adding 400 bytes per<br>
certificate will make EV certificates unusable by entities concerned with<br>
performance.<br>
<br>
The customer doesn't carry the risk: the risk is that we'll be unable to<br>
revoke a log in clients due to the number of certificates that depend on it.<br>
<br>
We should make the SCTs as small as possible, the the switch to larger<br>
initcwnds in recent years has released much of the pressure on keeping<br>
certificate sizes below the tradition initcwnd limit.<br>
<br>
<br>
Cheers<br>
<br>
AGL<br>
_______________________________________________<br>
therightkey mailing list<br>
<a href="mailto:therightkey@ietf.org">therightkey@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/therightkey" target="_blank">https://www.ietf.org/mailman/listinfo/therightkey</a><br>
<br>
_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
<br>
_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
</div></div></blockquote></div><br></div></div>