Draft: draft-ietf-acme-acme

Commentary: On the mailing list , and pointed out some risks arising from the default virtual host behavior of some web servers . This PR integrates the changes they suggest , namely ( 1 ) removing the " tls " option from the challenge , and ( 2 ) adding iterations to the challenge . This PR is based on top of and . 
 Sorry , feel free to tell me to go away , but reading the backing decision to drop HTTPS for SimpleHTTP does n't make sense to me . If I understand everything correctly , you control the originator of the HTTPS requests and the requests are always sent to domains . So why ca n't you just enforce to always send the Host header and this would n't be an issue ? 
 From : behaviour that if a default TLS / HTTPS virtual host is not configured explicitly , one will be selected based on the ordering of vhosts in the webserver configuration ( in practice , this often amounts to alphabetical ordering of files in a configuration directory ) . As far as I know Apache does the exact same thing for nonencrypted HTTP hosts ( this is also acknowledged by a later mail in the thread ) , so the reasoning is a little weird . I suppose the idea is that hosters are more likely to have HTTP configured correctly rather than HTTPS ? 
 The section on the " " registry says that " Fields marked as " client configurable " may be included in a new - account request " . This seems like a copy - paste - o , and perhaps should say that such fields may be included in a new - order request . 
 Good catch . I opened to fix . Thanks !
Paragraph (version A):
As a domain may resolve to multiple IPv4 and IPv6 addresses, the
server will connect to at least one of the hosts found in A and AAAA
records, at its discretion.  The HTTP server may be made available
over either HTTPS or unencrypted HTTP; the client tells the server in
its response which to check.
Paragraph (version B):
As a domain may resolve to multiple IPv4 and IPv6 addresses, the
server will connect to at least one of the hosts found in A and AAAA
records, at its discretion.  Because many webservers allocate a
default HTTPS virtual host to a particular low-privilege tenant user
in a subtle and non-intuitive manner, the challenge must be completed
over HTTP, not HTTPS.
Paragraph (version A):
If this attribute is present and set to "false", the server will
perform its validation check over unencrypted HTTP (on port 80)
rather than over HTTPS.  Otherwise the check will be done over
HTTPS, on port 443.
Paragraph (version A):
Form a URI by populating the URI template RFC6570
"{scheme}://{domain}/.well-known/acme-challenge/{token}", where: *
the scheme field is set to "http" if the "tls" field in the
response is present and set to false, and "https" otherwise; * the
domain field is set to the domain name being verified; and * the
token field is set to the token in the authorized key object.
Paragraph (version B):
Form a URI by populating the URI template RFC6570
"http://{domain}/.well-known/acme-challenge/{token}", where: * the
domain field is set to the domain name being verified; and * the
token field is set to the token in the authorized key object.
Paragraph (version A):
In response to the challenge, the client MUST parse the authorized
key object and verify that its "key" field contains the client's
account key.  The client then computes the SHA-256 digest Z of the
JSON-encoded authorized key object (without base64-encoding), and
encodes Z in hexadecimal form.
Paragraph (version A):
The client will generate a self-signed certificate with the
subjectAlternativeName extension containing the dNSName
"<Z[0:32]>.<Z[32:64]>.acme.invalid".  The client will then configure
the TLS server at the domain such that when a handshake is initiated
with the Server Name Indication extension set to
"<Z[0:32]>.<Z[32:64]>.acme.invalid", the generated test certificate
is presented.
Paragraph (version B):
The client generates a self-signed certificate for each iteration of
Zi with a single subjectAlternativeName extension dNSName that is
"<Zi[0:32]>.<Zi[32:64]>.acme.invalid", where "Zi[0:32]" and
"Zi[32:64]" represent the first 32 and last 32 characters of the hex-
encoded value, respectively (following the notation used in Python).
The client then configures the TLS server at the domain such that
when a handshake is initiated with the Server Name Indication
extension set to "<Zi[0:32]>.<Zi[32:64]>.acme.invalid", the
corresponding generated certificate is presented.
Paragraph (version A):
Compute the Z-value from the authorized key object in the same way
as the client.
Paragraph (version A):
Open a TLS connection to the domain name being validated on port
443, presenting the value "<Z[0:32]>.<Z[32:64]>.acme.invalid" in
the SNI field (where the comparison is case-insensitive).
Paragraph (version A):
Verify that the certificate contains a subjectAltName extension
with the dNSName of "<Z[0:32]>.<Z[32:64]>.acme.invalid".
Paragraph (version B):
Choose a subset of the N DVSNI iterations to check, according to
local policy.
Paragraph (version B):
For each iteration, compute the Zi-value from the authorized keys
object in the same way as the client.
Paragraph (version B):
Open a TLS connection to the domain name being validated on the
requested port, presenting the value
"<Zi[0:32]>.<Zi[32:64]>.acme.invalid" in the SNI field (where the
comparison is case-insensitive).
Paragraph (version B):
Verify that the certificate contains a subjectAltName extension
with the dNSName of "<Z[0:32]>.<Z[32:64]>.acme.invalid", and that
no other dNSName entries of the form "*.acme.invalid" are present
in the subjectAltName extension.