<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;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi 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'>I like proposal 1 best. However, I think the path should include the CA’s name (/name-of-CA/Certificate-request or /certificate-request/name-of-CA) to identify which CA performed the validation. <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,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Jeremy<o:p></o:p></span></p><p class=MsoNormal><a name="_MailEndCompose"><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></a></p><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>Ryan Sleevi<br><b>Sent:</b> Thursday, May 29, 2014 7:09 PM<br><b>To:</b> CABFPub<br><b>Subject:</b> [cabfpub] For discussion: Restricting the use of file-based demonstrations of control<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>As discussed on our call today, we'd like to float for discussion modifications to Section 11.1.1. Several CAs indicated a need to take it back to their organizations, so this is to serve as a discussion point for what might make acceptable controls.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The goal is to ensure that 11.1.1 (6) has a reliable behaviour, so that domain operators can control and restrict the misuse of file-based ownership proofs. This is conceptually similar to the restrictions imposed upon email-based proofs, discussed in 11.1.1 (4)<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Proposal 1: Remove 11.1.1 (6)<o:p></o:p></p></div><div><p class=MsoNormal>Alternate: Provide a single, explicit path and set of steps that must be done, so that there is consistency between the CAs that employ this method. One path that might suffice would be one based upon RFC 5785.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>For example, /.well-known/certificate-request . Within that file, we could either establish a structure (seems complex), or simply require that the applicant place a random string that is generated by the CA (eg: it is not influenced by the applicant, such as a value of their choosing, hash of their CSR, etc).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Proposal 2: Forbid the use of 11.1.1 (6) and 11.1.1 (7) from being used in conjunction with 11.1.3 (Wildcard Domain Validation). <o:p></o:p></p></div><div><p class=MsoNormal>Alternate: When using data validated 11.1.1 (6), there would be additional restrictions. One such restriction discussed was requiring CAA be checked and, if present, respected (do not issue). The purpose of this is to allow concerned site operators to restrict the scope of file-based usage (for example, if they cannot filter /.well-known/ URIs) to those that they have an established business relationship or authority structure (eg: as established through Paragraph 3 of 11.2.3).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>When using data validated by 11.1.1 (7), if the 'equivalent' method did not use information obtained through DNS (eg: methods equivalent to (1) - (5) ), then the same restriction would apply as in (6). Alternatively, (7) could just REQUIRE CAA be checked and, if present, not issued.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Proposal 3: If Proposal 2 doesn't pass, or the alternate is used, further clarify that 11.1.3 (Wildcard Certificates) may only be issued at one namespace level below the validated domain namespace. That is, if 11.1.1 (6) or (7) are employed, then the FQDN represents the validated namespace. This is to prevent an applicant from demonstrating control over <a href="http://www.example.com">www.example.com</a>, and being issued a certificate for *.<a href="http://example.com">example.com</a>. Unlike methods (1) - (5), the applicant has NOT demonstrated control over the domain namespace (only a single server), and thus should not be issued a certificate.<o:p></o:p></p></div></div></div></body></html>