Draft: draft-ietf-acme-acme

Commentary: Note : There is one " should " -"SHOULD " here , but I do n't think that 's substantive enough to hold up the PR .
Paragraph (version A):
Receive CA-provided 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 B):
Receive a CA-provided 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):
ACME allows a client to request certificate management actions using
a set of JavaScript Object Notation (JSON) messages carried over
HTTPS.
Issuance using ACME resembles a traditional CA's issuance process, 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.  Issuance using ACME resembles a traditional CA's issuance
process, in which a user creates an account, requests a certificate,
and proves control of the domain(s) in that certificate in order for
the CA to sign the requested certificate.
Paragraph (version A):
If the server wishes to present the client with terms under which the
ACME service is to be used, it MUST indicate the URL where such terms
can be accessed in the "termsOfService" subfield of the "meta" field
in the directory object, and the server MUST reject new-account
requests that do not have the "termsOfServiceAgreed" set to "true".
Clients SHOULD NOT automatically agree to terms by default.  Rather,
they SHOULD require some user interaction for agreement to terms.
Paragraph (version B):
If the server wishes to present the client with terms under which the
ACME service is to be used, it MUST indicate the URL where such terms
can be accessed in the "termsOfService" subfield of the "meta" field
in the directory object, and the server MUST reject new-account
requests that do not have the "termsOfServiceAgreed" field set to
"true".  Clients SHOULD NOT automatically agree to terms by default.
Rather, they SHOULD require some user interaction for agreement to
terms.
Paragraph (version A):
Servers SHOULD NOT respond to GET requests for account resources as
these requests are not authenticated.  If a client wishes to query
the server for information about its account (e.g., to examine the
"contact" or "certificates" fields), then it SHOULD do so by sending
a POST request with an empty update.  That is, it should send a JWS
whose payload is an empty object ({}).
Paragraph (version B):
Servers SHOULD NOT respond to GET requests for account resources as
these requests are not authenticated.  If a client wishes to query
the server for information about its account (e.g., to examine the
"contact" or "orders" fields), then it SHOULD do so by sending a POST
request with an empty update.  That is, it should send a JWS whose
payload is an empty object ({}).
Paragraph (version A):
The URL for account being modified.  The content of this field
MUST be the exact string provided in the Location header field in
response to the new-account request that created the account.
Paragraph (version B):
The URL for the account being modified.  The content of this field
MUST be the exact string provided in the Location header field in
response to the new-account request that created the account.
Paragraph (version B):
Check that the "account" field of the key-change object contains
the URL for the account matching the old key.
Paragraph (version B):
The requested value of the notBefore field in the certificate, in
the date format defined in RFC3339.
Paragraph (version B):
The requested value of the notAfter field in the certificate, in
the date format defined in RFC3339.
Paragraph (version A):
If the server is willing to proceed, it builds a pending
authorization object from the inputs submitted by the client.
Paragraph (version A):
When evaluating a request for an assignment in this registry, the
designated expert should ensure that the method being registered has
a clear, interoperable definition and does not overlap with existing
validation methods.  That is, it should not be possible for a client
and server to follow take the same set of actions to fulfill two
different validation methods.
Paragraph (version B):
When evaluating a request for an assignment in this registry, the
designated expert should ensure that the method being registered has
a clear, interoperable definition and does not overlap with existing
validation methods.  That is, it should not be possible for a client
and server to follow the same set of actions to fulfill two different
validation methods.
Paragraph (version A):
When processing an file of type "application/pem-certificate-chain",
a client SHOULD verify that the file contains only encoded
certificates.  If anything other than a certificate is found (i.e.,
if the string "---BEGIN" is ever followed by anything other than
"CERTIFICATE"), then the client MUST reject the file as invalid.
Paragraph (version B):
When processing an file of type "application/pem-certificate-chain",
a client SHOULD verify that the file contains only encoded
certificates.  If anything other than a certificate is found (i.e.,
if the string "-----BEGIN" is ever followed by anything other than
"CERTIFICATE"), then the client MUST reject the file as invalid.