Original text:
The major guiding use case for ACME is obtaining certificates for Web sites (HTTPS RFC2818).  In that case, the server is intended to speak for one or more domains, and the process of certificate issuance is <del> intended to verify that the server actually speaks for the domain. </del>  Different types of certificates reflect different kinds of CA verification of information about the certificate subject.  "Domain 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 <del> server SHOULD NOT include expired certificates. </del>  5.3. If the CA participates in Certificate Transparency (CT) RFC6962, then they may want to provide the client with a Signed Certificate Timestamp (SCT) that can be used to prove that a certificate was <del> submitted to a CT log.  An SCT can be included as a extension in the </del>  certificate or as an extension to OCSP responses for the certificate. The server can also provide the client with direct access to an SCT for a certificate using a Link relation header field with relation 7. <del> There are few types of identifier in the world for which there is a </del>  standardized mechanism to prove possession of a given identifier.  In all practical cases, CAs rely on a variety of means to test whether an entity applying for a certificate with a given identifier actually by their account keys, so this overall goal breaks down into two more precise goals: <del> Only an entity that controls a identifier can get an account key </del>  authorized for that identifier Once authorized, an account key's authorizations cannot be holder) All of the challenges above that require an out-of-band query by the <del> server have a binding to the account private key, such that the only the account private key holder can successfully respond to the validation query: </del>  HTTP: The value provided in the validation request is signed by the account private key.

Reviewer comments:
editorial change
These LGTM as editorial. I note that the inclusion of "revoked" in URL is on the edge, but I think it was intended and could be merged as a result.
I did think the mentioned change might be an edge case, too, but came to the same conclusion. Happy to be of any help.
LGTM as well. Thanks NAME

Revised text:
The major guiding use case for ACME is obtaining certificates for Web sites (HTTPS RFC2818).  In that case, the server is intended to speak for one or more domains, and the process of certificate issuance is  <ins> intended to verify that the server actually speaks for the domain(s). </ins> Different types of certificates reflect different kinds of CA verification of information about the certificate subject.  "Domain 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  <ins> server SHOULD NOT include expired or revoked certificates. </ins> 5.3. If the CA participates in Certificate Transparency (CT) RFC6962, then they may want to provide the client with a Signed Certificate Timestamp (SCT) that can be used to prove that a certificate was  <ins> submitted to a CT log.  An SCT can be included as an extension in the </ins> certificate or as an extension to OCSP responses for the certificate. The server can also provide the client with direct access to an SCT for a certificate using a Link relation header field with relation 7.  <ins> There are few types of identifiers in the world for which there is a </ins> standardized mechanism to prove possession of a given identifier.  In all practical cases, CAs rely on a variety of means to test whether an entity applying for a certificate with a given identifier actually by their account keys, so this overall goal breaks down into two more precise goals:  <ins> Only an entity that controls an identifier can get an account key </ins> authorized for that identifier Once authorized, an account key's authorizations cannot be holder) All of the challenges above that require an out-of-band query by the  <ins> server have a binding to the account private key, such that only the account private key holder can successfully respond to the validation query: </ins> HTTP: The value provided in the validation request is signed by the account private key.