Draft: draft-ietf-acme-acme

Commentary: Respond with { } instead of providing   " 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- 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 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 . Can you give this a review as well ?
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version A):
Verify that key authorization provided by the HTTP server matches
the key authorization provided by the client in its response to
the challenge.
Paragraph (version B):
Verify that key authorization provided by the HTTP server matches
the key authorization stored by the server.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version A):
The response to the DNS challenge provides the computed key
authorization to acknowledge that the client is ready to fulfill this
challenge.