<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><div><div><div><div><p class=MsoNormal><span style='color:#1F497D'>Comments in line:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p></div><div><p class=MsoNormal>Moving <a href="mailto:therightkey@ietf.org">therightkey@ietf.org</a> to bcc to avoid cross-posting.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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__.<o:p></o:p></p></div><div><p class=MsoNormal><span style='color:#1F497D'>[JR] This is part of the point since it’s one of the primary reasons we’ve supported CT since the beginning.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><span style='color:#1F497D'>[JR] I will see it as a benefit, but a lesser benefit than the monitoring advantage.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><span style='color:#1F497D'>[JR] If this were true, Google would be applying CT to all certificate types (or at least DV certificates). EV certificates have not traditionally been mis-issued. Thus, the public gains nothing from added EV monitoring capabilities.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><span style='color:#1F497D'>[JR] Nitpick - The requirements are higher than this for EV. We are excited about this aspect, but the primary benefit we recognize is the advantage it gives domain owners in detected fraudulent issuance. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><span style='color:#1F497D'>[JR] True. I should not have said “entire” since that was clearly inaccurate. I agree there are many additional (and significant) secondary benefits.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><span style='color:#1F497D'>[JR] I recognize that, but, from a CA perspective, the main advantage is to our customers. By making the system unusable to our customers (by requiring CT only for EV and requiring 3-4 proofs), you’ve undermined the primary reason behind CA support.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><span style='color:#1F497D'>[JR] Yep – this is why we support a global requirement for CT. For EV with 3-4 proofs per certificate, the appeal to customers diminishes.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Jeremy</span> <o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><p class=MsoNormal style='margin-bottom:12.0pt'><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<o:p></o:p></p></div><div><div><p class=MsoNormal>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>_______________________________________________<o:p></o:p></p></div></div><p class=MsoNormal>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><o:p></o:p></p><div><div><p class=MsoNormal><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><o:p></o:p></p></div></div></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></body></html>