Draft: draft-ietf-acme-acme

Commentary: Simplify the TLS SNI challenge by removing the iterations concept , which I believe is not necessary in practice and complicates the protocol needlessly . 
 Implementing TLS SNI is currently really complicated , yes . 
 FYI , implements protocol according to the contents of this PR - i.e. without iterations . 
 ( so does current  ) 
 I think this will be OK to land once lands . We should consider whether we want to bump the version number in the challenge . Principle would dictate that we should , since this breaks compatibility with what was published in -01 . But since I 'm not aware of any implementation of " tls - sni-01 " as specified in  ( vs. the off - spec implementation in boulder ) , I 'm inclined to just leave it . 
 FWIW on the client side of things , xenolf / lego did not implement the iterations for the tls - sni-01 challenge . 
 implements iterations but takes the absence of an " n " parameter to be equivalent to an " n " parameter of 1 , which is compatible . 
 Great , I 'm taking this as sufficient evidence that a version bump is not needed :)
Paragraph (version A):
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 B):
A client responds to this challenge by constructing a key
authorization from the "token" value provided in the challenge and
the client's account key.  The client computes the SHA-256 digest Z
of the UTF8-encoded key authorization, and encodes Z in UTF-8 lower-
case hexadecimal form.
Paragraph (version B):
The client generates a self-signed certificate for with a single
subjectAlternativeName extension dNSName that is
"<Z[0:32]>.<Z[32:64]>.acme.invalid", where "Z[0:32]" and "Z[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 "<Z[0:32]>.<Z[32:64]>.acme.invalid", the corresponding generated
certificate is presented.
Paragraph (version A):
Given a Challenge/Response pair, the ACME server verifies the
client's control of the domain by verifying that the TLS server was
configured appropriately.
Paragraph (version A):
Choose a subset of the N iterations to check, according to local
policy.
Paragraph (version A):
For each iteration, compute the Zi-value from the key
authorization in the same way as the client.
Paragraph (version A):
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):
Compute the Z-value from the key authorization 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
"<Z[0:32]>.<Z[32:64]>.acme.invalid" in the SNI field (where the
comparison is case-insensitive).