Draft: draft-ietf-acme-acme

Commentary: I do n't see any significant semantic changes , mainly wording clarifications .
Paragraph (version A):
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 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, and requiring any signed request from the client to carry
such a nonce.
Paragraph (version A):
The "up" link relation is used with challenge resources to indicate
the authorization resource to which a challenge belongs.  It is also
used from certificate resources to indicate a resource from which the
client may fetch a chain of CA certificates that could be used to
validate the certificate in the original resource.
Paragraph (version B):
The "up" link relation is used with challenge resources to indicate
the authorization resource to which a challenge belongs.  It is also
used, with some media types, from certificate resources to indicate a
resource from which the client may fetch a chain of CA certificates
that could be used to validate the certificate in the original
resource.
Paragraph (version A):
A client creates a new account with the server by sending a POST
request to the server's new-account URL.  The body of the request is
a stub account object optionally containing the "contact" and
"termsOfServiceAgreed" fields.
Paragraph (version B):
A client creates a new account with the server by sending a POST
request to the server's new-account URL.  The body of the request is
a stub account object optionally containing the "contact" and
"termsOfServiceAgreed" fields, and optionally the
"onlyReturnExisting" and "externalAccountBinding" fields.
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,
"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 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), the
"status" field (except as allowed by account-deactivation), 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):
The ACME client MAY request other formats by including an Accept
header field 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"" header fields pointing to an
issuer or issuers so that ACME clients can build a certificate chain
as defined in TLS.
Paragraph (version B):
The ACME client MAY request other formats by including an Accept
header field 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"" header fields pointing to an
issuer or issuers so that ACME clients can build a certificate chain
as defined in TLS RFC8446.
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 by predicting the token.