Draft: draft-ietf-acme-acme

Commentary: The WG is presumably going to want to iterate on challenges as work on this spec progresses . In order to enable implementations of pre - RFC versions of the spec to smoothly upgrade , this PR introduces explicit versioning on challenge names . Each challenge name is now of the form " type - version " , where " type " is the general type of challenge ( HTTP , SNI , DNS , PoP ) , and " version " is the version of the draft that last changed the challenge . For example , the version of the HTTP challenge in this draft is " http-00 " . 
 This has a lot of other changes in it . I do n't know if you value editorial convenience , but the current approach is hard to maintain . In HTTP/2 , we had a version identifiers section up front of the document . That section explained that identifiers had the draft suffix appended and that the examples all omitted this suffix for convenience . This protocol is different because you see the identifiers all over and there are things like signatures that cover them . If you are OK with changing the identifers ( all of these should be changed to -01 any way ) , then you should be OK . I would add a preprocessing step , but that 's me . 
 Yeah , I see what you 're saying , but I think I prefer to be explicit here . There are more version identifiers hanging around . 
 In favour of adding numbering to the Challenges . do you prefer DVSNI or TLS SNI as a name ?
Paragraph (version A):
Different challenges allow the server to obtain proof of different
aspects of control over an identifier.  In some challenges, like
Simple HTTP and DVSNI, the client directly proves its ability to do
certain things related to the identifier.  In the Proof of Possession
challenge, the client proves historical control of the identifier, by
reference to a prior authorization transaction or certificate.
Paragraph (version B):
Different challenges allow the server to obtain proof of different
aspects of control over an identifier.  In some challenges, like HTTP
and TLS SNI, the client directly proves its ability to do certain
things related to the identifier.  In the Proof of Possession
challenge, the client proves historical control of the identifier, by
reference to a prior authorization transaction or certificate.
Paragraph (version A):
The Domain Validation with Server Name Indication (DVSNI) validation
method proves control over a domain name by requiring the client to
configure a TLS server referenced by an A/AAAA record under the
domain name to respond to specific connection attempts utilizing the
Server Name Indication extension RFC6066.  The server verifies the
client's challenge by accessing the reconfigured server and verifying
a particular challenge certificate is presented.
Paragraph (version B):
The TLS with Server Name Indication (TLS SNI) validation method
proves control over a domain name by requiring the client to
configure a TLS server referenced by an A/AAAA record under the
domain name to respond to specific connection attempts utilizing the
Server Name Indication extension RFC6066.  The server verifies the
client's challenge by accessing the reconfigured server and verifying
a particular challenge certificate is presented.
Paragraph (version A):
The response to the DVSNI challenge simply acknowledges that the
client is ready to fulfill this challenge.
Paragraph (version B):
The response to the TLS SNI challenge simply acknowledges that the
client is ready to fulfill this challenge.
Paragraph (version A):
Choose a subset of the N DVSNI iterations to check, according to
local policy.
Paragraph (version B):
Choose a subset of the N iterations to check, according to local
policy.
Paragraph (version A):
Simple HTTP: The value provided in the validation request is
signed by the account private key.
Paragraph (version A):
DVSNI: The validation TLS request uses the account key pair as the
server's key pair.
Paragraph (version B):
HTTP: The value provided in the validation request is signed by
the account private key.
Paragraph (version B):
TLS SNI: The validation TLS request uses the account key pair as
the server's key pair.
Paragraph (version A):
There are several ways that these assumptions can be violated, both
by misconfiguration and by attack.  For example, on a web server that
allows non-administrative users to write to .well-known, any user can
claim to own the server's hostname by responding to a Simple HTTP
challenge, and likewise for TLS configuration and DVSNI.
Paragraph (version B):
There are several ways that these assumptions can be violated, both
by misconfiguration and by attack.  For example, on a web server that
allows non-administrative users to write to .well-known, any user can
claim to own the server's hostname by responding to a Simple HTTP
challenge, and likewise for TLS configuration and TLS SNI.