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

[Ryan Sleevi]

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: https://cabforum.org/pipermail/public/attachments/20140529/2bade20f/attachment.html