Draft: draft-ietf-acme-acme

Commentary: Several comprehensibility improvements to the first three sections of the draft RFC . For clarity about the contents of this pull request , please consider using the option ( git CLI ) or the " rich diff " option ( GitHub web interface ) to evaluate it , in preference to a traditional line - based diff . 
 - I think these changes are valuable . Thank you ! I do n't personally have any qualms / feedback having read through the diff but it would help get more eyes on this if you emailed the ACME mailing list with a brief mention of your PR ( even though it 's strictly editorial I think more folks monitor the list than the Github repo ) . 
 LGTM . 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(s).
Paragraph (version B):
The guiding use case for ACME is obtaining certificates for Web sites
(HTTPS RFC2818).  In this case, the user's web server is intended to
speak for one or more domains, and the process of certificate
issuance is intended to verify that this server actually speaks for
the domain(s).
Paragraph (version A):
The overall idea is that it's nearly as easy to deploy with a CA-
issued certificate as a self-signed certificate, and that once the
operator has done so, the process is self-sustaining with minimal
manual intervention.  Close integration of ACME with HTTPS servers,
for example, can allow the immediate and automated deployment of
certificates as they are issued, optionally sparing the human
administrator from additional configuration work.
Paragraph (version B):
In this way, it would be nearly as easy to deploy with a CA-issued
certificate as with a self-signed certificate.  Furthermore, the
maintenance of that CA-issued certificate would require minimal
manual intervention.  Such close integration of ACME with HTTPS
servers would allow the immediate and automated deployment of
certificates as they are issued, sparing the human administrator from
much of the time-consuming work described in the previous section.
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
protocols 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.