Original text:
5. <del> This section describes several components that are used by ACME, and general rules that apply to ACME transactions. </del>  5.1. Each ACME function is accomplished by the client sending a sequence <del> of HTTPS requests to the server, carrying JSON messages.  Use of HTTPS is REQUIRED.  Clients SHOULD support HTTP public key pinning </del>  RFC7469, and servers SHOULD emit pinning headers.  Each subsection of certificate-management below describes the message formats used by the function, and the order in which messages are sent. Servers MUST NOT respond to GET requests for resources that might be considered sensitive. <del> An ACME request carries a JSON dictionary that provides the details of the client's request to the server.  In order to avoid attacks that might arise from sending a request object to a resource of the wrong type, each request object MUST have a "resource" field that indicates what type of resource the request is addressed to, as defined in the below table: Other fields in ACME request bodies are described below. </del> 5.3. <del> An ACME registration resource represents a set of metadata associated to an account key pair.  Registration resources have the following structure: The public key of the account key pair, encoded as a JSON Web Key object RFC7517. </del>  <del> An array of URIs that the server can use to contact the client for issues related to this authorization.  For example, the server may wish to notify the client about server-initiated revocation. A URI referring to a subscriber agreement or terms of service provided by the server (see below).  Including this field indicates the client's agreement with the referenced terms. A URI from which a list of authorizations granted to this account can be fetched via a GET request.  The result of the GET request MUST be a JSON object whose "authorizations" field is an array of strings, where each string is the URI of an authorization belonging to this registration.  The server SHOULD include pending authorizations, and SHOULD NOT include authorizations that are invalid or expired.  The server MAY return an incomplete list, along with a Link header with link relation "next" indicating a URL to retrieve further entries. </del>  <del> A URI from which a list of certificates issued for this account can be fetched via a GET request.  The result of the GET request MUST be a JSON object whose "certificates" field is an array of strings, where each string is the URI of a certificate.  The server SHOULD NOT include expired or revoked certificates.  The server MAY return an incomplete list, along with a Link header with link relation "next" indicating a URL to retrieve further entries. </del>  5.4. <del> An ACME authorization object represents server's authorization for an account to represent an identifier.  In addition to the identifier, an authorization includes several metadata fields, such as the status of the authorization (e.g., "pending", "valid", or "revoked") and which challenges were used to validate possession of the identifier. The structure of an ACME authorization resource is as follows: The identifier that the account is authorized to represent The type of identifier. The identifier itself. The status of this authorization.  Possible values are: "unknown", "pending", "processing", "valid", "invalid" and "revoked".  If this field is missing, then the default value is "pending". 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. The challenges that the client needs to fulfill in order to prove possession of the identifier (for pending authorizations).  For final authorizations, the challenges that were used.  Each array entry is a dictionary with parameters required to validate the challenge, as specified in identifier-validation-challenges. A collection of sets of challenges, each of which would be sufficient to prove possession of the identifier.  Clients complete a set of challenges that covers at least one set in this array.  Challenges are identified by their indices in the challenges array.  If no "combinations" element is included in an authorization object, the client completes all challenges. The only type of identifier defined by this specification is a fully- qualified domain name (type: "dns").  The value of the identifier MUST be the ASCII representation of the domain name.  Wildcard domain names (with "*" as the first label) MUST NOT be included in authorization requests.  See certificate-issuance below for more information about wildcard domains. 5.5. Errors can be reported in ACME both at the HTTP layer and within ACME payloads.  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). When the server responds with an error status, it SHOULD provide additional information using problem document I-D.ietf-appsawg-http- problem.  To facilitate automatic response to errors, this document defines the following standard tokens for use in the "type" field (within the "urn:ietf:params:acme:error:" namespace): 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 other than the standard types.  Clients SHOULD display the "detail" field of such errors. Authorization and challenge objects can also contain error information to indicate why the server was unable to validate authorization. 5.6. </del> In order to protect ACME resources from any possible replay attacks, ACME requests have a mandatory anti-replay mechanism.  This mechanism is based on the server maintaining a list of nonces that it has value for each response, keep a list of issued nonces, and strike nonces from this list as they are used. <del> 5.6.1. </del>  The "Replay-Nonce" header field includes a server-generated value that the server can use to detect unauthorized replay in future The Replay-Nonce header field SHOULD NOT be included in HTTP request messages. <del> 5.6.2. </del>  The "nonce" header parameter provides a unique value that enables the verifier of a JWS to recognize when replay has occurred.  The "nonce" according to this encoding, then the verifier MUST reject the JWS as malformed.  6. In this section, we describe the certificate management functions The remainder of this section provides the details of how these resources are structured and how the ACME protocol makes use of them.  6.2. In order to help clients configure themselves with the right URIs for

Reviewer comments:
Move description of registration and authorization objects to Certificate Management section Re-frame Protocol Elements section to be more clearly about the transport layer Fix some references

Revised text:
5.  <ins> ACME uses a combination of HTTPS and JWS to create a messaging layer with a few important security properties. Communications between an ACME client and an ACME server are done over HTTPS, using JWS to provide som additional security properties for messages sent from the client to the server.  HTTPS provides server authentication and confidentiality.  With some ACME-specific extensions, JWS provides authentication of the client's request payloads, anti-replay protection, and a degree of integrity for the HTTPS request URI. </ins> 5.1. Each ACME function is accomplished by the client sending a sequence  <ins> of HTTPS requests to the server, carrying JSON messages RFC7159.  Use of HTTPS is REQUIRED.  Clients SHOULD support HTTP public key pinning </ins> RFC7469, and servers SHOULD emit pinning headers.  Each subsection of certificate-management below describes the message formats used by the function, and the order in which messages are sent. Servers MUST NOT respond to GET requests for resources that might be considered sensitive.  5.3.  <ins> It is common in deployment 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. These intermediaries can also change values in the request that are not signed in the HTTPS request, e.g., the request URI and headers. ACME uses JWS to provides a limited integrity mechanism, which protects against an intermediary changing the request URI to anothe ACME URI of a different type.  (It does not protect against changing between URIs of the same type, e.g., from one authorization URI to another). </ins>  <ins> An ACME request carries a JSON dictionary that provides the details of the client's request to the server.  Each request object MUST have a "resource" field that indicates what type of resource the request is addressed to, as defined in the below table: </ins>  <ins> Other fields in ACME request bodies are described below. </ins> 5.4.  In order to protect ACME resources from any possible replay attacks, ACME requests have a mandatory anti-replay mechanism.  This mechanism is based on the server maintaining a list of nonces that it has value for each response, keep a list of issued nonces, and strike nonces from this list as they are used.  <ins> 5.4.1. </ins> The "Replay-Nonce" header field includes a server-generated value that the server can use to detect unauthorized replay in future The Replay-Nonce header field SHOULD NOT be included in HTTP request messages.  <ins> 5.4.2. </ins> The "nonce" header parameter provides a unique value that enables the verifier of a JWS to recognize when replay has occurred.  The "nonce" according to this encoding, then the verifier MUST reject the JWS as malformed. <ins> 5.5. Errors can be reported in ACME both at the HTTP layer and within ACME payloads.  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). When the server responds with an error status, it SHOULD provide additional information using problem document I-D.ietf-appsawg-http- problem.  To facilitate automatic response to errors, this document defines the following standard tokens for use in the "type" field (within the "urn:ietf:params:acme:error:" namespace): 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 other than the standard types.  Clients SHOULD display the "detail" field of such errors. Authorization and challenge objects can also contain error information to indicate why the server was unable to validate authorization. </ins> 6. In this section, we describe the certificate management functions The remainder of this section provides the details of how these resources are structured and how the ACME protocol makes use of them. <ins> 6.1.1. An ACME registration resource represents a set of metadata associated to an account key pair.  Registration resources have the following structure: The public key of the account key pair, encoded as a JSON Web Key object RFC7517. An array of URIs that the server can use to contact the client for issues related to this authorization.  For example, the server may wish to notify the client about server-initiated revocation. A URI referring to a subscriber agreement or terms of service provided by the server (see below).  Including this field indicates the client's agreement with the referenced terms. A URI from which a list of authorizations granted to this account can be fetched via a GET request.  The result of the GET request MUST be a JSON object whose "authorizations" field is an array of strings, where each string is the URI of an authorization belonging to this registration.  The server SHOULD include pending authorizations, and SHOULD NOT include authorizations that are invalid or expired.  The server MAY return an incomplete list, along with a Link header with link relation "next" indicating a URL to retrieve further entries. A URI from which a list of certificates issued for this account can be fetched via a GET request.  The result of the GET request MUST be a JSON object whose "certificates" field is an array of strings, where each string is the URI of a certificate.  The server SHOULD NOT include expired or revoked certificates.  The server MAY return an incomplete list, along with a Link header with link relation "next" indicating a URL to retrieve further entries. 6.1.2. An ACME authorization object represents server's authorization for an account to represent an identifier.  In addition to the identifier, an authorization includes several metadata fields, such as the status of the authorization (e.g., "pending", "valid", or "revoked") and which challenges were used to validate possession of the identifier. The structure of an ACME authorization resource is as follows: The identifier that the account is authorized to represent The type of identifier. The identifier itself. The status of this authorization.  Possible values are: "unknown", "pending", "processing", "valid", "invalid" and "revoked".  If this field is missing, then the default value is "pending". 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. The challenges that the client needs to fulfill in order to prove possession of the identifier (for pending authorizations).  For final authorizations, the challenges that were used.  Each array entry is a dictionary with parameters required to validate the challenge, as specified in identifier-validation-challenges. A collection of sets of challenges, each of which would be sufficient to prove possession of the identifier.  Clients complete a set of challenges that covers at least one set in this array.  Challenges are identified by their indices in the challenges array.  If no "combinations" element is included in an authorization object, the client completes all challenges. The only type of identifier defined by this specification is a fully- qualified domain name (type: "dns").  The value of the identifier MUST be the ASCII representation of the domain name.  Wildcard domain names (with "*" as the first label) MUST NOT be included in authorization requests.  See certificate-issuance below for more information about wildcard domains. </ins> 6.2. In order to help clients configure themselves with the right URIs for