<p dir="ltr">One can also use OCSP Stapling or the TLS extension. OCSP stapling is particularly useful for also dealing with the revocation status in a single response.</p>
<div class="gmail_quote">On Feb 4, 2014 9:52 AM, "Adam Langley" <<a href="mailto:agl@chromium.org">agl@chromium.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Feb 4, 2014 at 12:33 PM, Jeremy Rowley<br>
<<a href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>> wrote:<br>
> 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.<br>

<br>
The customer doesn't carry the risk: the risk is that we'll be unable<br>
to revoke a log in clients due to the number of certificates that<br>
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>
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>
</blockquote></div>