Draft: draft-ietf-acme

Commentary: ( As part of closing out the letsencrypt / acme - spec repo . )
Paragraph (version A):
Servers SHOULD NOT respond to GET requests for registration resources
as these requests are not authenticated.  If a client wishes to query
the server for information about its account (e.g., to examine the
"contact" or "certificates" fields), then it SHOULD do so by sending
a POST request with an empty update.  That is, it should send a JWS
whose payload is trivial ({"resource":"reg"}).
Paragraph (version A):
With Simple HTTP validation, the client in an ACME transaction proves
its control over a domain name by proving that it can provision
resources on an HTTP server that responds for that domain name.  The
ACME server challenges the client to provision a file with a specific
string as its contents.
Paragraph (version B):
With Simple HTTP validation, the client in an ACME transaction proves
its control over a domain name by proving that it can provision
resources on an HTTP server that responds for that domain name.  The
ACME server challenges the client to provision a file with a specific
JWS as its contents.
Paragraph (version A):
The value to be provisioned in the file.  This value MUST have at
least 128 bits of entropy, in order to prevent an attacker from
guessing it.  It MUST NOT contain any non-ASCII characters.
Paragraph (version A):
A client responds to this challenge by signing a JWS object and
provisioning it as a resource on the HTTP server for the domain in
question.  The payload of the JWS MUST be a JSON dictionary
containing the fields "type", "token", "path", and "tls" from the
ACME challenge and response (see below), and no other fields.  If the
"tls" field is not included in the response, then validation object
MUST have its "tls" field set to "true".  The JWS MUST be signed with
the client's account key pair.  This JWS is NOT REQUIRED to have a
"nonce" header parameter (as with the JWS objects that carry ACME
request objects), but MUST otherwise meet the guidelines laid out in
terminology.
Paragraph (version B):
The value to be used in generation of validation JWS.  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):
A client responds to this challenge by signing a JWS object and
provisioning it as a resource on the HTTP server for the domain in
question.  The payload of the JWS MUST be a JSON dictionary
containing the fields "type", "token", and "tls" from the ACME
challenge and response (see below), and no other fields.  If the
"tls" field is not included in the response, then validation object
MUST have its "tls" field set to "true".  The JWS MUST be signed with
the client's account key pair.  This JWS is NOT REQUIRED to have a
"nonce" header parameter (as with the JWS objects that carry ACME
request objects), but MUST otherwise meet the guidelines laid out in
terminology.
Paragraph (version A):
Comparisons of the "path" and "token" fields 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 "application/jose+json".
Paragraph (version B):
Verify that the body of the response is a valid JWS, signed with
the client's account key.
Paragraph (version B):
Verify that the payload of the JWS meets the following criteria: *
it is a valid JSON dictionary; * it has exactly three fields; *
its "type" field is set to "simpleHttp"; * its "token" field is
equal to the "token" field in the challenge; * its "tls" field is
equal to the "tls" field in the response, or "true" if the "tls"
field was absent.
Paragraph (version B):
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):
The value to be used in generation of validation certificate.
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 A):
A random value with at least 128 bits of entropy.  It MUST NOT
contain any characters outside the URL-safe Base64 alphabet.
Paragraph (version B):
The value to be used in generation of validation record to be
provisioned in DNS.  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.