<p dir="ltr">J.C.,</p>
<p dir="ltr">Could this change?</p>
<p dir="ltr">This provides a good example of a practice that, in the abstract, may be too dangerous too allow, even if it is presently practiced under Item 7 of the BRs. We are forced to chose between the Devil we Know (the security risks pointed out) and the Devil we Don't Know (all the terrible things that can occur under the existing Item 7/Any equivalent method)</p>
<p dir="ltr">One option is to revise the proposed ballot to be explicit in its use of the presumed safe construct, rather than attempting to formalize it in the general. Another would be if the CA or CAs who depend on the unsafe (in the general) construct could change to a solution that is more objectively safe, when phrased in the BRs.</p>
<p dir="ltr">I'm just trying to explore what possible solutions we may have, if any, to remedy this security flaw, which needs to happen either now or, if it is punted, immediately following the approval of this ballot.</p>
<div class="gmail_quote">On May 3, 2016 8:53 AM, "J.C. Jones" <<a href="mailto:jjones@mozilla.com">jjones@mozilla.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Tim,<br>
<br>
This is deliberate. For example: ACME's HTTP validation mechanism [1]<br>
includes the Random Value in the path, and the ACME server expects to<br>
find in the body the concatenated string  `$random_value ||<br>
$account_key_thumbprint`. The "Account Key" used in this validation is<br>
not included in the request by the CA, and would only be known to the<br>
CA and the Subscriber.<br>
<br>
When the Required Website Content includes information not included in<br>
the HTTP validation request, the highlighted risk of false-positives<br>
from certain webserver configurations is mitigated. Supporting this,<br>
some months back an older draft ACME was formally analyzed [2] and<br>
there were no false-positive issues identified, though I haven't yet<br>
seen the final report.<br>
<br>
1) <a href="https://tools.ietf.org/html/draft-ietf-acme-acme-02#section-7.2" rel="noreferrer" target="_blank">https://tools.ietf.org/html/draft-ietf-acme-acme-02#section-7.2</a><br>
2) <a href="https://www.ietf.org/mail-archive/web/acme/current/msg00996.html" rel="noreferrer" target="_blank">https://www.ietf.org/mail-archive/web/acme/current/msg00996.html</a><br>
<br>
Cheers,<br>
J.C.<br>
<br>
On Tue, May 3, 2016 at 7:47 AM, Tim Hollebeek <<a href="mailto:THollebeek@trustwave.com">THollebeek@trustwave.com</a>> wrote:<br>
> I'm slightly concerned that this exact text allows the "Random Value" or "Request Token" to be in the path, as long as the entire RWC is not in the path.<br>
><br>
> Should it perhaps instead say that the Random Value or Request Token part of the RWC must not appear in the path?<br>
><br>
> -Tim<br>
><br>
> -----Original Message-----<br>
> From: <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>] On Behalf Of J.C. Jones<br>
> Sent: Monday, May 02, 2016 2:28 PM<br>
> To: Gervase Markham<br>
> Cc: <a href="mailto:public@cabforum.org">public@cabforum.org</a><br>
> Subject: Re: [cabfpub] Pre-Ballot 169: Revised Validation Requirements<br>
><br>
> All,<br>
><br>
> One concern with mandating a prefix is that it would break the HTTP validation for the ACME protocol. After some discussions, I'd like to propose adding a new term "Required Website Content" and use that term in the method. Credit to Andrew Ayer for the proposed text (thanks!).<br>
><br>
> The diff against Ballot-169 is available at GitHub [1], and can be made into a pull request (into Ballot-169 branch) if desired.<br>
><br>
> New Term:<br>
><br>
>   **Required Website Content**: Either a Random Value or a Request Token, optionally concatenated with additional information as specified by the CA.<br>
><br>
> Method Change (additions in +{ }+ brackets):<br>
><br>
>   ##### 3.2.2.4.6 Agreed-Upon Change to Website<br>
>   Confirming the Applicant's control over the requested FQDN by confirming the presence of +{Required Website Content}+ (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. +{The entire Required Website Content MUST NOT appear in the path used to retrieve the file or web page.}+<br>
><br>
> 1) <a href="http://scanmail.trustwave.com/?c=4062&d=15yn16AuR_LXsSVpRkrsubRsDevOE_8__pvrBZZ2xg&s=5&u=https%3a%2f%2fgithub%2ecom%2fcabforum%2fdocuments%2fcompare%2fBallot-169%2e%2e%2ejcjones%3aBallot-169%3fexpand%3d1" rel="noreferrer" target="_blank">http://scanmail.trustwave.com/?c=4062&d=15yn16AuR_LXsSVpRkrsubRsDevOE_8__pvrBZZ2xg&s=5&u=https%3a%2f%2fgithub%2ecom%2fcabforum%2fdocuments%2fcompare%2fBallot-169%2e%2e%2ejcjones%3aBallot-169%3fexpand%3d1</a><br>
><br>
> Cheers,<br>
> J.C.<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" rel="noreferrer" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
</blockquote></div>