<div dir="ltr"><div><div>Tim, Ryan, Richard: Thank you again for your help in solidifying this.<br><br>Taking Richard's updates then, I propose that the working group proposal be amended before the vote begins:<br><br></div>Define the term "Required Website Content":<br><span><br></span><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span><b><span>Required Website Content</span></b>: Either a Random Value or a Request Token, together with additional information that uniquely identifies the Subscriber, as specified by the CA.</span><br><span></span></blockquote><span><br></span></div><span>Change the first paragraph of </span><span><span><span>section 3.2.2.4.6, "Agreed-Upon Change to Website</span></span>", to state:<br></span><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span>Confirming the Applicant's control over the requested FQDN by confirming the presence of <span>Required Website Content </span>(contained in the content of a file or on a web page in the form of a meta tag) under the "/.well-known/pki-validation" directory, or another path registered with IANA for the purpose of Domain Validation, on the Authorization Domain Name that can be validated over an Authorized Port<span>. The entire Required Website Content MUST NOT appear in the request used to retrieve the file or web page</span>.</span></blockquote><div><div><br>The graphical diff of this proposed amendment is here: <a href="https://github.com/cabforum/documents/compare/Ballot-169...jcjones:Ballot-169?expand=1" target="_blank">https://github.com/cabforum/documents/compare/Ballot-169...jcjones:Ballot-169?expand=1</a><br><br></div><div>Cheers,<br></div><div>J.C.<br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 4, 2016 at 7:36 AM, Richard Barnes <span dir="ltr"><<a href="mailto:rbarnes@mozilla.com" target="_blank">rbarnes@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Fair enough. So, JC's text without the optionality:<br><br><b>"Required Website Content</b>: <span>Either a Random Value or a Request Token, together with information that uniquely identifies the Subscriber, as specified by the CA</span>"<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 4, 2016 at 10:27 AM, Tim Hollebeek <span dir="ltr"><<a href="mailto:THollebeek@trustwave.com" target="_blank">THollebeek@trustwave.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Well, the point is that in addition to removing the optionality, the added information must bind the RWC to the request. I actually like JC’s change as a good
step in the right direction.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Writing generic descriptions of validation methods tends to allow more bad things than it helps. I’d rather see a description of enough of the ACME protocol
to capture it’s necessary security features. If people want to add similar validation schemes in the future, they should be added as new methods after being adequately reviewed, instead of trying to anticipate all possible similar future methods in advance.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">-Tim<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></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""> Richard Barnes [mailto:<a href="mailto:rbarnes@mozilla.com" target="_blank">rbarnes@mozilla.com</a>]
<br>
<b>Sent:</b> Wednesday, May 04, 2016 10:18 AM<br>
<b>To:</b> J.C. Jones<br>
<b>Cc:</b> Tim Hollebeek; Ryan Sleevi; CABFPub</span></p><div><div><br>
<b>Subject:</b> Re: [cabfpub] Pre-Ballot 169: Revised Validation Requirements<u></u><u></u></div></div><p></p><div><div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Tue, May 3, 2016 at 8:06 PM, J.C. Jones <<a href="mailto:jjones@mozilla.com" target="_blank">jjones@mozilla.com</a>> wrote:<u></u><u></u></p>
<div>
<p class="MsoNormal">Tim, Ryan:<br>
<br>
Your points are well-made. As it sounds like we'd prefer to err being more ACME-specific, I propose changing the definition of Required Website Content (RWC) to:<br>
<br>
<b>Required Website Content</b>: Either a Random Value or a Request Token, optionally concatenated with additional information +{<i>to uniquely identify the Subscriber</i>}+ as specified by the CA.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">I would think the change needed would be in the other direction -- rather than adding description, remove the optionality:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><b>"Required Website Content</b>: A byte string specified by the CA containing either a Random Value or a Request Token, as well as some additional information"<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><br>
<u></u><u></u></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"><br>
This should preclude concatenating a fixed prefix, or other such simple validation schemes.<br>
<br>
I've also made a one-word clarification to my change from yesterday, clarifying that the RWC can't be contained in its entirety anywhere in the whole request, not only the path.<br>
<br>
Both of these changes are reflected in the diff at GitHub [1].<br>
<br>
1) <a href="https://github.com/cabforum/documents/compare/Ballot-169...jcjones:Ballot-169?expand=1" target="_blank">
https://github.com/cabforum/documents/compare/Ballot-169...jcjones:Ballot-169?expand=1</a><br>
<br>
Cheers,<br>
J.C.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">On Tue, May 3, 2016 at 4:21 PM, Tim Hollebeek <<a href="mailto:THollebeek@trustwave.com" target="_blank">THollebeek@trustwave.com</a>> wrote:<u></u><u></u></p>
</div>
</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>
<div>
<div>
<div>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black">Given the goal of this ballot is to remove "any other method", and we explicitly agreed at the start of this process to simply enumerate existing practice (unless egregiously
wrong), I'm not going to hold things up over my concerns. I'd like to see any other method go away ASAP.<u></u><u></u></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black">That said, this language allows "Tim's Zero Fuss Certificate Authority", which uses Random Value + "ZFCA" as the challenge, and "Tim's Zero Fuss Web Server" which simply
parrots back Request + "ZFCA" for all requests for any file under .well_known/pki-validation.<u></u><u></u></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black">I predict my product will be extremely popular, as issuance will always succeed without any configuration or manual steps. Once my web server achieves ubiquity, it will
succeed even if you accidentally use the wrong domain name in your CSR!<u></u><u></u></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black">Basically, I don't see anywhere in the proposed text where there is a requirement that the validation method must include the essential security that account_key_thumbprint
might provide.<u></u><u></u></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black">-Tim<u></u><u></u></span></p>
<p style="background:white"><span style="font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div class="MsoNormal" style="text-align:center" align="center">
<hr size="2" width="98%" align="center">
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">
<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a> <<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a>> on behalf of Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>><br>
<b>Sent:</b> Tuesday, May 3, 2016 6:07:23 PM<br>
<b>To:</b> Richard Barnes<br>
<b>Cc:</b> CABFPub<br>
<b>Subject:</b> Re: [cabfpub] Pre-Ballot 169: Revised Validation Requirements</span>
<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Tue, May 3, 2016 at 3:02 PM, Richard Barnes <<a href="mailto:rbarnes@mozilla.com" target="_blank">rbarnes@mozilla.com</a>> wrote:<u></u><u></u></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Hey Ryan,<u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">I'm confused about where you're going here.<br>
<br>
It seems like the property that we need to remedy the flaw that Peter exposed is that the server's response cannot be generated based on the request from the CA. It seems to me that the right response is just to make that requirement explicitly. As I think
JC's text does, though perhaps it could be made clearer.<u></u><u></u></p>
</div>
<p class="MsoNormal">Do you agree with that approach, and we're just arguing about wording? Or do you think the HTTP validation method needs to be even more prescriptive?<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Well, the wording is to make the HTTP validation method more prescriptive ;)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">To be clear: We're discussing wording. Tim proposed some more restrictive changes, and J.C. raised the concern that ACME relies on the lax language. The question is fundamentally trying to find out what options we have to tweak wording
or implementation - to try to close the gap so that everyone is happy.<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div class="MsoNormal" style="text-align:center" align="center">
<hr size="2" width="100%" align="center">
</div>
<p class="MsoNormal"><span style="font-size:7.5pt;font-family:"Arial","sans-serif";color:gray"><br>
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information
contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.</span><u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div></div></div><div><div>
<br>
<hr>
<font face="Arial" color="Gray" size="1"><br>
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information
contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.<br>
</font>
</div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>