Draft: draft-ietf-acme-acme

Commentary: Looks good to me . Thanks for the revisions : trophy : Reading carefully , I see some good clarifications and one ( redirect ) concession to reality .
Mailing list commentary: has entered the following ballot position for draft - ietf - acme - acme-14 : No Objection When responding , please keep the subject line intact and reply to all email addresses included in the To and CC lines . ( Feel free to cut this introductory paragraph , however . ) Please refer to for more information about IESG DISCUSS and COMMENT positions . The document , along with other ballot positions , can be found here :
Paragraph (version A):
https://mailarchive.ietf.org/arch/msg/acme/_CQgGVs9pglD3ZMFg_MIPUJAKqQACME clients MUST send a User-Agent header, in accordance with
RFC7231.  This header 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 A):
ACME clients SHOULD send an Accept-Language header in accordance with
RFC7231 to enable localization of error messages.
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 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):
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):
Each account object includes an "orders" URL from which a list of
orders created by the account can be fetched via GET request.  The
result of the GET 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 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 GET request.  The
result of the GET 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):
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):
resource.  Clients SHOULD NOT make any assumptions about the sort
order of "identifiers" or "authorizations" elements in the returned
order object.
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):
Because certificate resources are immutable once issuance is
complete, the server MAY enable the caching of the resource by adding
Expires and Cache-Control headers specifying a point in time in the
distant future.  These headers have no relation to the certificate's
period of validity.
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 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.
Paragraph (version A):
The server SHOULD follow redirects when dereferencing the URL.
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 file of this type contains one or more certificates encoded with
the PEM textual encoding, according to RFC 7468 RFC7468.  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 A):
File contains one or more certificates encoded with the PEM textual
encoding, according to RFC 7468 RFC7468.  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 specifies a
trust anchor MAY be omitted from the chain, provided that supported
peers are known to possess any omitted certificates.
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 A):
ACME: "Y" if the validation method corresponds to an ACME
challenge type; "N" otherwise.
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".