Draft: draft-ietf-acme-acme

Commentary: Some grammar fixes POST - as - GETs should be indicated as having a signature in flow Specify that the JWS profile we define in Section 6.2 is for ACME request bodies , to distinuish it from the profile used for External Account Binding . They have incompatible requirements : MUST NOT use MAC vs MUST use MAC . Clarify that Replay - Nonce is an HTTP header field since it 's defined near JWS header parameters . Do n't include " wildcard " : false in examples . Section 7.1.4 requires that it MUST be absent when false . There was lingering language in the Section 7.5.1 about " updating " an authorization body in response to fields in a challenge POST . Since the challenge POST is now described explicitly as " an empty  body " , this language did n't make sense . Fixed . 
 Per offline review , I back in a sentence that contained a MUST :
Paragraph (version A):
The CA verifies that the client controls the requested domain
name(s) by having the ACME client perform some action(s) that can
only be done with control of the domain name(s).  For example, the
CA might require a client requesting example.com to provision DNS
record under example.com or an HTTP resource under
http://example.com.
Paragraph (version B):
The CA verifies that the client controls the requested domain
name(s) by having the ACME client perform some action(s) that can
only be done with control of the domain name(s).  For example, the
CA might require a client requesting example.com to provision a
DNS record under example.com or an HTTP resource under
http://example.com.
Paragraph (version A):
The Replay-Nonce header field includes a server-generated value that
the server can use to detect unauthorized replay in future client
requests.  The server MUST generate the value provided in Replay-
Nonce in such a way that they are unique to each message, with high
probability, and unpredictable to anyone besides the server.  For
instance, it is acceptable to generate Replay-Nonces randomly.
Paragraph (version B):
The Replay-Nonce HTTP header field includes a server-generated value
that the server can use to detect unauthorized replay in future
client requests.  The server MUST generate the values provided in
Replay-Nonce header fields in such a way that they are unique to each
message, with high probability, and unpredictable to anyone besides
the server.  For instance, it is acceptable to generate Replay-Nonces
randomly.
Paragraph (version A):
This process may be repeated to associate multiple identifiers to a
key pair (e.g., to request certificates with multiple identifiers) or
to associate multiple accounts with an identifier (e.g., to allow
multiple entities to manage certificates).
Paragraph (version A):
Authorization resources are created by the server in response to
certificate orders or authorization requests submitted by an account
key holder; their URLs are provided to the client in the responses to
these requests.  The authorization object is implicitly tied to the
account key used to sign the request.
Paragraph (version A):
When a client receives an order from the server in reply to a new
order request, it downloads the authorization resources by sending
POST-as-GET requests to the indicated URLs.  If the client initiates
authorization using a request to the newAuthz resource, it will have
already received the pending authorization object in the response to
that request.
Paragraph (version B):
This process may be repeated to associate multiple identifiers with
an account (e.g., to request certificates with multiple identifiers)
or to associate multiple accounts with an identifier (e.g., to allow
multiple entities to manage certificates).
Paragraph (version B):
Authorization resources are created by the server in response to
newOrder or newAuthorization requests submitted by an account key
holder; their URLs are provided to the client in the responses to
these requests.  The authorization object is implicitly tied to the
account key used to sign the request.
Paragraph (version B):
When a client receives an order from the server in reply to a
newOrder request, it downloads the authorization resources by sending
POST-as-GET requests to the indicated URLs.  If the client initiates
authorization using a request to the newAuthz resource, it will have
already received the pending authorization object in the response to
that request.
Paragraph (version A):
The server updates the authorization document by updating its
representation of the challenge with the response object provided by
the client.  The server MUST ignore any fields in the response object
that are not specified as response fields for this type of challenge.
The server provides a 200 (OK) response with the updated challenge
object as its body.
Paragraph (version B):
The server updates the authorization document by updating its
representation of the challenge with the response object provided by
the client.  The server MUST ignore any fields in the response object
that are not specified as response fields for this type of challenge.
Note that the challenges in this document do not define any response
fields, but future specifications might define them.  The server
provides a 200 (OK) response with the updated challenge object as its
body.