Draft: draft-ietf-acme-acme

Commentary: Following up on my own comment : the inner / outer signature is not being flipped , the change is to the inner key parameter of the inner  ' authenticated body . I have less opposition to that change but I think it would be helpful to call out the motivation explicitly : +1 : 
 I do n't know the motivation , but for me , it makes sense if you interpret the key change as a transfer of the account from the owner of the old private key to the owner of the new private key . ( Of course , this is only interesting if these are different entities . ) With the old method , the owner of the new private key has to provide a signed message and his public key info to the owner of the old private key without knowing which account will be changed to her private key . With the new method , this is no longer possible . 
 Yeah , the motivation is that the " handshake " is supposed to be symmetrical here : Old key signs over new key and account URL New key signs over old key and account URL That way , both halves of the hand - off are represented explicitly . In addition , the existing " newKey " field does n't add any value , since the new key is already provided in the " jwk " field of the protected header . 
 Thanks - : +1 :
Paragraph (version A):
The CA verifies that the client controls the requested domain
name(s) by having the ACME client perform some action related to
the domain name(s).
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 DNS
record under example.com or an HTTP resource under
http://example.com.
Paragraph (version A):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 RFC2119.
Paragraph (version B):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 RFC8174 when, and only when, they appear in all capitals,
as shown here.
Paragraph (version A):
An ACME client is represented by an "account key pair".  The client
uses the private key of this key pair to sign all messages sent to
the server.  The server uses the public key to verify the
authenticity and integrity of messages from the client.
Paragraph (version B):
An ACME client authenticates to the server by means of an "account
key pair".  The client uses the private key of this key pair to sign
all messages sent to the server.  The server uses the public key to
verify the authenticity and integrity of messages from the client.
Paragraph (version A):
Binary fields in the JSON objects used by ACME are encoded using
base64url encoding described in RFC4648 Section 5, according to the
profile specified in JSON Web Signature RFC7515 Section 2.  This
encoding uses a URL safe character set.  Trailing '=' characters MUST
be stripped.
Paragraph (version B):
Binary fields in the JSON objects used by ACME are encoded using
base64url encoding described in RFC4648 Section 5, according to the
profile specified in JSON Web Signature RFC7515 Section 2.  This
encoding uses a URL safe character set.  Trailing '=' characters MUST
be stripped.  Encoded values that include trailing '=' characters
MUST be rejected as improperly encoded.
Paragraph (version A):
If the client sends a JWS signed with an algorithm that the server
does not support, then the server MUST return an error with status
code 400 (Bad Request) and type
"urn:ietf:params:acme:error:badSignatureAlgorithm".  The problem
document returned with the error MUST include an "algorithms" field
with an array of supported "alg" values.
Paragraph (version B):
If the client sends a JWS signed with an algorithm that the server
does not support, then the server MUST return an error with status
code 400 (Bad Request) and type
"urn:ietf:params:acme:error:badSignatureAlgorithm" (see errors).  The
problem document returned with the error MUST include an "algorithms"
field with an array of supported "alg" values.
Paragraph (version A):
The status of this account.  Possible values are: "valid",
"deactivated", and "revoked".  The value "deactivated" should be
used to indicate client-initiated deactivation whereas "revoked"
should be used to indicate server-initiated deactivation.
Paragraph (version A):
The status of this order.  Possible values are: "pending",
"ready", "processing", "valid", and "invalid".
Paragraph (version B):
The type of identifier.  This document defines the "dns"
identifier type.  See the registry defined in iana-identifier
for any others.
Paragraph (version A):
For pending orders, the authorizations that the client needs to
complete before the requested certificate can be issued (see
identifier-authorization).  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 GET request.
Paragraph (version B):
Clients should check the "status" field of an order to determine
whether they need to take any action.
Paragraph (version A):
The status of this authorization.  Possible values are: "pending",
"valid", "invalid", "deactivated", "expired", and "revoked".
Paragraph (version A):
To get a fresh nonce, the client sends a HEAD request to the new-
nonce resource on the server.  The server's response MUST include a
Replay-Nonce header field containing a fresh nonce, and SHOULD have
status code 200 (OK).  The server SHOULD also respond to GET requests
for this resource, returning an empty body (while still providing a
Replay-Nonce header) with a 204 (No Content) status.
Paragraph (version B):
To get a fresh nonce, the client sends a HEAD request to the new-
nonce resource on the server.  The server's response MUST include a
Replay-Nonce header field containing a fresh nonce, and SHOULD have
status code 200 (OK).  The server MUST also respond to GET requests
for this resource, returning an empty body (while still providing a
Replay-Nonce header) with a 204 (No Content) status.
Paragraph (version A):
If the server already has an account registered with the provided
account key, then it MUST return a response with a 200 (OK) status
code and provide the URL of that account in the Location header
field.  This allows a client that has an account key but not the
corresponding account URL to recover the account URL.
Paragraph (version B):
If the server receives a newAccount request signed with a key for
which it already has an account registered with the provided account
key, then it MUST return a response with a 200 (OK) status code and
provide the URL of that account in the Location header field.  The
body of this response represents the account object as it existed on
the server before this request; any fields in the request object MUST
be ignored.  This allows a client that has an account key but not the
corresponding account URL to recover the account URL.
Paragraph (version A):
If the client wishes to update this information in the future, it
sends a POST request with updated information to the account URL.
The server MUST ignore any updates to the "orders" field or any other
fields it does not recognize.  If the server accepts the update, it
MUST return a response with a 200 (OK) status code and the resulting
account object.
Paragraph (version B):
If the client wishes to update this information in the future, it
sends a POST request with updated information to the account URL.
The server MUST ignore any updates to the "orders" field,
"termsOfServiceAgreed" field (see changes-of-terms-of-service), or
any other fields it does not recognize.  If the server accepts the
update, it MUST return a response with a 200 (OK) status code and the
resulting account object.
Paragraph (version A):
If all of these checks pass and the CA creates a new account, then
the CA may consider the new account associated with the external
account corresponding to the MAC key and MUST reflect the value of
the "externalAccountBinding" field in the resulting account object.
If any of these checks fail, then the CA MUST reject the new-account
request.
Paragraph (version A):
The client then encapsulates the key-change object in an "inner" JWS,
signed with the requested new account key (i.e., the key matching the
"newKey" value).  This JWS then becomes the payload for the "outer"
JWS that is the body of the ACME request.
Paragraph (version A):
The inner JWS MUST have a "jwk" header parameter, containing the
public key of the new key pair (i.e., the same value as the
"newKey" field).
Paragraph (version B):
To change the key associated with an account, the client sends a
request to the server containing signatures by both the old and new
keys.  The signature by the new key covers the account URL and the
old key, signifying a request by the new key holder to take over the
account from the old key holder.  The signature by the old key covers
this request and its signature, and indicates the old key holder's
assent to the roll-over request.
Paragraph (version B):
The inner JWS MUST have a "jwk" header parameter, containing the
public key of the new key pair.
Paragraph (version A):
This transaction has signatures from both the old and new keys so
that the server can verify that the holders of the two keys both
agree to the change.  The signatures are nested to preserve the
property that all signatures on POST messages are signed by exactly
one key.
Paragraph (version B):
This transaction has signatures from both the old and new keys so
that the server can verify that the holders of the two keys both
agree to the change.  The signatures are nested to preserve the
property that all signatures on POST messages are signed by exactly
one key.  The "inner" JWS effectively represents a request by the
holder of the new key to take over the account form the holder of the
old key.  The "outer" JWS represents the current account holder's
assent to this request.
Paragraph (version A):
Check that the "newKey" field of the key-change object also
verifies the inner JWS.
Paragraph (version A):
Check that no account exists whose account key is the same as the
key in the "newKey" field.
Paragraph (version B):
Check that no account exists whose account key is the same as the
key in the "jwk" header parameter of the inner JWS.
Paragraph (version A):
The CSR encodes the client's requests with regard to the content of
the certificate to be issued.  The CSR MUST indicate the exact same
set of requested identifiers as the initial new-order request, either
in the commonName portion of the requested subject name, or in an
extensionRequest attribute RFC2985 requesting a subjectAltName
extension.
Paragraph (version A):
A request to finalize an order will result in error if the order
indicated does not have status "ready", if the CSR and order
identifiers differ, or if the account is not authorized for the
identifiers indicated in the CSR.
Paragraph (version B):
In such cases, the problem document returned by the server SHOULD use
error code "badCSR", and describe specific reasons the CSR was
rejected in its "details" field.  After returning such an error, the
server SHOULD leave the order in the "ready" state, to allow the
client to submit a new finalize request with an amended CSR.
Paragraph (version A):
The default format of the certificate is application/pem-certificate-
chain (see IANA Considerations).
Paragraph (version B):
The default format of the certificate is application/pem-certificate-
chain (see iana-considerations).
Paragraph (version A):
The status of this challenge.  Possible values are: "pending",
"processing", "valid", and "invalid".
Paragraph (version B):
The values "tls-sni-01" and "tls-sni-02" are reserved because they
were used in pre-RFC versions of this specification to denote
validation methods that were removed because they were found not to
be secure in some cases.
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.
Paragraph (version B):
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 A):
For this reason, it is RECOMMENDED that account key pairs be used for
no other purpose besides ACME authentication.  For example, the
public key of an account key pair SHOULD NOT be included in a
certificate.  ACME clients and servers SHOULD verify that a CSR
submitted in a finalize request does not contain a public key for any
known account key pair.  In particular, when a server receives a
finalize request, it MUST verify that the public key in a CSR is not
the same as the public key of the account key pair used to
authenticate that request.
Paragraph (version B):
For this reason, it is RECOMMENDED that account key pairs be used for
no other purpose besides ACME authentication.  For example, the
public key of an account key pair SHOULD NOT be included in a
certificate.  ACME clients and servers SHOULD verify that a CSR
submitted in a finalize request does not contain a public key for any
known account key pair.  In particular, when a server receives a
finalize request, it MUST verify that the public key in a CSR is not
the same as the public key of the account key pair used to
authenticate that request.  This assures that vulnerabilities in the
protocols with which the certificate is used (e.g., signing oracles
in TLS JSS15) do not result in compromise of the ACME account.