[cabf_validation] Replacement for Domain Validation Method 6

[Jacob Hoffman-Andrews]

On Mon, Nov 4, 2019 at 2:00 PM Doug Beattie via Validation <
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.


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

I think we will need to specify this.


> 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.

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/20191104/705f8a62/attachment.html>