Draft: draft-ietf-acme-acme

Commentary: This PR updates the new challenges so that they no longer use a JSON object dictated by the server . Instead , they use a " key authorization " string that is canonically generated from the token and key for a given challenge . ( And also , while we 're here , changes " authorized key object " to " key authorization " . )
Paragraph (version A):
Several of the challenges in this document makes use of an
"authorized key" object.  Such an object is a JSON object that
encodes an authorization for a specific account key to fulfill a
specific challenge.
Paragraph (version A):
A random value that uniquely identifies a challenge.  This value
MUST have at least 128 bits of entropy, in order to prevent an
attacker from guessing it.  It MUST NOT contain any characters
outside the URL-safe Base64 alphabet.
Paragraph (version B):
The "JWK_Thumbprint" step indicates the computation specified in
RFC7638, using the SHA-256 digest.  As specified in the individual
challenges below, the token for a challenge is a JSON string
comprised entirely of characters in the base64 alphabet.  The "||"
operator indicates concatenation of strings.
Paragraph (version B):
In computations involving key authorizations, such as the digest
computations required for the DNS and TLS SNI challenges, the key
authorization string MUST be represented in UTF-8 form (or,
equivalently, ASCII).
Paragraph (version B):
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):
Form a URI by populating the URI template RFC6570
"http://{domain}/.well-known/acme-challenge/{token}", where: * the
domain field is set to the domain name being verified; and * the
token field is set to the token in the authorized key object.
Paragraph (version B):
Form a URI by populating the URI template RFC6570
"http://{domain}/.well-known/acme-challenge/{token}", where: * the
domain field is set to the domain name being verified; and * the
token field is set to the token in the challenge.
Paragraph (version A):
Verify that the Content-Type header of the response is either
absent, or has the value "application/json".
Paragraph (version A):
Verify that the body of the response is well-formed authorized key
object.
Paragraph (version A):
Verify that the "key" and "token" fields in the authorized key
object match the values from the authorized key object in the
challenge.
Paragraph (version A):
Comparisons of the "token" field MUST be performed in terms of
Unicode code points, taking into account the encodings of the stored
nonce and the body of the request.
Paragraph (version B):
Verify that the Content-Type header of the response is either
absent, or has the value "text/plain".
Paragraph (version B):
Verify that the body of the response is well-formed key
authorization.
Paragraph (version B):
Verify that key authorization provided by the server matches the
token for this challenge and the client's account key.
Paragraph (version A):
For each iteration, compute the Zi-value from the authorized keys
object in the same way as the client.
Paragraph (version B):
For each iteration, compute the Zi-value from the key
authorization in the same way as the client.
Paragraph (version A):
In response to the challenge, the client MUST parse the authorized
key object and verify that its "key" field contains the client's
account key.  The client then computes the SHA-256 digest of the
JSON-encoded authorized key object (without base64-encoding).
Paragraph (version B):
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 of the key authorization.