<div dir="ltr"><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 4, 2014 at 11:00 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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></blockquote><div><br></div><div>Moving <a href="mailto:therightkey@ietf.org">therightkey@ietf.org</a> to bcc to avoid cross-posting.</div><div><br></div><div>I wanted to correct a misunderstanding that I've seen repeated several times within the CA/Browser Forum, and which I've tried to correct repeatedly.</div>
<div><br></div><div>No, the entire point is NOT to disclose the entire universe of public certificates to the customer. The entire point is to disclose the entire universe of public certificates __to the public__.</div><div>
<br></div><div>That is, if no *customer* ever uses CT to monitor logs (an improbable and extremely unlike situation, as demonstrated by the IETF WG chartering), we will STILL see CT as a benefit to the public and as a success.</div>
<div><br></div><div>This is because CT provides capabilities to allow ALL relying parties to audit public CAs. This capability extends to allowing root store operators to audit compliance to their programs. This capability extends to those who ingest root programs to examine the authorities trusted by these root programs. This allows independent third parties to monitor compliance to stated policies and practices.</div>
<div><br></div><div>The current practice sees a random audit at a point in time conducted by an auditor (ETSI or WebTrust), often with a quite small percentage (3%, at most, IIRC), with the results of those audits not disclosed to any entity beyond the CA. Even if every browser program required full disclosure to the browser, this would fail to meet the goals.</div>
<div><br></div><div>I want to make sure it's clear the _why_ we're requiring CT, and where the value is derived from, as suggesting the *entire* point is just for the customer misses out the significant improvements to the ecosystem.</div>
<div><br></div><div>It's already clear that root store operators care about these things - as seen by Google's indexing or Microsoft's SmartScreen reporting ( <a href="http://realworldcrypto.files.wordpress.com/2013/06/shumow.pdf">http://realworldcrypto.files.wordpress.com/2013/06/shumow.pdf</a> ). These are NOT sufficient technologies, as has been previously suggested, but they do demonstrate the increasing concern of root stores - and the interested parties such as EFF and the Certificate Observatory.</div>
<div><br></div><div>CT addresses many of these holes, but only when it's required. We're happy to add CT to the list of requirements that CAs that wish to participate in our root stores and EV programs because of this, and we hope that other root store operators will follow.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><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>
</div><div><div class="h5">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>
</div></div>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>
<div class=""><div class="h5"><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>