Draft: draft-ietf-acme-acme

Commentary: This pull request includes editorial changes related to : Terminology and acronyms standards Punctuation and grammar Section references This is not an attempt to address any of the above in a holistic / complete way ; I 've only addressed the instances I noted while reading the document . 
 Thanks !
Paragraph (version A):
Receive CA challenge at a (hopefully) administrator-controlled
e-mail address corresponding to the domain and then respond to
it on the CA's web page.
Paragraph (version B):
Receive CA challenge at a (hopefully) administrator-controlled
email address corresponding to the domain and then respond to
it on the CA's web page.
Paragraph (version A):
This document describes an extensible framework for automating the
issuance and domain validation procedure, thereby allowing servers
and infrastructural software to obtain certificates without user
interaction.  Use of this protocol should radically simplify the
deployment of HTTPS and the practicality of PKIX authentication for
other protocols based on TLS RFC5246.
Paragraph (version B):
This document describes an extensible framework for automating the
issuance and domain validation procedure, thereby allowing servers
and infrastructural software to obtain certificates without user
interaction.  Use of this protocol should radically simplify the
deployment of HTTPS and the practicality of PKIX authentication for
other protocols based on Transport Layer Security (TLS) RFC5246.
Paragraph (version A):
Once the CA is satisfied, the certificate is issued and the ACME
client automatically downloads and installs it, potentially
notifying the operator via e-mail, SMS, etc.
Paragraph (version B):
Once the CA is satisfied, the certificate is issued and the ACME
client automatically downloads and installs it, potentially
notifying the operator via email, SMS, etc.
Paragraph (version A):
ACME allows a client to request certificate management actions using
a set of JSON messages carried over HTTPS.  In many ways, ACME
functions much like a traditional CA, in which a user creates an
account, requests a certificate, and proves control of the domains in
that certificate in order for the CA to sign the requested
certificate.
Paragraph (version B):
ACME allows a client to request certificate management actions using
a set of JavaScript Object Notation (JSON) messages carried over
HTTPS.  In many ways, ACME functions much like a traditional CA, in
which a user creates an account, requests a certificate, and proves
control of the domains in that certificate in order for the CA to
sign the requested certificate.
Paragraph (version A):
For example, in most cases, the server will require the client to
demonstrate that it controls the identifiers in the requested
certificate.  Because there are many different ways to validate
possession of different types of identifiers, the server will choose
from an extensible set of challenges that are appropriate for the
identifier being claimed.  The client responds with a set of
responses that tell the server which challenges the client has
completed.  The server then validates the challenges to check that
the client has accomplished the challenge.
Paragraph (version B):
For example, in most cases, the server will require the client to
demonstrate that it controls the identifiers in the requested
certificate.  Because there are many different ways to validate
possession of different types of identifiers, the server will choose
from an extensible set of challenges that are appropriate for the
identifier being claimed.  The client responds with a set of
responses that tell the server which challenges the client has
completed.  The server then validates the challenges to check that
the client has accomplished them.
Paragraph (version A):
Note that while ACME is defined with enough flexibility to handle
different types of identifiers in principle, the primary use case
addressed by this document is the case where domain names are used as
identifiers.  For example, all of the identifier validation
challenges described in identifier-validation-challenges below
address validation of domain names.  The use of ACME for other
identifiers will require further specification, in order to describe
how these identifiers are encoded in the protocol, and what types of
validation challenges the server might require.
Paragraph (version B):
Note that while ACME is defined with enough flexibility to handle
different types of identifiers in principle, the primary use case
addressed by this document is the case where domain names are used as
identifiers.  For example, all of the identifier validation
challenges described in identifier-validation-challenges below
address validation of domain names.  The use of ACME for other
identifiers will require further specification in order to describe
how these identifiers are encoded in the protocol and what types of
validation challenges the server might require.
Paragraph (version A):
"kid" (for all other requests).
Paragraph (version A):
As noted above, all ACME request objects carry a "url" parameter in
their protected header.  This header parameter encodes the URL to
which the client is directing the request.  On receiving such an
object in an HTTP request, the server MUST compare the "url"
parameter to the request URI.  If the two do not match, then the
server MUST reject the request as unauthorized.
Paragraph (version B):
As noted in request-authentication above, all ACME request objects
carry a "url" parameter in their protected header.  This header
parameter encodes the URL to which the client is directing the
request.  On receiving such an object in an HTTP request, the server
MUST compare the "url" parameter to the request URI.  If the two do
not match, then the server MUST reject the request as unauthorized.
Paragraph (version A):
An ACME server provides nonces to clients using the Replay-Nonce
header field, as specified below.  The server MUST include a Replay-
Nonce header field in every successful response to a POST request and
SHOULD provide it in error responses as well.
Paragraph (version A):
Every JWS sent by an ACME client MUST include, in its protected
header, the "nonce" header parameter, with contents as defined below.
As part of JWS verification, the ACME server MUST verify that the
value of the "nonce" header is a value that the server previously
provided in a Replay-Nonce header field.  Once a nonce value has
appeared in an ACME request, the server MUST consider it invalid, in
the same way as a value it had never issued.
Paragraph (version B):
An ACME server provides nonces to clients using the Replay-Nonce
header field, as specified in replay-nonce below.  The server MUST
include a Replay-Nonce header field in every successful response to a
POST request and SHOULD provide it in error responses as well.
Paragraph (version B):
Every JWS sent by an ACME client MUST include, in its protected
header, the "nonce" header parameter, with contents as defined in
nonce-nonce-jws-header-parameter below.  As part of JWS verification,
the ACME server MUST verify that the value of the "nonce" header is a
value that the server previously provided in a Replay-Nonce header
field.  Once a nonce value has appeared in an ACME request, the
server MUST consider it invalid, in the same way as a value it had
never issued.
Paragraph (version A):
The "authorizations" array in the challenge SHOULD reflect all
authorizations that the CA takes into account in deciding to issue,
even if some authorizations were fulfilled in earlier orders or in
pre-authorization transactions.  For example, if a CA allows multiple
orders to be fulfilled based on a single authorization transaction,
then it SHOULD reflect that authorization in all of the order.
Paragraph (version B):
The "authorizations" array in the challenge SHOULD reflect all
authorizations that the CA takes into account in deciding to issue,
even if some authorizations were fulfilled in earlier orders or in
pre-authorization transactions.  For example, if a CA allows multiple
orders to be fulfilled based on a single authorization transaction,
then it SHOULD reflect that authorization in all of the orders.
Paragraph (version A):
Validate the POST request belongs to a currently active account,
as described in Message Transport.
Paragraph (version B):
Validate the POST request belongs to a currently active account,
as described in message-transport.