Draft: draft-ietf-acme-acme

Commentary: As   , there is a risk of requests being redirected to unexpected servers unless the client 's request is somehow bound to the server . As discussed on the list , we should add the full URL for the request to the request object , not just the resource class .
Paragraph (version A):
Other fields in ACME request bodies are described below.
Paragraph (version B):
As noted above, all ACME request object carry a "url" parameter in
their protected header.  This header parameter encodes the URL to
which the client is directing the request.  On receiving such an
object in an HTTP request, the server MUST compare the "url"
parameter to the request URI.  If the two do not match, then the
server MUST reject the request as unauthorized.
Paragraph (version B):
Except for the directory resource, all ACME resources are addressed
with URLs provided to the client by the server.  In such cases, the
client MUST set the "url" field to the exact string provided by the
server (rather than performing any re-encoding on the URL).
Paragraph (version B):
The "url" header parameter specifies the URL to which this JWS object
is directed RFC3986.  The "url" parameter MUST be carried in the
protected header of the JWS.  The value of the "nonce" header MUST be
a JSON string representing the URL.
Paragraph (version A):
In order to help clients configure themselves with the right URIs for
each ACME operation, ACME servers provide a directory object.  This
should be the only URL needed to configure clients.  It is a JSON
dictionary, whose keys are the "resource" values listed in resources,
and whose values are the URIs used to accomplish the corresponding
function.
Paragraph (version B):
In order to help clients configure themselves with the right URIs for
each ACME operation, ACME servers provide a directory object.  This
should be the only URL needed to configure clients.  It is a JSON
dictionary, whose keys are drawn from the following table and whose
values are the corresponding URLs.
Paragraph (version A):
A client creates a new account with the server by sending a POST
request to the server's new-registration URI.  The body of the
request is a stub registration object containing only the "contact"
field (along with the required "resource" field).
Paragraph (version B):
A client creates a new account with the server by sending a POST
request to the server's new-registration URI.  The body of the
request is a stub registration object containing only the "contact"
field.
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 B):
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 ({}).
Paragraph (version B):
This registry lists the types of resources that ACME servers may list
in their directory objects.