<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=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1859081804;
mso-list-type:hybrid;
mso-list-template-ids:-375459776 1962688768 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Calibri","sans-serif";
mso-fareast-font-family:Calibri;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Brad,<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I would say a DV cert is superior to DANE w/o PKIX because:<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The DV cert will conform to Baseline Requirements (minimum key size, strong signing and hashing algorithm, acceptable validity period, proper extensions)<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The DV cert would be very likely to have undergone automated checks for weak keys, weak exponents, not on Debian weak key list, not on internal phish lists, etc.)<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>-<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The DV cert would contain AIA and/or CDP extensions, so if the CA detects that the site is fraudulent, it can revoke the cert.<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I feel strongly that a site (either real or fake) with a self-signed certificate with a 30-year validity, containing a 1024-bit Debian weak key, no basicConstraints or CA=true should not be given the same “trusted cert” status indicators as a DV cert.<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-Rick<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 style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Hill, Brad [mailto:bhill@paypal-inc.com] <br><b>Sent:</b> Friday, October 12, 2012 3:23 PM<br><b>To:</b> Rick Andrews; Ryan Sleevi<br><b>Cc:</b> public@cabforum.org<br><b>Subject:</b> RE: [cabfpub] Revised document for Ballot 89 - Adopt Requirements for the Processing of EV SSL Certificates v.2<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Rick,<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Can you provide any examples of ways in which DANE absent PKIX provides an inferior chain of trust to Domain Validated certificates? Both prove administrative control of a name through means ultimately rooted in the registrar as a trust root. (validating “what”, not “who” you are talking to)<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> I don’t think the CABF has any grounds to discourage such DANE options unless it discourages DV similarly or justifies why DV should be treated any differently.<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-Brad Hill<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 style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> public-bounces@cabforum.org [mailto:public-bounces@cabforum.org] <b>On Behalf Of </b>Rick Andrews<br><b>Sent:</b> Friday, October 12, 2012 2:57 PM<br><b>To:</b> Ryan Sleevi<br><b>Cc:</b> public@cabforum.org<br><b>Subject:</b> Re: [cabfpub] Revised document for Ballot 89 - Adopt Requirements for the Processing of EV SSL Certificates v.2<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Ryan,<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks for your speedy review. You raise a good point about DANE, one which the entire Forum may want to debate. IMO, we (at least the CAs) should be united in discouraging the use of DANE options that disable PKIX chain validation. If browsers add DANE support for option 3 (no PKIX chain validation), then a phisher could set up a fake site with a self-signed cert, and users visiting it would receive no warning whatsoever. I believe there’s value if having a CA vet the certificate holder, so the user can’t be directed to bunkofamerica.com and get fooled into thinking it’s their bank.<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Having said that, though, I suspect DANE will involve much debate and I’d rather not wait to resolve that. If others agree with you, I’ll roll back the language to make it less contentious.<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>What are Google’s plans for DANE support in Chrome? I suppose it will be dependent on platform support, since Chrome relies on the OS for crypto and PKI.<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-Rick<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 style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Ryan Sleevi [<a href="mailto:sleevi@google.com">mailto:sleevi@google.com</a>] <br><b>Sent:</b> Thursday, October 11, 2012 6:23 PM<br><b>To:</b> Rick Andrews<br><b>Cc:</b> <a href="mailto:public@cabforum.org">public@cabforum.org</a><br><b>Subject:</b> Re: [cabfpub] Revised document for Ballot 89 - Adopt Requirements for the Processing of EV SSL Certificates v.2<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>On Thu, Oct 11, 2012 at 5:31 PM, Rick Andrews <<a href="mailto:Rick_Andrews@symantec.com" target="_blank">Rick_Andrews@symantec.com</a>> wrote:<o:p></o:p></p><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><p class=MsoNormal><span style='font-family:"Calibri","sans-serif"'>Colleagues,<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Calibri","sans-serif"'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Calibri","sans-serif"'>I’ve updated the document again to include feedback from Kathleen. I changed the title back to Guidelines as opposed to Requirements, and changed a lot of musts to shoulds.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Calibri","sans-serif"'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Calibri","sans-serif"'>Please look it over again, especially browser members. If we have consensus on this version, I’ll advance it towards a ballot. Thanks,<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Calibri","sans-serif"'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Calibri","sans-serif"'>-Rick <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Calibri","sans-serif"'> <o:p></o:p></span></p></div></div><p class=MsoNormal style='margin-bottom:12.0pt'><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></blockquote></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Rick,<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Thanks for taking the time to incorporate the feedback raised by the browser members. I think this is a very positive step forward in the document.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I don't have strong feelings on the matter, and certainly haven't implemented anything to the effect, but I wonder what the proposed changes to Section 9 mean for systems that implement DANE Type 3 validation (that is, where DNSSEC is used to obtain the public key, independent of CA trust anchors). Under such scenarios, it seems like there would be some middle ground in the UI between a full EV indication, and the proposed change which is "no secure indicator".<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I certainly agree that if RFC 5280 / EV Treatment hasn't been followed, there should be no EV branding, but I'm not sure whether it's necessary to fully strip any security indicator - particularly if using any application-defined or non-RFC5280 validation logic (again, eg: DANE). I see three levels of validation here (with three possible UI brands) - EV, DV, DANE - and the current text seems to suggest that only EV/DV should be used.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The original text (sans proposed addition) handled the above scenario fine, but I'm curious for your thoughts as to what you think the expected behaviour should be for such situations. I'll note this same concern also applies to the proposed "and should not be treated as trusted certificates" for section 13.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>For section 13 "but should try the GET method first" - perhaps "should prefer the GET method". This is by no means a sticking point, but it just seems to conflict with the "may use either" implies they could only use POST. "should prefer" provides directions both for implementation and prioritization of the attempt.<o:p></o:p></p></div></div></div></div></div></body></html>