<p dir="ltr"><br>
On May 31, 2014 9:46 AM, "Peter Bowen" <<a href="mailto:pzbowen@gmail.com">pzbowen@gmail.com</a>> wrote:<br>
><br>
> On Sat, May 31, 2014 at 9:01 AM, Ryan Sleevi <<a href="mailto:sleevi@google.com">sleevi@google.com</a>> wrote:<br>
> > On May 31, 2014 7:07 AM, "Jeremy Rowley" <<a href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>> wrote:<br>
> >> I like proposal 1 best.  However, I think the path should include the CA’s<br>
> >> name (/name-of-CA/Certificate-request or /certificate-request/name-of-CA) to<br>
> >> identify which CA performed the validation.<br>
> ><br>
> > Can you explain a bit on what security or technical value you see it<br>
> > bringing? The CA is already responsible for generating a random string that<br>
> > the customer must embed.<br>
> ><br>
> > Additionally, the goal was to use a *single* well-known URI, so that site<br>
> > operators have a single file to filter or control. Having multiple files<br>
> > forces the entire path needing to be blacklisted.<br>
><br>
> For customers who use multiple CAs, there is value in having a way to<br>
> express which confirmation is for which CA.  This could be as simple<br>
> as specifying that the file format one line per confirmation with the<br>
> first token being a CA identifier (similar to CAA issue and issuewild<br>
> record contents).  This aligns with RFC5785, which appears to<br>
> encourage files in .well-known to be structured, rather than creating<br>
> many files .well-known, by requiring registration of names.<br>
><br>
> As an example, there might be a<br>
> .well-known/ca-domain-control-verification file with:<br>
> symantec 6cf44e90-e8e2-11e3-ac10-0800200c9a66<br>
> digicert UGFsLCBJbmMuMRQwEgYDVQQLFAtDRE4gU3VwcG9ydDEXMBUGA1UEAxQOd3d3LnBh<br>
> symantec b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c<br>
><br>
> This would reflect two different concurrently valid domain control<br>
> confirmations for Symantec and one for DigiCert.<br>
><br>
> Supporting multiple concurrently valid confirmations is important,<br>
> especially if the CA verifies domain control for each certificate<br>
> signing.<br>
><br>
> Thanks,<br>
> Peter</p>
<p dir="ltr">When would you have multiple verifications in flight for a single domain?</p>
<p dir="ltr">I suppose the assumption I am making here is that when you apply for <a href="http://foo.example.com">foo.example.com</a>, you make the file based modification in <a href="http://foo.example.com/.well-known/some-file">foo.example.com/.well-known/some-file</a></p>

<p dir="ltr">If you then apply for <a href="http://bar.example.com">bar.example.com</a>, you would modify <a href="http://bar.example.com/.well-known/some-file">bar.example.com/.well-known/some-file</a></p>
<p dir="ltr">Neither foo nor bar allows CAs to check <a href="http://example.com/.well-known/some-file">http://example.com/.well-known/some-file</a>, since the BRs make it clear the check is constructed from the applied-for FQDN.</p>

<p dir="ltr">So the domain authorization within /some-file is only applicable at a point in time for your current application, and only needs to remain until the CA has vetted it (which, in cases of DV, is normally immediately, and in cases of EV, can be done at any point in time during information gathering)</p>

<p dir="ltr">That's what I meant by the brief reply - what is the scenario that you would have a single file that had multiple verifications?</p>
<p dir="ltr">The only practical example is if both <a href="http://foo.example.com">foo.example.com</a> and <a href="http://bar.example.com">bar.example.com</a> are aliases for <a href="http://baz.example.com">baz.example.com</a> - and I believe that demonstrates more about how unsuitable this is as a verification method.</p>

<p dir="ltr">If we did go the well-known file route, I should think we would need to require that foo be an A/AAAA record, that you not follow redirects, etc.</p>