Change:
Respond with {} instead of providing keyAuthorization Remove "keyAuthorization" from the challenge object returned by the server. Fixes a potential misguide for clients that enabels a MitM attack. Keep the storing of the keyAuthorization on response to retain the same behavior if an account key roll-over happens before the challenge is validated
I like this change in theory, but it's substantive enough that I'd like to give the mailing list a couple more pokes to see if anyone has further thoughts on it before we land it.
This is not an editorial change, and I think it would require pushing back further on last-call timing. Please bring this up and discuss on the mailing list; WG consensus will be required.
This was brought up on the list Dec 27th and only positive responses were received.
https://ietf-wg-URL From the spec This is not consistent with the example: Which is posting to . I would expect the example to show has . Also, there is no other mention of present in the example payload. Is this a mistake?
The example is correct. The URL for the challenge is , as shown in the response body above the example you cite: (Note the at the end that distinguishes the challenge from the authz URL ) As for the field, it looks like NAME fixed this in
thanks
This PR looks good to me. I think the proposed change makes sense and removes a potential error without sacrificing anything functionality wise. NAME NAME Can you give this a review as well?

Discussion:
characters outside the base64url alphabet, and MUST NOT include base64 padding characters ("="). <del> A client responds to this challenge by constructing a key authorization from the "token" value provided in the challenge and the client's account key.  The client then provisions the key authorization as a resource on the HTTP server for the domain in question. </del> <ins> A client fulfills this challenge by constructing a key authorization from the "token" value provided in the challenge and the client's account key.  The client then provisions the key authorization as a resource on the HTTP server for the domain in question. </ins> The path at which the resource is provisioned is comprised of the fixed prefix "/.well-known/acme-challenge/", followed by the "token" value in the challenge.  The value of the resource MUST be the ASCII representation of the key authorization. <del> The client's response to the validation request indicates its agreement to this challenge by sending the server the key authorization covering the challenge's token and the client's account key. </del> <ins> A client responds with an empty object ({}) to acknowledge that the challenge can be validated by the server. </ins> <del> The key authorization for this challenge.  This value MUST match the token from the challenge and the client's account key. On receiving a response, the server MUST verify that the key authorization in the response matches the "token" value in the challenge and the client's account key.  If they do not match, then the server MUST return an HTTP error in response to the POST request in which the client sent the challenge. </del> <ins> On receiving a response, the server constructs and stores the key authorization from the challenge "token" value and the current client account key. </ins> Given a challenge/response pair, the server verifies the client's control of the domain by verifying that the resource was provisioned

the end of the body. Verify that key authorization provided by the HTTP server matches <del> the key authorization provided by the client in its response to the challenge. </del> <ins> the key authorization stored by the server. </ins> The server SHOULD follow redirects when dereferencing the URL.

characters outside the base64url alphabet, including padding characters ("="). <del> A client responds to this challenge by constructing a key authorization from the "token" value provided in the challenge and the client's account key.  The client then computes the SHA-256 digest FIPS180-4 of the key authorization. </del> <ins> A client fulfills this challenge by constructing a key authorization from the "token" value provided in the challenge and the client's account key.  The client then computes the SHA-256 digest FIPS180-4 of the key authorization. </ins> The record provisioned to the DNS contains the base64url encoding of this digest.  The client constructs the validation domain name by

"example.org", then the client would provision the following DNS record: <del> The response to the DNS challenge provides the computed key authorization to acknowledge that the client is ready to fulfill this challenge. The key authorization for this challenge.  This value MUST match the token from the challenge and the client's account key. </del> <ins> A client responds with an empty object ({}) to acknowledge that the challenge can be validated by the server. </ins> <del> On receiving a response, the server MUST verify that the key authorization in the response matches the "token" value in the challenge and the client's account key.  If they do not match, then the server MUST return an HTTP error in response to the POST request in which the client sent the challenge. </del> <ins> On receiving a response, the server constructs and stores the key authorization from the challenge "token" value and the current client account key. </ins> To validate a DNS challenge, the server performs the following steps: <del> Compute the SHA-256 digest FIPS180-4 of the key authorization </del> <ins> Compute the SHA-256 digest FIPS180-4 of the stored key authorization </ins> Query for TXT records for the validation domain name