[cabf_validation] Replacement for Domain Validation Method 6

[Doug Beattie]

Ok, so make 2 new methods to replace method 6, one that is ACME and one that is “everything else”.

 

 

 

From: Ryan Sleevi <sleevi at google.com> 
Sent: Monday, November 4, 2019 1:09 PM
To: Doug Beattie <doug.beattie at globalsign.com>
Cc: CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: Re: [cabf_validation] Replacement for Domain Validation Method 6

 

 

 

On Mon, Nov 4, 2019 at 12:54 PM Doug Beattie <doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com> > wrote:

Ryan,

 

Thanks for the comments and especially for the proposed re-wording that would be acceptable, that saves a lot of time.  I agree with all of your comments and will incorporate them except for the comment about the location of the file. 

 

Great. Glad the context and the changes were acceptable.

 

 

The intent of this change was to remove “or another path registered with IANA for the purpose of Domain Validation” and to specifically define the 2 places where the validation could be done.  Is it an important security related recommendation to specify ACME MUST use only '.well-known/acme-challenge/ and that all other  implementing of this method MUST use /.well-known/pki-validation (if that is what you were recommending)?  Since multiple random Numbers may be in the same file, I don’t think this will cause interoperability issues, but I wasn’t sure what motived your recommendation.

 

Yes, I'm suggesting it's both a security and an interoperability issue. We want the contents of .well-known/acme-challenge, which is registered with IANA at https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml for use with RFC 8555, Section 8.3, to be used in accordance with RFC 8555, which defines an overall protocol for validating.

 

In general, this is a category of attacks known as "cross-protocol attacks" - in which the requests/responses from one protocol are confused as another. This is particularly pervasive in plaintext protocols, like 3.2.2.4.6 is trying to be. Classic examples are confusing HTTP requests for IRC or SMTP traffic in web browsers (this is known as "XPS" or cross-protocol scripting). This is also why we tightened down the TXT records for the new validation methods, since they're plaintext, to avoid any confusion.

 

That's why the easiest resolution was to explicitly list http-01 as a distinct validation method, with its RFC-specified processing model, and then if we want to continue with something that isn't http-01, that's a separate method. I think we're better off wholesale moving to HTTP-01, which has received much wider review and security analysis, but I can understand that some CAs are not yet ready to transition, and I wouldn't want to block tightening up 3.2.2.4.6 on that.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20191104/769d1ee6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5701 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20191104/769d1ee6/attachment-0001.p7s>