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

[Ryan Sleevi]

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.
On May 31, 2014 7:07 AM, "Jeremy Rowley" <jeremy.rowley at digicert.com> wrote:

> Hi Ryan,
>
>
>
> 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.
>
>
>
> Thanks,
>
> Jeremy
>
>
>
> *From:* public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] *On
> Behalf Of *Ryan Sleevi
> *Sent:* Thursday, May 29, 2014 7:09 PM
> *To:* CABFPub
> *Subject:* [cabfpub] For discussion: Restricting the use of file-based
> demonstrations of control
>
>
>
> 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.
>
>
>
> 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)
>
>
>
>
>
>
>
> Proposal 1: Remove 11.1.1 (6)
>
> 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.
>
>
>
> 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).
>
>
>
>
>
>
>
> 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).
>
> 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).
>
>
>
> 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.
>
>
>
>
>
> 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
> www.example.com, and being issued a certificate for *.example.com. 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140531/b281d077/attachment-0003.html>