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

[Jeremy Rowley]

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/45c6fc10/attachment-0003.html>