[cabfpub] For discussion: Restricting the use of file-based demonstrations of control

[Ryan Sleevi]

On May 31, 2014 9:46 AM, "Peter Bowen" <pzbowen at gmail.com> wrote:
>
> On Sat, May 31, 2014 at 9:01 AM, Ryan Sleevi <sleevi at google.com> wrote:
> > On May 31, 2014 7:07 AM, "Jeremy Rowley" <jeremy.rowley at digicert.com>
wrote:
> >> 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.
> >
> > Can you explain a bit on what security or technical value you see it
> > bringing? The CA is already responsible for generating a random string
that
> > the customer must embed.
> >
> > Additionally, the goal was to use a *single* well-known URI, so that
site
> > operators have a single file to filter or control. Having multiple files
> > forces the entire path needing to be blacklisted.
>
> For customers who use multiple CAs, there is value in having a way to
> express which confirmation is for which CA.  This could be as simple
> as specifying that the file format one line per confirmation with the
> first token being a CA identifier (similar to CAA issue and issuewild
> record contents).  This aligns with RFC5785, which appears to
> encourage files in .well-known to be structured, rather than creating
> many files .well-known, by requiring registration of names.
>
> As an example, there might be a
> .well-known/ca-domain-control-verification file with:
> symantec 6cf44e90-e8e2-11e3-ac10-0800200c9a66
> digicert UGFsLCBJbmMuMRQwEgYDVQQLFAtDRE4gU3VwcG9ydDEXMBUGA1UEAxQOd3d3LnBh
> symantec b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c
>
> This would reflect two different concurrently valid domain control
> confirmations for Symantec and one for DigiCert.
>
> Supporting multiple concurrently valid confirmations is important,
> especially if the CA verifies domain control for each certificate
> signing.
>
> Thanks,
> Peter

When would you have multiple verifications in flight for a single domain?

I suppose the assumption I am making here is that when you apply for
foo.example.com, you make the file based modification in
foo.example.com/.well-known/some-file

If you then apply for bar.example.com, you would modify
bar.example.com/.well-known/some-file

Neither foo nor bar allows CAs to check
http://example.com/.well-known/some-file, since the BRs make it clear the
check is constructed from the applied-for FQDN.

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)

That's what I meant by the brief reply - what is the scenario that you
would have a single file that had multiple verifications?

The only practical example is if both foo.example.com and bar.example.com
are aliases for baz.example.com - and I believe that demonstrates more
about how unsuitable this is as a verification method.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140531/7bda1e7e/attachment.html