[cabf_validation] Replacement for Domain Validation Method 6

[Doug Beattie]

Ryan,

 

For the new ACME HTTP method I was going to just say:

*	Confirming the Applicant's control over a FQDN by validating domain control of the FQDN using the ACME HTTP Challenge method defined in section 8.3 of RFC 8555.

 

 

But when I looked at RFC I feel like it’s lacking in a few places, but I’m certainly not all that knowledgeable about the details for how it works.  Do you think we’re going to need some further detail in the BR method to supplement what’s in the ACME spec?

 

There is no discussion of redirects, so the entire redirect section should be added to this new method.

 

There isn’t a 30 day maximum usage period for the token.

 

There isn’t an explicit requirement that you must receive a 200 HTTP return code (implied as far as I can tell)

 

There are statements in RFC 8555 like “ it is possible to build clients that copy the token from request to response” and then there are some “should” statements around how to avoid issues.  ” Is that sufficient, or do we need something about the uniqueness of this token to the validation of the domain?

 

 

 

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

 

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/43353b21/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/43353b21/attachment-0001.p7s>