Draft: draft-ietf-acme-acme

Commentary: editorial change 
 These LGTM as editorial . I note that the inclusion of " revoked " in 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
Paragraph (version A):
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
intended to verify that the server actually speaks for the domain.
Paragraph (version B):
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
intended to verify that the server actually speaks for the domain(s).
Paragraph (version A):
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 certificates.
Paragraph (version B):
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.
Paragraph (version A):
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
submitted to a CT log.  An SCT can be included as a extension in the
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
"ct-sct".
Paragraph (version B):
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
submitted to a CT log.  An SCT can be included as an extension in the
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
"ct-sct".
Paragraph (version A):
There are few types of identifier in the world for which there is a
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
controls that identifier.
Paragraph (version B):
There are few types of identifiers in the world for which there is a
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
controls that identifier.