Draft: draft-ietf-acme-acme

Commentary: Addresses    TSV - ART review 
 Merging based on review 
 On the mailing list ,     pointed out these issues : Section 7.3.5 , first paragraph , second line : A " bind " word is missing between the words " to " and " an " Section 7.4.1 , second paragraph , second sentence : " case " should be " cases " . When the server builds the authorization object , the document is stating that the response would include " challenges " and " combinations " . Remove the " combinations " as it is not being used . Section 7.5.1 , the Request URIs in the examples : Should not this be /acme / authz/1234/0 ? 
 In " Responding to challenges , " we use the term " response fields . " These fields are defined by each challenge type , but are not described as " response fields " there . We should add a heading describing them as such in the challenge type definitions . 
 The other challenges do n't expect you to post a payload containing a type field , so it 's inconsistent for OOB-01 to do so . It should just take an empty object " { } " as its payload . 
 This seems fine . It seems to be protected from replay by the and parameters . I think we 're OK leaving the challenge name at " oob-01 " , since this is n't a breaking change .
Paragraph (version A):
DISCLAIMER: This is a work in progress draft of ACME and has not yet
had a thorough security analysis.
Paragraph (version A):
The server MAY require a value to be present for the "external-
account-binding" field.  This can be used to an ACME account with an
existing account in a non-ACME system, such as a CA customer
database.
Paragraph (version B):
The server MAY require a value to be present for the "external-
account-binding" field.  This can be used to associate an ACME
account with an existing account in a non-ACME system, such as a CA
customer database.
Paragraph (version A):
In some cases, a CA running an ACME server might have a completely
external, non-ACME process for authorizing a client to issue for an
identifier.  In these case, the CA should provision its ACME server
with authorization objects corresponding to these authorizations and
reflect them as already valid in any orders submitted by the client.
Paragraph (version B):
In some cases, a CA running an ACME server might have a completely
external, non-ACME process for authorizing a client to issue for an
identifier.  In these cases, the CA should provision its ACME server
with authorization objects corresponding to these authorizations and
reflect them as already valid in any orders submitted by the client.
Paragraph (version A):
The client sends these updates back to the server in the form of a
JSON object with the response fields required by the challenge type,
carried in a POST request to the challenge URL (not authorization
URL) once it is ready for the server to attempt validation.
Paragraph (version A):
The server updates the authorization document by updating its
representation of the challenge with the response fields provided by
the client.  The server MUST ignore any fields in the response object
that are not specified as response fields for this type of challenge.
The server provides a 200 (OK) response with the updated challenge
object as its body.
Paragraph (version B):
The client sends these updates back to the server in the form of a
JSON object with contents as specified by the challenge type, carried
in a POST request to the challenge URL (not authorization URL) once
it is ready for the server to attempt validation.
Paragraph (version B):
The server updates the authorization document by updating its
representation of the challenge with the response object provided by
the client.  The server MUST ignore any fields in the response object
that are not specified as response fields for this type of challenge.
The server provides a 200 (OK) response with the updated challenge
object as its body.
Paragraph (version A):
Clients SHOULD NOT respond to challenges until they believe that the
server's queries will succeed.  If a server's initial validation
query fails, the server SHOULD retry the query after some time.
While the server is still trying, the status of the challenge remains
"pending"; it is only marked "invalid" once the server has given up.
Paragraph (version B):
Clients SHOULD NOT respond to challenges until they believe that the
server's queries will succeed.  If a server's initial validation
query fails, the server SHOULD retry the query after some time, in
order to account for delay in setting up responses such as DNS
records or HTTP resources.  The precise retry schedule is up to the
server, but server operators should keep in mind the operational
scenarios that the schedule is trying to accommodate.  Given that
retries are intended to address things like propagation delays in
HTTP or DNS provisioning, there should not usually be any reason to
retry more often than every 5 or 10 seconds.  While the server is
still trying, the status of the challenge remains "pending"; it is
only marked "invalid" once the server has given up.
Paragraph (version A):
A client responds to this challenge by presenting the indicated URL
for a human user to navigate to.  If the user chooses to complete
this challenge (by visiting the website and completing its
instructions), the client indicates this by sending a simple
acknowledgement response to the server.
Paragraph (version B):
A client responds to this challenge by presenting the indicated URL
for a human user to navigate to.  If the user chooses to complete
this challenge (by visiting the website and completing its
instructions), the client indicates this by sending a simple
acknowledgement response to the server.  The payload of this response
is an empty JSON object ("{}", or "e30" base64url-encoded).