[cabf_validation] Replacement for Domain Validation Method 6

[Doug Beattie]

Yes, I will add some items to the new method to cover the possible missing things in RFC 8555 and then you can comment on which are redundant which maybe should be removed.

 

I replied to some of your comments below with [DOUG]

 

 

From: Validation <validation-bounces at cabforum.org> On Behalf Of Jacob Hoffman-Andrews via Validation
Sent: Monday, November 4, 2019 5:14 PM
To: Doug Beattie via Validation <validation at cabforum.org>
Subject: Re: [cabf_validation] Replacement for Domain Validation Method 6

 

On Mon, Nov 4, 2019 at 2:00 PM Doug Beattie via Validation <validation at cabforum.org <mailto:validation at cabforum.org> > wrote:

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

 

https://tools.ietf.org/html/rfc8555#page-65

>  The server SHOULD follow redirects when dereferencing the URL.

 

 

[DOUG], yes, but we want to limit redirects to 10, only to http and https, only follow 3xx redirects, etc, so we need those added as MUST statements, right?

 

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

 

I think we will need to specify this.

 [Doug] I will add

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

 

I was surprised to see that there is not a clear MUST for 200. That seems like an oversight. There is this line:
>  If all of the above verifications succeed, then the validation is

>   successful. If the request fails, or the body does not pass these

>   checks, then it has failed.

 

Which IMO would rule out 4xx and 5xx responses, but perhaps not 201 or 202. I think it would be reasonable to add the 200 here, and file an erratum on ACME.

 

[DOUG] I will add the same words we have for the HTTP method here so they are consistent.

 

FYI, Let's Encrypt currently enforces that the response must be 200, so I expect most ACME clients are built with that requirement in mind.

 

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?

 

The response contains a "keyAuthorization" object, which contains both the "token" field from the authorization object and a fingerprint of the subscriber's account key, thus binding all such responses strongly to a single account. I think this is sufficient.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20191107/419ca97d/attachment.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/20191107/419ca97d/attachment.p7s>