Draft: draft-ietf-acme-acme

Commentary: This is one option for resolving the privacy concerns raised in  's and  's AD reviews . 
 I think we do n't need to require a " typ " field . I think we just need to update the semantics for each resource so that POSTs are always allowed , and a POST with the literal contents is a request to echo the current contents of that resource . This is what we already do for retrieving account objects , so we should mirror that . 
 the POST to initiate a challenge throws a : wrench : into this plan . Specifically the server needs a way to differentiate a POST to an authorization 's challenge as a POST to initiate the challenge validation process or a POST - AS - GET to poll the challenge . Both types of POST would be using a body and without the header or equivalent I do n't think it would be possible to know which was intended . One option is to change the " start the challenge " POST to include a marker field in the body instead of using a " typ " header in the JWS and reserving the empty body as a marker for POST - AS - GET . 
 Which case do you mean ? GETs are clearly allowed for certificate resources , just at the MAY level . 
 I was referring to the " Downloading the Certificate " section . After rereading the whole thing again , I realize that GET is still allowed . But still , for clarity , we should mention this fact again in this section . 
 I think we need to give the WG a chance to object to this . Yes there has been some discussion , but I 'll do a formal ' call ' email . Do n't let that delay merging , we can always revert . :)
Paragraph (version A):
ACME servers that are intended to be generally accessible need to use
Cross-Origin Resource Sharing (CORS) in order to be accessible from
browser-based clients W3C.CR-cors-20130129.  Such servers SHOULD set
the Access-Control-Allow-Origin header field to the value "*".
Paragraph (version B):
ACME servers SHOULD follow the recommendations of RFC7525 when
configuring their TLS implementations.  ACME servers that support TLS
because the ACME protocol itself includes anti-replay protections
(see replay-protection) in all cases where they are required.  For
this reason, there are no restrictions on what ACME data can be
carried in 0-RTT.
Paragraph (version B):
ACME clients MUST send a User-Agent header field, in accordance with
RFC7231.  This header field SHOULD include the name and version of
the ACME software in addition to the name and version of the
underlying HTTP client software.
Paragraph (version B):
ACME clients SHOULD send an Accept-Language header field in
accordance with RFC7231 to enable localization of error messages.
Paragraph (version B):
ACME servers that are intended to be generally accessible need to use
Cross-Origin Resource Sharing (CORS) in order to be accessible from
browser-based clients W3C.REC-cors-20140116.  Such servers SHOULD set
the Access-Control-Allow-Origin header field to the value "*".
Paragraph (version B):
This field MUST NOT contain "none" or a Message
Authentication Code (MAC)-based algorithm (e.g. one in which
the algorithm registry description mentions MAC/HMAC).
Paragraph (version A):
Note that authentication via signed JWS request bodies implies that
GET requests are not authenticated.  Servers MUST NOT respond to GET
requests for resources that might be considered sensitive.  Account
resources are the only sensitive resources defined in this
specification.
Paragraph (version B):
Note that authentication via signed JWS request bodies implies that
requests without an entity body are not authenticated, in particular
GET requests.  Except for the cases described in this section, if the
server receives a GET request, it MUST return an error with status
code 405 "Method Not Allowed" and type "malformedRequest".
Paragraph (version B):
If a client wishes to fetch a resource from the server (which would
otherwise be done with a GET), then it MUST send a POST request with
a JWS body as described above, where the payload of the JWS is a
zero-length octet string.  In other words, the "payload" field of the
JWS object MUST be present and set to the empty string ("").
Paragraph (version B):
We will refer to these as "POST-as-GET" requests.  On receiving a
request with a zero-length (and thus non-JSON) payload, the server
MUST authenticate the sender and verify any access control rules.
Otherwise, the server MUST treat this request as having the same
semantics as a GET request for the same resource.
Paragraph (version B):
The server MUST allow GET requests for the directory and newNonce
resources (see resources), in addition to POST-as-GET requests for
these resources.  This enables clients to bootstrap into the ACME
authentication system.
Paragraph (version B):
The server MAY allow GET requests for certificate resources in order
to allow certificates to be fetched by a lower-privileged process,
e.g., the web server that will use the referenced certificate chain.
(See I-D.ietf-acme-star for more advanced cases.)  A server that
allows GET requests for certificate resources can still provide a
degree of access control by assigning them capability URLs W3C.WD-
capability-urls-20140218.  As above, if the server does not allow GET
requests for a given resource, it MUST return an error with status
code 405 "Method Not Allowed" and type "malformedRequest".
Paragraph (version B):
These intermediaries can also change values in the request that are
not signed in the HTTPS request, e.g., the request URL and header
fields.  ACME uses JWS to provide an integrity mechanism, which
protects against an intermediary changing the request URL to another
ACME URL.
Paragraph (version A):
Except for the directory resource, all ACME resources are addressed
with URLs provided to the client by the server.  In requests sent to
these resources, the client MUST set the "url" header parameter to
the exact string provided by the server (rather than performing any
re-encoding on the URL).  The server SHOULD perform the corresponding
string equality check, configuring each resource with the URL string
provided to clients and having the resource check that requests have
the same string in their "url" header parameter.
Paragraph (version A):
In order to protect ACME resources from any possible replay attacks,
ACME requests have a mandatory anti-replay mechanism.  This mechanism
is based on the server maintaining a list of nonces that it has
issued to clients, and requiring any signed request from the client
to carry such a nonce.
Paragraph (version B):
In order to protect ACME resources from any possible replay attacks,
ACME POST requests have a mandatory anti-replay mechanism.  This
mechanism is based on the server maintaining a list of nonces that it
has issued to clients, and requiring any signed request from the
client to carry such a nonce.
Paragraph (version A):
This list is not exhaustive.  The server MAY return errors whose
"type" field is set to a URI other than those defined above.  Servers
MUST NOT use the ACME URN namespace acme-urn-space for errors other
than the standard types.  Clients SHOULD display the "detail" field
of all errors.
Paragraph (version B):
This list is not exhaustive.  The server MAY return errors whose
"type" field is set to a URI other than those defined above.  Servers
MUST NOT use the ACME URN namespace for errors not listed in the
appropriate IANA registry (see acme-urn-space).  Clients SHOULD
display the "detail" field of all errors.
Paragraph (version A):
In order to help clients configure themselves with the right URLs for
each ACME operation, ACME servers provide a directory object.  This
should be the only URL needed to configure clients.  It is a JSON
object, whose field names are drawn from the following table and
whose values are the corresponding URLs.
Paragraph (version B):
In order to help clients configure themselves with the right URLs for
each ACME operation, ACME servers provide a directory object.  This
should be the only URL needed to configure clients.  It is a JSON
object, whose field names are drawn from the resource registry (iana-
resource) and whose values are the corresponding URLs.
Paragraph (version A):
Each string MUST be a lowercase hostname which the ACME server
recognizes as referring to itself for the purposes of CAA record
validation as defined in RFC6844.  This allows clients to
determine the correct issuer domain name to use when configuring
CAA records.
Paragraph (version B):
The hostnames that the ACME server recognizes as referring to
itself for the purposes of CAA record validation as defined in
RFC6844.  Each string MUST represent the same sequence of ASCII
code points that the server will expect to see as the "Issuer
Domain Name" in a CAA issue or issuewild property tag.  This
allows clients to determine the correct issuer domain name to use
when configuring CAA records.
Paragraph (version A):
An array of URLs that the server can use to contact the client for
issues related to this account.  For example, the server may wish
to notify the client about server-initiated revocation or
certificate expiration.
Paragraph (version A):
A URL from which a list of orders submitted by this account can be
fetched via a GET request, as described in orders-list.
Paragraph (version B):
A URL from which a list of orders submitted by this account can be
fetched via a POST-as-GET request, as described in orders-list.
Paragraph (version B):
Each account object includes an "orders" URL from which a list of
orders created by the account can be fetched via POST-as-GET request.
The result of the request MUST be a JSON object whose "orders" field
is an array of URLs, each identifying an order belonging to the
account.  The server SHOULD include pending orders, and SHOULD NOT
include orders that are invalid in the array of URLs.  The server MAY
return an incomplete list, along with a Link header field with a
"next" link relation indicating where further entries can be
acquired.
Paragraph (version A):
For pending orders, the authorizations that the client needs to
complete before the requested certificate can be issued (see
identifier-authorization), including unexpired authorizations that
the client has completed in the past for identifiers specified in
the order.  The authorizations required are dictated by server
policy and there may not be a 1:1 relationship between the order
identifiers and the authorizations required.  For final orders (in
the "valid" or "invalid" state), the authorizations that were
completed.  Each entry is a URL from which an authorization can be
fetched with a GET request.
Paragraph (version B):
For pending orders, the authorizations that the client needs to
complete before the requested certificate can be issued (see
identifier-authorization), including unexpired authorizations that
the client has completed in the past for identifiers specified in
the order.  The authorizations required are dictated by server
policy and there may not be a 1:1 relationship between the order
identifiers and the authorizations required.  For final orders (in
the "valid" or "invalid" state), the authorizations that were
completed.  Each entry is a URL from which an authorization can be
fetched with a POST-as-GET request.
Paragraph (version B):
For pending authorizations, the challenges that the client can
fulfill in order to prove possession of the identifier.  For valid
authorizations, the challenge that was validated.  For invalid
authorizations, the challenge that was attempted and failed.  Each
array entry is an object with parameters required to validate the
challenge.  A client should attempt to fulfill one of these
challenges, and a server should consider any one of the challenges
sufficient to make the authorization valid.
Paragraph (version B):
The only type of identifier defined by this specification is a fully-
qualified domain name (type: "dns").  The domain name MUST be encoded
in the form in which it would apper in a certificate.  That is, it
MUST be encoded according to the rules in Section 7 of RFC5280.
Servers MUST verify any identifier values that begin with the ASCII
Compatible Encoding prefix "xn--" as defined in RFC5890 are properly
encoded.  Wildcard domain names (with "*" as the first label) MUST
NOT be included in authorization objects.  If an authorization object
conveys authorization for the base domain of a newOrder DNS type
identifier with a wildcard prefix then the optional authorizations
"wildcard" field MUST be present with a value of true.
Paragraph (version A):
Authorization objects are created in the "pending" state.  If one of
the challenges listed in the authorization transitions to the "valid"
state, then the authorization also changes to the "valid" state.  If
there is an error while the authorization is still pending, then the
authorization transitions to the "invalid" state.  Once the
authorization is in the valid state, it can expire ("expired"), be
deactivated by the client ("deactivated", see deactivating-an-
authorization), or revoked by the server ("revoked").
Paragraph (version A):
Servers MUST NOT respond to GET requests for account 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 "orders" 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 an empty object ({}).
Paragraph (version A):
If the server has changed its terms of service since a client
initially agreed, and the server is unwilling to process a request
without explicit agreement to the new terms, then it MUST return an
error response with status code 403 (Forbidden) and type
"urn:ietf:params:acme:error:userActionRequired".  This response MUST
include a Link header with link relation "terms-of-service" and the
latest terms-of-service URL.
Paragraph (version B):
If the server has changed its terms of service since a client
initially agreed, and the server is unwilling to process a request
without explicit agreement to the new terms, then it MUST return an
error response with status code 403 (Forbidden) and type
"urn:ietf:params:acme:error:userActionRequired".  This response MUST
include a Link header field with link relation "terms-of-service" and
the latest terms-of-service URL.
Paragraph (version A):
If a CA requires that new-account requests contain an
"externalAccountBinding" field, then it MUST provide the value "true"
in the "externalAccountRequired" subfield of the "meta" field in the
directory object.  If the CA receives a new-account request without
an "externalAccountBinding" field, then it SHOULD reply with an error
of type "externalAccountRequired".
Paragraph (version A):
A client can deactivate an account by posting a signed update to the
server with a status field of "deactivated."  Clients may wish to do
this when the account key is compromised or decommissioned.
Paragraph (version B):
A client can deactivate an account by posting a signed update to the
account URL with a status field of "deactivated."  Clients may wish
to do this when the account key is compromised or decommissioned.  A
deactivated account can no longer request certificate issuance or
access resources related to the account, such as orders or
authorizations.  If a server receives a POST or POST-as-GET from a
deactivated account, it MUST return an error response with status
code 401 (Unauthorized) and type
"urn:ietf:params:acme:error:unauthorized".
Paragraph (version B):
resource.  Clients MUST NOT make any assumptions about the sort order
of "identifiers" or "authorizations" elements in the returned order
object.
Paragraph (version A):
"processing": The certificate is being issued.  Send a GET request
after the time given in the "Retry-After" header field of the
response, if any.
Paragraph (version A):
To download the issued certificate, the client simply sends a GET
request to the certificate URL.
Paragraph (version B):
To download the issued certificate, the client simply sends a POST-
as-GET request to the certificate URL.
Paragraph (version A):
The ACME client MAY request other formats by including an Accept
header RFC7231 in its request.  For example, the client could use the
media type "application/pkix-cert" RFC2585 or "applicaiton/
pkcs7-mime" RFC5751 to request the end-entity certificate in DER
format.  Server support for alternate formats is OPTIONAL.  For
formats that can only express a single certificate, the server SHOULD
provide one or more "Link: rel="up"" headers pointing to an issuer or
issuers so that ACME clients can build a certificate chain as defined
in TLS.
Paragraph (version B):
Because certificate resources are immutable once issuance is
complete, the server MAY enable the caching of the resource by adding
Expires and Cache-Control header fields specifying a point in time in
the distant future.  These header fields have no relation to the
certificate's period of validity.
Paragraph (version A):
To prove control of the identifier and receive authorization, the
client needs to respond with information to complete the challenges.
To do this, the client updates the authorization object received from
the server by filling in any required information in the elements of
the "challenges" dictionary.
Paragraph (version A):
The client sends these updates back to the server in the form of a
JSON object with contents as specified by the challenge type, carried
in a POST request to the challenge URL (not authorization URL) once
it is ready for the server to attempt validation.
Paragraph (version B):
To prove control of the identifier and receive authorization, the
client needs to provision the required challenge response based on
the challenge type and indicate to the server that it is ready for
the challenge validation to be attempted.
Paragraph (version B):
The client indicates to the server it is ready for the challenge
validation by sending an empty JSON body ("{}"), carried in a POST
request to the challenge URL (not authorization URL).
Paragraph (version A):
To check on the status of an authorization, the client sends a GET
request to the authorization URL, and the server responds with the
current authorization object.  In responding to poll requests while
the validation is still in progress, the server MUST return a 200
(OK) response and MAY include a Retry-After header field to suggest a
polling interval to the client.
Paragraph (version B):
To check on the status of an authorization, the client sends a POST-
as-GET request to the authorization URL, and the server responds with
the current authorization object.  In responding to poll requests
while the validation is still in progress, the server MUST return a
200 (OK) response and MAY include a Retry-After header field to
suggest a polling interval to the client.
Paragraph (version A):
Error that occurred while the server was validating the challenge,
if any, structured as a problem document RFC7807.  Multiple errors
can be indicated by using subproblems subproblems.
Paragraph (version B):
Error that occurred while the server was validating the challenge,
if any, structured as a problem document RFC7807.  Multiple errors
can be indicated by using subproblems subproblems.  A challenge
object with an error MUST have status equal to "invalid".
Paragraph (version B):
The "Thumbprint" step indicates the computation specified in RFC7638,
using the SHA-256 digest FIPS180-4.  As noted in RFC7518 any
prepended zero octets in the fields of a JWK object MUST be stripped
before doing the computation.
Paragraph (version A):
Verify that the body of the response is well-formed key
authorization.  The server SHOULD ignore whitespace characters at
the end of the body.
Paragraph (version B):
Verify that the body of the response is a well-formed key
authorization.  The server SHOULD ignore whitespace characters at
the end of the body.
Paragraph (version B):
The server SHOULD follow redirects when dereferencing the URL.
Clients might use redirects, for example, so that the response can be
provided by a centralized certificate management server.  See
integrity-of-authorizations for security considerations related to
redirects.
Paragraph (version B):
A random value that uniquely identifies the challenge.  This value
MUST have at least 128 bits of entropy.  It MUST NOT contain any
characters outside the base64url alphabet, including padding
characters ("=").  See RFC4086 for additional information on
randomness requirements.
Paragraph (version B):
In order to provide easy interoperation with TLS, the first
certificate MUST be an end-entity certificate.  Each following
certificate SHOULD directly certify the one preceding it.  Because
certificate validation requires that trust anchors be distributed
independently, a certificate that represents a trust anchor MAY be
omitted from the chain, provided that supported peers are known to
possess any omitted certificates.
Paragraph (version B):
Security considerations: Carries a cryptographic certificate and its
associated certificate chain.  This media type carries no active
content.
Paragraph (version B):
Person & email address to contact for further information: See
Authors' Addresses section.
Paragraph (version B):
Author: See Authors' Addresses section.
Paragraph (version B):
This registry may also contain reserved entries (e.g., to avoid
collisions).  Such entries should have the "ACME" field set to "N"
and the "Identifier Type" set to "RESERVED".
Paragraph (version A):
All of the challenges defined in this document have a binding between
the account private key and the validation query made by the server,
via the key authorization.  The key authorization reflects the
account public key, is provided to the server in the validation
response over the validation channel and signed afterwards by the
corresponding private key in the challenge response over the ACME
channel.
Paragraph (version B):
All of the challenges defined in this document have a binding between
the account private key and the validation query made by the server,
via the key authorization.  The key authorization reflects the
account public key and is provided to the server in the validation
response over the validation channel.
Paragraph (version A):
Some server implementations include information from the validation
server's response (in order to facilitate debugging).  Such
implementations enable an attacker to extract this information from
any web server that is accessible to the ACME server, even if it is
not accessible to the ACME client.  For example, the ACME server
might be able to access servers behind a firewall that would prevent
access by the ACME client.
Paragraph (version B):
Some ACME server implementations include information from the
validation server's response (in order to facilitate debugging).
Such implementations enable an attacker to extract this information
from any web server that is accessible to the ACME server, even if it
is not accessible to the ACME client.  For example, the ACME server
might be able to access servers behind a firewall that would prevent
access by the ACME client.
Paragraph (version B):
ACME does not specify how the server constructs the URLs that it uses
to address resources.  If the server operator uses URLs that are
predictable to third parties, this can leak information about what
URLs exist on the server, since an attacker can probe for whether
POST-as-GET request to the URL returns "Not Found" or "Unauthorized".
Paragraph (version B):
If the ID fields have low entropy, then an attacker can find out how
many users a CA has, how many authorizations each account has, etc.
Paragraph (version B):
In order to avoid leaking these correlations, servers SHOULD assign
capability URLs for dynamically-created resources W3C.WD-capability-
urls-20140218.  These URLs incorporate large unpredictable components
to prevent third parties from guessing them.  These URLs SHOULD NOT
have a structure that would enable a third party to infer
correlations between resources.
Paragraph (version B):
Such a scheme would leak only the type of resource, hiding the
additional correlations revealed in the example above.
Paragraph (version B):
Because ACME accounts are uniquely identified by their account key
pair (see finding-an-account-url-given-a-key) the server MUST not
allow account key pair reuse across multiple accounts.
Paragraph (version A):
The http-01, and dns-01 validation methods mandate the usage of a
random token value to uniquely identify the challenge.  The value of
the token is required to contain at least 128 bits of entropy for the
following security properties.  First, the ACME client should not be
able to influence the ACME server's choice of token as this may allow
an attacker to reuse a domain owner's previous challenge responses
for a new validation request.  Secondly, the entropy requirement
prevents ACME clients from implementing a "naive" validation server
that automatically replies to challenges without participating in the
creation of the initial authorization request.
Paragraph (version B):
The http-01 and dns-01 validation methods mandate the usage of a
random token value to uniquely identify the challenge.  The value of
the token is required to contain at least 128 bits of entropy for the
following security properties.  First, the ACME client should not be
able to influence the ACME server's choice of token as this may allow
an attacker to reuse a domain owner's previous challenge responses
for a new validation request.  Secondly, the entropy requirement
prevents ACME clients from implementing a "naive" validation server
that automatically replies to challenges without participating in the
creation of the initial authorization request.