Draft: draft-ietf-acme-acme

Commentary: The RFC Editor has completed their editing pass on ACME and assigned us RFC number -- ACME will be RFC 8555 In order to finalize the RFC , we now need to reconcile that with the edits that have come in while they were working , and return to them an updated XML document . This PR takes the first few steps in that process : Most of the RFC Editor 's content changes have been reflected in the Markdown . The ones that are not reflected are ones that I rejected after reviewing them . Adds an directory with : A script that removes some artifacts that kramdown - rfc2629 introduces The RFC editor 's proposed file , Some intermediate XML files to help understand the differences between the updated source and what the RFC editor provided : Raw output from kramdown - xml2rfc Output from clean- Same content as , but has RFC editor 's technical XML changes Content is the same as , but has : Whitespace adjustments to facilitate diffs with the above My comments in response to the RFC editor The authors , chairs , and ADs are currently working on a plan to work this through to completion .
Paragraph (version A):
Public Key Infrastructure X.509 (PKIX) certificates are used for a
number of purposes, the most significant of which is the
authentication of domain names.  Thus, certification authorities
(CAs) in the Web PKI are trusted to verify that an applicant for a
certificate legitimately represents the domain name(s) in the
certificate.  Today, this verification is done through a collection
of ad hoc mechanisms.  This document describes a protocol that a CA
and an applicant can use to automate the process of verification and
certificate issuance.  The protocol also provides facilities for
other certificate management functions, such as certificate
revocation.
Paragraph (version A):
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for
this draft is maintained in GitHub.  Suggested changes should be
submitted as pull requests at https://github.com/ietf-wg-acme/acme
[1].  Instructions are on that page as well.  Editorial changes can
be managed in GitHub, but any substantive change should be discussed
on the ACME mailing list (acme@ietf.org).
Paragraph (version B):
Public Key Infrastructure using X.509 (PKIX) certificates are used
for a number of purposes, the most significant of which is the
authentication of domain names.  Thus, certification authorities
(CAs) in the Web PKI are trusted to verify that an applicant for a
certificate legitimately represents the domain name(s) in the
certificate.  As of this writing, this verification is done through a
collection of ad hoc mechanisms.  This document describes a protocol
that a CA and an applicant can use to automate the process of
verification and certificate issuance.  The protocol also provides
facilities for other certificate management functions, such as
certificate revocation.
Paragraph (version A):
Cut-and-paste the CSR into a CA's web page.
Paragraph (version B):
Cut and paste the CSR into a CA's web page.
Paragraph (version A):
Receive a CA-provided challenge at a (hopefully) administrator-
controlled email address corresponding to the domain and then
respond to it on the CA's web page.
Paragraph (version B):
Receive a CA-provided challenge at (hopefully) an
administrator-controlled email address corresponding to the
domain, and then respond to it on the CA's web page.
Paragraph (version A):
It should be noted that while the focus of this document is on
validating domain names for purposes of issuing certificates in the
Web PKI, ACME supports extensions for uses with other identifiers in
other PKI contexts.  For example, as of this writing, there is
ongoing work to use ACME for issuance of Web PKI certificates
attesting to IP addresses I-D.ietf-acme-ip and STIR certificates
attesting to telephone numbers I-D.ietf-acme-telephone.
Paragraph (version B):
It should be noted that while the focus of this document is on
validating domain names for purposes of issuing certificates in the
Web PKI, ACME supports extensions for uses with other identifiers in
other PKI contexts.  For example, as of this writing, there is
ongoing work to use ACME for issuance of Web PKI certificates
attesting to IP addresses I-D.ietf-acme-ip and Secure Telephone
Identity Revisited (STIR) certificates attesting to telephone numbers
I-D.ietf-acme-telephone.
Paragraph (version A):
ACME can also be used to automate some aspects of certificate
management even where non-automated processes are still needed.  For
example, the external account binding feature (see external-account-
binding) can allow an ACME account to use authorizations that have
been granted to an external, non-ACME account.  This allows ACME to
address issuance scenarios that cannot yet be fully automated, such
as the issuance of Extended Validation certificates.
Paragraph (version B):
ACME can also be used to automate some aspects of certificate
management even where non-automated processes are still needed.  For
example, the external account binding feature (see external-account-
binding) can allow an ACME account to use authorizations that have
been granted to an external, non-ACME account.  This allows ACME to
address issuance scenarios that cannot yet be fully automated, such
as the issuance of "Extended Validation" certificates.
Paragraph (version A):
The ACME client periodically contacts the CA to get updated
certificates, stapled OCSP responses, or whatever else would be
required to keep the web server functional and its credentials up-
to-date.
Paragraph (version B):
The ACME client periodically contacts the CA to get updated
certificates, stapled Online Certificate Status Protocol (OCSP)
responses, or whatever else would be required to keep the web
server functional and its credentials up to date.
Paragraph (version A):
The two main roles in ACME are "client" and "server".  The ACME
client uses the protocol to request certificate management actions,
such as issuance or revocation.  An ACME client may run on a web
server, mail server, or some other server system which requires valid
X.509 certificates.  Or, it may run on a separate server that does
not consume the certificate, but is authorized to respond to a CA-
provided challenge.  The ACME server runs at a certification
authority, and responds to client requests, performing the requested
actions if the client is authorized.
Paragraph (version B):
The two main roles in ACME are "client" and "server".  The ACME
client uses the protocol to request certificate management actions,
such as issuance or revocation.  An ACME client may run on a web
server, mail server, or some other server system that requires valid
X.509 certificates.  Or, it may run on a separate server that does
not consume the certificate but is authorized to respond to a CA-
provided challenge.  The ACME server runs at a certification
authority and responds to client requests, performing the requested
actions if the client is authorized.
Paragraph (version A):
ACME allows a client to request certificate management actions using
a set of JavaScript Object Notation (JSON) messages carried over
HTTPS RFC7159 RFC2818.  Issuance using ACME resembles a traditional
CA's issuance process, in which a user creates an account, requests a
certificate, and proves control of the domain(s) in that certificate
in order for the CA to issue the requested certificate.
Paragraph (version B):
ACME allows a client to request certificate management actions using
a set of JavaScript Object Notation (JSON) messages carried over
HTTPS RFC8259 RFC2818.  Issuance using ACME resembles a traditional
CA's issuance process, in which a user creates an account, requests a
certificate, and proves control of the domain(s) in that certificate
in order for the CA to issue the requested certificate.
Paragraph (version A):
The first phase of ACME is for the client to request an account with
the ACME server.  The client generates an asymmetric key pair and
requests a new account, optionally providing contact information,
agreeing to terms of service, and/or associating the account with an
existing account in another system.  The creation request is signed
with the generated private key to prove that the client controls it.
Paragraph (version B):
The first phase of ACME is for the client to request an account with
the ACME server.  The client generates an asymmetric key pair and
requests a new account, optionally providing contact information,
agreeing to terms of service (ToS), and/or associating the account
with an existing account in another system.  The creation request is
signed with the generated private key to prove that the client
controls it.
Paragraph (version A):
Note that while ACME is defined with enough flexibility to handle
different types of identifiers in principle, the primary use case
addressed by this document is the case where domain names are used as
identifiers.  For example, all of the identifier validation
challenges described in identifier-validation-challenges below
address validation of domain names.  The use of ACME for other
identifiers will require further specification in order to describe
how these identifiers are encoded in the protocol and what types of
validation challenges the server might require.
Paragraph (version A):
All requests and responses sent via HTTP by ACME clients, ACME
servers, and validation servers as well as any inputs for digest
computations MUST be encoded using the UTF-8 RFC3629 character set.
Note that identifiers that appear in certificates may have their own
encoding considerations (e.g., DNS names containing non-ASCII
characters are expressed as A-labels rather than U-labels).  Any such
encoding considerations are to be applied prior to the aforementioned
UTF-8 encoding.
Paragraph (version B):
Note that while ACME is defined with enough flexibility to handle
different types of identifiers in principle, the primary use case
addressed by this document is the case where domain names are used as
identifiers.  For example, all of the identifier validation
challenges described in identifier-validation-challenges address
validation of domain names.  The use of ACME for other identifiers
will require further specification in order to describe how these
identifiers are encoded in the protocol and what types of validation
challenges the server might require.
Paragraph (version B):
All requests and responses sent via HTTP by ACME clients, ACME
servers, and validation servers as well as any inputs for digest
computations MUST be encoded using the UTF-8 character set RFC3629.
Note that identifiers that appear in certificates may have their own
encoding considerations (e.g., DNS names containing non-ASCII
characters are expressed as A-labels rather than U-labels).  Any such
encoding considerations are to be applied prior to the aforementioned
UTF-8 encoding.
Paragraph (version A):
Each ACME function is accomplished by the client sending a sequence
of HTTPS requests to the server, carrying JSON messages RFC7159.  Use
of HTTPS is REQUIRED.  Each subsection of certificate-management
below describes the message formats used by the function and the
order in which messages are sent.
Paragraph (version B):
Each ACME function is accomplished by the client sending a sequence
of HTTPS requests to the server, carrying JSON messages RFC8259.  Use
of HTTPS is REQUIRED.  Each subsection of certificate-management
below describes the message formats used by the function and the
order in which messages are sent.
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.  Encoded values that include trailing '=' characters
MUST be rejected as improperly encoded.
Paragraph (version B):
Binary fields in the JSON objects used by ACME are encoded using
base64url encoding described in Section 5 of RFC4648 according to the
profile specified in JSON Web Signature in Section 2 of RFC7515.
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):
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 B):
This field MUST NOT contain "none" or a Message
Authentication Code (MAC) algorithm (e.g. one in which the
algorithm registry description mentions MAC/HMAC).
Paragraph (version A):
For all other requests, the request is signed using an existing
account and there MUST be a "kid" field.  This field MUST contain the
account URL received by POSTing to the newAccount resource.
Paragraph (version B):
For all other requests, the request is signed using an existing
account, and there MUST be a "kid" field.  This field MUST contain
the account URL received by POSTing to the newAccount resource.
Paragraph (version A):
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 "malformed".
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 "malformed".
Paragraph (version A):
It is common in deployment for the entity terminating TLS for HTTPS
to be different from the entity operating the logical HTTPS server,
with a "request routing" layer in the middle.  For example, an ACME
CA might have a content delivery network terminate TLS connections
from clients so that it can inspect client requests for denial-of-
service protection.
Paragraph (version B):
It is common in deployment for the entity terminating TLS for HTTPS
to be different from the entity operating the logical HTTPS server,
with a "request routing" layer in the middle.  For example, an ACME
CA might have a content delivery network terminate TLS connections
from clients so that it can inspect client requests for denial-of-
service (DoS) protection.
Paragraph (version A):
As noted in request-authentication above, all ACME request objects
carry a "url" header 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" header parameter to the request URL.  If the
two do not match, then the server MUST reject the request as
unauthorized.
Paragraph (version B):
As noted in request-authentication, all ACME request objects carry a
"url" header 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" header parameter to the request URL.  If the
two do not match, then the server MUST reject the request as
unauthorized.
Paragraph (version A):
An ACME server provides nonces to clients using the HTTP Replay-Nonce
header field, as specified in replay-nonce below.  The server MUST
include a Replay-Nonce header field in every successful response to a
POST request and SHOULD provide it in error responses as well.
Paragraph (version A):
Every JWS sent by an ACME client MUST include, in its protected
header, the "nonce" header parameter, with contents as defined in
nonce-nonce-jws-header-parameter below.  As part of JWS verification,
the ACME server MUST verify that the value of the "nonce" header is a
value that the server previously provided in a Replay-Nonce header
field.  Once a nonce value has appeared in an ACME request, the
server MUST consider it invalid, in the same way as a value it had
never issued.
Paragraph (version B):
An ACME server provides nonces to clients using the HTTP Replay-Nonce
header field, as specified in replay-nonce.  The server MUST include
a Replay-Nonce header field in every successful response to a POST
request and SHOULD provide it in error responses as well.
Paragraph (version B):
Every JWS sent by an ACME client MUST include, in its protected
header, the "nonce" header parameter, with contents as defined in
nonce-nonce-jws-header-parameter.  As part of JWS verification, the
ACME server MUST verify that the value of the "nonce" header is a
value that the server previously provided in a Replay-Nonce header
field.  Once a nonce value has appeared in an ACME request, the
server MUST consider it invalid, in the same way as a value it had
never issued.
Paragraph (version A):
Errors can be reported in ACME both at the HTTP layer and within
challenge objects as defined in identifier-validation-challenges.
ACME servers can return responses with an HTTP error response code
(4XX or 5XX).  For example: If the client submits a request using a
method not allowed in this document, then the server MAY return
status code 405 (Method Not Allowed).
Paragraph (version B):
Errors can be reported in ACME both at the HTTP layer and within
challenge objects as defined in identifier-validation-challenges.
ACME servers can return responses with an HTTP error response code
(4XX or 5XX).  For example, if the client submits a request using a
method not allowed in this document, then the server MAY return
status code 405 (Method Not Allowed).
Paragraph (version A):
Subproblems need not all have the same type, and do not need to match
the top level type.
Paragraph (version A):
ACME clients may choose to use the "identifier" field of a subproblem
as a hint that an operation would succeed if that identifier were
omitted.  For instance, if an order contains ten DNS identifiers, and
the new-order request returns a problem document with two
subproblems, referencing two of those identifiers, the ACME client
may choose to submit another order containing only the eight
identifiers not listed in the problem document.
Paragraph (version B):
Subproblems need not all have the same type, and they do not need to
match the top level type.
Paragraph (version B):
ACME clients may choose to use the "identifier" field of a subproblem
as a hint that an operation would succeed if that identifier were
omitted.  For instance, if an order contains ten DNS identifiers, and
the new-order request returns a problem document with two subproblems
(referencing two of those identifiers), the ACME client may choose to
submit another order containing only the eight identifiers not listed
in the problem document.
Paragraph (version A):
a host which functions as both an ACME and a Web server may want
to keep the root path "/" for an HTML "front page", and place the
ACME directory under the path "/acme".
Paragraph (version A):
a host which only functions as an ACME server could place the
directory under the path "/".
Paragraph (version A):
If the ACME server does not implement pre-authorization (pre-
authorization) it MUST omit the "newAuthz" field of the directory.
Paragraph (version A):
The object MAY additionally contain a field "meta".  If present, it
MUST be a JSON object; each field in the object is an item of
metadata relating to the service provided by the ACME server.
Paragraph (version B):
a host that functions as both an ACME and a Web server may want to
keep the root path "/" for an HTML "front page" and place the ACME
directory under the path "/acme".
Paragraph (version B):
a host that only functions as an ACME server could place the
directory under the path "/".
Paragraph (version B):
If the ACME server does not implement pre-authorization (pre-
authorization), it MUST omit the "newAuthz" field of the directory.
Paragraph (version B):
The object MAY additionally contain a "meta" field.  If present, it
MUST be a JSON object; each field in the object is an item of
metadata relating to the service provided by the ACME server.
Paragraph (version A):
Including this field in a new-account request, with a value of
true, indicates the client's agreement with the terms of service.
This field is not updateable by the client.
Paragraph (version B):
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.  See
status-changes.
Paragraph (version B):
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.  For information on supported URL schemes,
see account-management.
Paragraph (version B):
Including this field in a new-account request, with a value of
true, indicates the client's agreement with the terms of service.
This field cannot be updated by the client.
Paragraph (version A):
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 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):
The timestamp after which the server will consider this order
invalid, encoded in the format specified in RFC 3339 RFC3339.
This field is REQUIRED for objects with "pending" or "valid" in
the status field.
Paragraph (version B):
The status of this order.  Possible values are "pending", "ready",
"processing", "valid", and "invalid".  See status-changes.
Paragraph (version B):
The timestamp after which the server will consider this order
invalid, encoded in the format specified in RFC3339.  This field
is REQUIRED for objects with "pending" or "valid" in the status
field.
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 POST-as-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; 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 A):
Any identifier of type "dns" in a new-order request MAY have a
wildcard domain name as its value.  A wildcard domain name consists
of a single asterisk character followed by a single full stop
character ("*.") followed by a domain name as defined for use in the
Subject Alternate Name Extension by RFC 5280 RFC5280.  An
authorization returned by the server for a wildcard domain name
identifier MUST NOT include the asterisk and full stop ("*.") prefix
in the authorization identifier value.  The returned authorization
MUST include the optional "wildcard" field, with a value of true.
Paragraph (version A):
The elements of the "authorizations" and "identifiers" array are
immutable once set.  The server MUST NOT change the contents of
either array after they are created.  If a client observes a change
in the contents of either array, then it SHOULD consider the order
invalid.
Paragraph (version B):
Any identifier of type "dns" in a new-order request MAY have a
wildcard domain name as its value.  A wildcard domain name consists
of a single asterisk character followed by a single full stop
character ("*.") followed by a domain name as defined for use in the
Subject Alternate Name Extension by RFC5280.  An authorization
returned by the server for a wildcard domain name identifier MUST NOT
include the asterisk and full stop ("*.") prefix in the authorization
identifier value.  The returned authorization MUST include the
optional "wildcard" field, with a value of true.
Paragraph (version B):
The elements of the "authorizations" and "identifiers" arrays are
immutable once set.  The server MUST NOT change the contents of
either array after they are created.  If a client observes a change
in the contents of either array, then it SHOULD consider the order
invalid.
Paragraph (version A):
The timestamp after which the server will consider this
authorization invalid, encoded in the format specified in RFC 3339
RFC3339.  This field is REQUIRED for objects with "valid" in the
"status" field.
Paragraph (version B):
The identifier that the account is authorized to represent.
Paragraph (version B):
The type of identifier (see below and iana-identifier).
Paragraph (version B):
The status of this authorization.  Possible values are "pending",
"valid", "invalid", "deactivated", "expired", and "revoked".  See
status-changes.
Paragraph (version B):
The timestamp after which the server will consider this
authorization invalid, encoded in the format specified in RFC3339.
This field is REQUIRED for objects with "valid" in the "status"
field.
Paragraph (version A):
For authorizations created as a result of a newOrder request
containing a DNS identifier with a value that contained a wildcard
prefix this field MUST be present, and true.
Paragraph (version A):
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 appear 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 B):
This field MUST be present and true for authorizations created as
a result of a newOrder request containing a DNS identifier with a
value that contained a wildcard prefix.  For other authorizations,
it MUST be absent.
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 appear 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):
Order objects are created in the "pending" state.  Once all of the
authorizations listed in the order object are in the "valid" state,
the order transitions to the "ready" state.  The order moves to the
"processing" state after the client submits a request to the order's
"finalize" URL and the CA begins the issuance process for the
certificate.  Once the certificate is issued, the order enters the
"valid" state.  If an error occurs at any of these stages, the order
moves to the "invalid" state.  The order also moves to the "invalid"
state if it expires, or one of its authorizations enters a final
state other than "valid" ("expired", "revoked", "deactivated").
Paragraph (version B):
Order objects are created in the "pending" state.  Once all of the
authorizations listed in the order object are in the "valid" state,
the order transitions to the "ready" state.  The order moves to the
"processing" state after the client submits a request to the order's
"finalize" URL and the CA begins the issuance process for the
certificate.  Once the certificate is issued, the order enters the
"valid" state.  If an error occurs at any of these stages, the order
moves to the "invalid" state.  The order also moves to the "invalid"
state if it expires or one of its authorizations enters a final state
other than "valid" ("expired", "revoked", or "deactivated").
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 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):
Proxy caching of responses from the new-nonce resource can cause
clients receive the same nonce repeatedly, leading to badNonce
errors.  The server MUST include a Cache-Control header field with
the "no-store" directive in responses for the new-nonce resource, in
order to prevent caching of this resource.
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 status code of 204 (No Content).
Paragraph (version B):
Proxy caching of responses from the new-nonce resource can cause
clients to receive the same nonce repeatedly, leading to badNonce
errors.  The server MUST include a Cache-Control header field with
the "no-store" directive in responses for the new-nonce resource, in
order to prevent caching of this resource.
Paragraph (version A):
In this section, we describe how an ACME client can create an account
on an ACME server, and perform some modifications to the account
after it has been created.
Paragraph (version B):
In this section, we describe how an ACME client can create an account
on an ACME server and perform some modifications to the account after
it has been created.
Paragraph (version A):
The server SHOULD validate that the contact URLs in the "contact"
field are valid and supported by the server.  If the server validates
contact URLs it MUST support the "mailto" scheme.  Clients MUST NOT
provide a "mailto" URL in the "contact" field that contains "hfields"
RFC6068, or more than one "addr-spec" in the "to" component.  If a
server encounters a "mailto" contact URL that does not meet these
criteria, then it SHOULD reject it as invalid.
Paragraph (version A):
If the server rejects a contact URL for using an unsupported scheme
it MUST return an error of type "unsupportedContact", with a
description describing the error and what types of contact URLs the
server considers acceptable.  If the server rejects a contact URL for
using a supported scheme but an invalid value then the server MUST
return an error of type "invalidContact".
Paragraph (version B):
The server SHOULD validate that the contact URLs in the "contact"
field are valid and supported by the server.  If the server validates
contact URLs, it MUST support the "mailto" scheme.  Clients MUST NOT
provide a "mailto" URL in the "contact" field that contains "hfields"
RFC6068 or more than one "addr-spec" in the "to" component.  If a
server encounters a "mailto" contact URL that does not meet these
criteria, then it SHOULD reject it as invalid.
Paragraph (version B):
If the server rejects a contact URL for using an unsupported scheme,
it MUST return an error of type "unsupportedContact", with a
description of the error and what types of contact URLs the server
considers acceptable.  If the server rejects a contact URL for using
a supported scheme but an invalid value, then the server MUST return
an error of type "invalidContact".
Paragraph (version A):
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 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 status code 200 (OK) 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):
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):
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 rollover request.
Paragraph (version B):
The JWK representation of the old key.
Paragraph (version A):
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):
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 A):
The server MUST return an error if it cannot fulfill the request as
specified, and MUST NOT issue a certificate with contents other than
those requested.  If the server requires the request to be modified
in a certain way, it should indicate the required changes using an
appropriate error type and description.
Paragraph (version B):
The server MUST return an error if it cannot fulfill the request as
specified, and it MUST NOT issue a certificate with contents other
than those requested.  If the server requires the request to be
modified in a certain way, it should indicate the required changes
using an appropriate error type and description.
Paragraph (version A):
A CSR encoding the parameters for the certificate being requested
RFC2986.  The CSR is sent in the base64url-encoded version of the
DER format.  (Note: Because this field uses base64url, and does
not include headers, it is different from PEM.).
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.
Identifiers of type "dns" MUST appear either in the commonName
portion of the requested subject name, or in an extensionRequest
attribute RFC2985 requesting a subjectAltName extension, or both.
(These identifiers may appear in any sort order.)  Specifications
that define new identifier types must specify where in the
certificate signing request these identifiers can appear.
Paragraph (version B):
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.
Identifiers of type "dns" MUST appear either in the commonName
portion of the requested subject name or in an extensionRequest
attribute RFC2985 requesting a subjectAltName extension, or both.
(These identifiers may appear in any sort order.)  Specifications
that define new identifier types must specify where in the
certificate signing request these identifiers can appear.
Paragraph (version A):
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 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 "detail" 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 B):
The identifier to appear in the resulting authorization object
(see authorization-objects).
Paragraph (version A):
Before processing the authorization request, the server SHOULD
determine whether it is willing to issue certificates for the
identifier.  For example, the server should check that the identifier
is of a supported type.  Servers might also check names against a
blacklist of known high-value identifiers.  If the server is
unwilling to issue for the identifier, it SHOULD return a 403
(Forbidden) error, with a problem document describing the reason for
the rejection.
Paragraph (version B):
Before processing the authorization request, the server SHOULD
determine whether it is willing to issue certificates for the
identifier.  For example, the server should check that the identifier
is of a supported type.  Servers might also check names against a
blacklist of known high-value identifiers.  If the server is
unwilling to issue for the identifier, it SHOULD return an error with
status code 403 (Forbidden), with a problem document describing the
reason for the rejection.
Paragraph (version A):
The server allocates a new URL for this authorization, and returns a
201 (Created) response, with the authorization URL in the Location
header field, and the JSON authorization object in the body.  The
client then follows the process described in identifier-authorization
to complete the authorization process.
Paragraph (version B):
The server allocates a new URL for this authorization and returns a
201 (Created) response with the authorization URL in the Location
header field and the JSON authorization object in the body.  The
client then follows the process described in identifier-authorization
to complete the authorization process.
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 B):
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):
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 B):
The client indicates to the server that it is ready for the challenge
validation by sending an empty JSON body ("{}") carried in a POST
request to the challenge URL (not the authorization URL).
Paragraph (version A):
The server is said to "finalize" the authorization when it has
completed one of the validations, by assigning the authorization a
status of "valid" or "invalid", corresponding to whether it considers
the account authorized for the identifier.  If the final state is
"valid", then the server MUST include an "expires" field.  When
finalizing an authorization, the server MAY remove challenges other
than the one that was completed, and may modify the "expires" field.
The server SHOULD NOT remove challenges with status "invalid".
Paragraph (version B):
The server is said to "finalize" the authorization when it has
completed one of the validations.  This is done by assigning the
authorization a status of "valid" or "invalid", corresponding to
whether it considers the account authorized for the identifier.  If
the final state is "valid", then the server MUST include an "expires"
field.  When finalizing an authorization, the server MAY remove
challenges other than the one that was completed, and it may modify
the "expires" field.  The server SHOULD NOT remove challenges with
status "invalid".
Paragraph (version A):
If a client wishes to relinquish its authorization to issue
certificates for an identifier, then it may request that the server
deactivates each authorization associated with it by sending POST
requests with the static object {"status": "deactivated"} to each
authorization URL.
Paragraph (version B):
If a client wishes to relinquish its authorization to issue
certificates for an identifier, then it may request that the server
deactivate each authorization associated with it by sending POST
requests with the static object {"status": "deactivated"} to each
authorization URL.
Paragraph (version A):
One of the revocation reasonCodes defined in Section 5.3.1 of
RFC5280 to be used when generating OCSP responses and CRLs.  If
this field is not set the server SHOULD omit the reasonCode CRL
entry extension when generating OCSP responses and CRLs.  The
server MAY disallow a subset of reasonCodes from being used by the
user.  If a request contains a disallowed reasonCode the server
MUST reject it with the error type
"urn:ietf:params:acme:error:badRevocationReason".  The problem
document detail SHOULD indicate which reasonCodes are allowed.
Paragraph (version A):
Revocation requests are different from other ACME requests in that
they can be signed either with an account key pair or the key pair in
the certificate.
Paragraph (version B):
One of the revocation reasonCodes defined in Section 5.3.1 of
RFC5280 to be used when generating OCSP responses and CRLs.  If
this field is not set, the server SHOULD omit the reasonCode CRL
entry extension when generating OCSP responses and CRLs.  The
server MAY disallow a subset of reasonCodes from being used by the
user.  If a request contains a disallowed reasonCode, then the
server MUST reject it with the error type
"urn:ietf:params:acme:error:badRevocationReason".  The problem
document detail SHOULD indicate which reasonCodes are allowed.
Paragraph (version B):
Revocation requests are different from other ACME requests in that
they can be signed with either an account key pair or the key pair in
the certificate.
Paragraph (version A):
If the revocation succeeds, the server responds with status code 200
(OK).  If the revocation fails, the server returns an error.  For
example, if the certificate has already been revoked the server
returns an error response with status code 400 (Bad Request) and type
"urn:ietf:params:acme:error:alreadyRevoked".
Paragraph (version B):
If the revocation succeeds, the server responds with status code 200
(OK).  If the revocation fails, the server returns an error.  For
example, if the certificate has already been revoked, the server
returns an error response with status code 400 (Bad Request) and type
"urn:ietf:params:acme:error:alreadyRevoked".
Paragraph (version B):
Control the identifier in question.
Paragraph (version A):
The time at which the server validated this challenge, encoded in
the format specified in RFC 3339 RFC3339.  This field is REQUIRED
if the "status" field is "valid".
Paragraph (version B):
The status of this challenge.  Possible values are "pending",
"processing", "valid", and "invalid" (see status-changes).
Paragraph (version B):
The time at which the server validated this challenge, encoded in
the format specified in RFC3339.  This field is REQUIRED if the
"status" field is "valid".
Paragraph (version A):
ACME challenges typically require the client to set up some network-
accessible resource that the server can query in order to validate
that the client controls an identifier.  In practice it is not
uncommon for the server's queries to fail while a resource is being
set up, e.g., due to information propagating across a cluster or
firewall rules not being in place.
Paragraph (version B):
ACME challenges typically require the client to set up some network-
accessible resource that the server can query in order to validate
that the client controls an identifier.  In practice, it is not
uncommon for the server's queries to fail while a resource is being
set up, e.g., due to information propagating across a cluster or
firewall rules not being in place.
Paragraph (version A):
Clients can explicitly request a retry by re-sending their response
to a challenge in a new POST request (with a new nonce, etc.).  This
allows clients to request a retry when the state has changed (e.g.,
after firewall rules have been updated).  Servers SHOULD retry a
request immediately on receiving such a POST request.  In order to
avoid denial-of-service attacks via client-initiated retries, servers
SHOULD rate-limit such requests.
Paragraph (version B):
Clients can explicitly request a retry by resending their response to
a challenge in a new POST request (with a new nonce, etc.).  This
allows clients to request a retry when the state has changed (e.g.,
after firewall rules have been updated).  Servers SHOULD retry a
request immediately on receiving such a POST request.  In order to
avoid denial-of-service attacks via client-initiated retries, servers
SHOULD rate-limit such requests.
Paragraph (version A):
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, and MUST NOT include
base64 padding characters ("=").  See RFC4086 for additional
information on randomness requirements.
Paragraph (version B):
The string "http-01".
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 and MUST NOT include
base64 padding characters ("=").  See RFC4086 for additional
information on randomness requirements.
Paragraph (version A):
Note that becuase the token appears both in the request sent by the
ACME server and in the key authorization in the response, it is
possible to build clients that copy the token from request to
response.  Clients should avoid this behavior, because it can lead to
cross-site scripting vulnerabilities; instead, clients should be
explicitly configured on a per-challenge basis.  A client that does
copy tokens from requests to responses MUST validate that the token
in the request matches the token syntax above (e.g., that it includes
only characters from the base64url alphabet).
Paragraph (version B):
Note that because the token appears both in the request sent by the
ACME server and in the key authorization in the response, it is
possible to build clients that copy the token from request to
response.  Clients should avoid this behavior because it can lead to
cross-site scripting vulnerabilities; instead, clients should be
explicitly configured on a per-challenge basis.  A client that does
copy tokens from requests to responses MUST validate that the token
in the request matches the token syntax above (e.g., that it includes
only characters from the base64url alphabet).
Paragraph (version B):
The string "dns-01".
Paragraph (version A):
This registry lists field names that are defined for use in ACME
account objects.  Fields marked as "configurable" may be included in
a new-account request.
Paragraph (version B):
The "ACME Account Object Fields" registry lists field names that are
defined for use in ACME account objects.  Fields marked as
"configurable" may be included in a new-account request.
Paragraph (version A):
This registry lists field names that are defined for use in ACME
order objects.  Fields marked as "configurable" may be included in a
new-order request.
Paragraph (version B):
The "ACME Order Object Fields" registry lists field names that are
defined for use in ACME order objects.  Fields marked as
"configurable" may be included in a new-order request.
Paragraph (version A):
This registry lists field names that are defined for use in ACME
authorization objects.  Fields marked as "configurable" may be
included in a new-authorization request.
Paragraph (version B):
The "ACME Authorization Object Fields" registry lists field names
that are defined for use in ACME authorization objects.  Fields
marked as "configurable" may be included in a new-authorization
request.
Paragraph (version A):
This registry lists values that are used within URN values that are
provided in the "type" field of problem documents in ACME.
Paragraph (version B):
The "ACME Error Types" registry lists values that are used within URN
values that are provided in the "type" field of problem documents in
ACME.
Paragraph (version A):
This registry lists the types of resources that ACME servers may list
in their directory objects.
Paragraph (version B):
The "ACME Resource Types" registry lists the types of resources that
ACME servers may list in their directory objects.
Paragraph (version A):
This registry lists field names that are defined for use in the JSON
object included in the "meta" field of an ACME directory object.
Paragraph (version B):
The "ACME Directory Metadata Fields" registry lists field names that
are defined for use in the JSON object included in the "meta" field
of an ACME directory object.
Paragraph (version A):
This registry lists the types of identifiers that can be present in
ACME authorization objects.
Paragraph (version B):
The "ACME Identifier Types" registry lists the types of identifiers
that can be present in ACME authorization objects.
Paragraph (version A):
This registry lists identifiers for the ways that CAs can validate
control of identifiers.  Each method's entry must specify whether it
corresponds to an ACME challenge type.  The "Identifier Type" field
must be contained in the Label column of the ACME Identifier Types
registry.
Paragraph (version B):
The "ACME Validation Methods" registry lists identifiers for the ways
that CAs can validate control of identifiers.  Each method's entry
must specify whether it corresponds to an ACME challenge type.  The
"Identifier Type" field must be contained in the Label column of the
"ACME Identifier Types" registry.
Paragraph (version A):
Validation methods do not have to be compatible with ACME in order to
be registered.  For example, a CA might wish to register a validation
method in order to support its use with the ACME extensions to CAA I-
D.ietf-acme-caa.
Paragraph (version B):
Validation methods do not have to be compatible with ACME in order to
be registered.  For example, a CA might wish to register a validation
method to support its use with the ACME extensions to CAA I-D.ietf-
acme-caa.
Paragraph (version A):
On the ACME channel, in addition to network layer attackers, we also
need to account for man-in-the-middle (MitM) attacks at the
application layer, and for abusive use of the protocol itself.
Protection against application layer MitM addresses potential
attackers such as Content Distribution Networks (CDNs) and
middleboxes with a TLS MitM function.  Preventing abusive use of ACME
means ensuring that an attacker with access to the validation channel
can't obtain illegitimate authorization by acting as an ACME client
(legitimately, in terms of the protocol).
Paragraph (version B):
On the ACME channel, in addition to network-layer attackers, we also
need to account for man-in-the-middle (MitM) attacks at the
application layer and for abusive use of the protocol itself.
Protection against application-layer MitM addresses potential
attackers such as Content Distribution Networks (CDNs) and
middleboxes with a TLS MitM function.  Preventing abusive use of ACME
means ensuring that an attacker with access to the validation channel
can't obtain illegitimate authorization by acting as an ACME client
(legitimately, in terms of the protocol).
Paragraph (version A):
ACME does not protect against other types of abuse by a MitM on the
ACME channel.  For example, such an attacker could send a bogus
"badSignatureAlgorithm" error response to downgrade a client to the
lowest-quality signature algorithm that the server supports.  A MitM
that is present on all connections (such as a CDN), can cause denial-
of-service conditions in a variety of ways.
Paragraph (version B):
ACME does not protect against other types of abuse by a MitM on the
ACME channel.  For example, such an attacker could send a bogus
"badSignatureAlgorithm" error response to downgrade a client to the
lowest-quality signature algorithm that the server supports.  A MitM
that is present on all connections (such as a CDN) can cause denial-
of-service conditions in a variety of ways.
Paragraph (version A):
ACME allows anyone to request challenges for an identifier by
registering an account key and sending a new-order request using that
account key.  The integrity of the authorization process thus depends
on the identifier validation challenges to ensure that the challenge
can only be completed by someone who both (1) holds the private key
of the account key pair, and (2) controls the identifier in question.
Paragraph (version B):
ACME allows anyone to request challenges for an identifier by
registering an account key and sending a new-order request using that
account key.  The integrity of the authorization process thus depends
on the identifier validation challenges to ensure that the challenge
can only be completed by someone who both (1) holds the private key
of the account key pair and (2) controls the identifier in question.
Paragraph (version A):
Has issuance been authorized or forbidden by a Certificate
Authority Authorization (CAA) record?
Paragraph (version B):
Has issuance been authorized or forbidden by a Certificate
Authority Authorization (CAA) record (RFC6844)?
Paragraph (version A):
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):
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 a
POST-as-GET request to the URL returns 404 (Not Found) or 401
(Unauthorized).
Paragraph (version B):
There are certain factors that arise in operational reality that
operators of ACME-based CAs will need to keep in mind when
configuring their services.  See the subsections below for examples.
Paragraph (version A):
For this reason, it is RECOMMENDED that each account key pair be used
only for authentication of a single ACME account.  For example, the
public key of an account key pair MUST NOT be included in a
certificate.  If an ACME client receives a request from a user for
account creation or key roll-over using an account key that the
client knows to be used elsewhere, then the client MUST return an
error.  Clients MUST generate a fresh account key for every account
creation or roll-over operation.  Note that given the requirements of
finding-an-account-url-given-a-key, servers will not create accounts
with reused keys anyway.
Paragraph (version B):
For this reason, it is RECOMMENDED that each account key pair be used
only for authentication of a single ACME account.  For example, the
public key of an account key pair MUST NOT be included in a
certificate.  If an ACME client receives a request from a user for
account creation or key rollover using an account key that the client
knows to be used elsewhere, then the client MUST return an error.
Clients MUST generate a fresh account key for every account creation
or rollover operation.  Note that given the requirements of finding-
an-account-url-given-a-key, servers will not create accounts with
reused keys anyway.
Paragraph (version A):
ACME clients and servers MUST 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.  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 B):
ACME clients and servers MUST 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.  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):
CA.  It is therefore RECOMMENDED that ACME-based CAs make all DNS
queries via DNSSEC-validating stub or recursive resolvers.  This
provides additional protection to domains which choose to make use of
DNSSEC.
Paragraph (version A):
An ACME-based CA must use only a resolver if it trusts the resolver
and every component of the network route by which it is accessed.  It
is therefore RECOMMENDED that ACME-based CAs operate their own
DNSSEC-validating resolvers within their trusted network and use
these resolvers both for both CAA record lookups and all record
lookups in furtherance of a challenge scheme (A, AAAA, TXT, etc.).
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
makes it more difficult for ACME clients to implement a "naive"
validation server that automatically replies to challenges without
being configured per-challenge.
Paragraph (version A):
ACME provides certificate chains in the widely-used format known
colloquially as PEM (though it may diverge from the actual Privacy
Enhanced Mail specifications RFC1421, as noted in RFC7468).  Some
current software will allow the configuration of a private key and a
certificate in one PEM file, by concatenating the textual encodings
of the two objects.  In the context of ACME, such software might be
vulnerable to "key replacement" attacks.  A malicious ACME server
could cause a client to use a private key of its choosing by
including the key in the PEM file returned in response to a query for
a certificate URL.
Paragraph (version A):
When processing a file of type "application/pem-certificate-chain", a
client SHOULD verify that the file contains only encoded
certificates.  If anything other than a certificate is found (i.e.,
if the string "-----BEGIN" is ever followed by anything other than
"CERTIFICATE"), then the client MUST reject the file as invalid.
Paragraph (version B):
CA.  Therefore, it is RECOMMENDED that ACME-based CAs make all DNS
queries via DNSSEC-validating stub or recursive resolvers.  This
provides additional protection to domains that choose to make use of
DNSSEC.
Paragraph (version B):
An ACME-based CA must only use a resolver if it trusts the resolver
and every component of the network route by which it is accessed.
Therefore, it is RECOMMENDED that ACME-based CAs operate their own
DNSSEC-validating resolvers within their trusted network and use
these resolvers both for CAA record lookups and all record lookups in
furtherance of a challenge scheme (A, AAAA, TXT, etc.).
Paragraph (version B):
The http-01 and dns-01 validation methods mandate the use 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.  Second, the entropy requirement makes
it more difficult for ACME clients to implement a "naive" validation
server that automatically replies to challenges without being
configured per challenge.
Paragraph (version B):
ACME provides certificate chains in the widely used format known
colloquially as PEM (though it may diverge from the actual Privacy
Enhanced Mail specification RFC1421, as noted in RFC7468).  Some
current software will allow the configuration of a private key and a
certificate in one PEM file by concatenating the textual encodings of
the two objects.  In the context of ACME, such software might be
vulnerable to key replacement attacks.  A malicious ACME server could
cause a client to use a private key of its choosing by including the
key in the PEM file returned in response to a query for a certificate
URL.