Change:
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

Discussion:
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