Yes, I agree it's odd that the validation request is based on the key authorization not the token. That's really the crux of the issue and more succinct than my original message.
In option 1) I proposed, to be clear it would make sense to update tls-sni-01 validation to use Z(token) as the SNI hostname, and use two entries in the DNSName cert response. One matching the SNI hostname based on Z(token) so the right cert is chosen, and one based on Z(key authorization) that serves as the secret. As you mentioned a new `tls-01` could depend on just the request/response like `http-01` and not depend on details of the cert so that you don't have to mess with configurations of both cert & request handling as much. -- Jehiah On Thu, Jan 21, 2016 at 11:09 PM, Martin Thomson <[email protected]> wrote: > Thinking more about this, if the intent is to make the tls-sni-xx > challenge analogous to the http-xx one, then the request would encode > the token (not a hash of the key authorization) and the response to > that challenge would include the key authorization (as I suggest > below). > > On 22 January 2016 at 14:03, Martin Thomson <[email protected]> wrote: >> On 22 January 2016 at 13:38, Jehiah Czebotar <[email protected]> wrote: >>> 1) Change the requirement that the self signed cert have one DNSName, >>> and require the response to have TWO DNS names. One that matches the >>> requested hostname, and a second that is secret which proves it can >>> only be created by the appropriate party initiating validation >>> 2) Remove reliance on SNI matching, and make the challenge `tls-01` >>> and fulfill the same HTTP response requirements as `http-01` where the >>> Hostname, and request path are untrusted, but the response body with >>> full keyAuthorization proves the connection to the requestor. This >>> opens up the possibility of TLS validation against the $domain being >>> validated instead of relying on a .acme.invalid hostname. >> >> I think that the suggestion that the challenge response include >> something unique to the challenge (as http-01 already does) is a fine >> suggestion. I don't think that it matters much how that is done. If >> the intent is to verify that the requester exercises control over the >> TLS server, having this restricted to things that are part of the TLS >> server configuration is probably advisable. >> >> To that end, adding a key authorization to the certificate would seem >> to be the best option. Whether that is done as a second >> subjectAltName or as a separate extension probably doesn't matter >> much. >> >> Following through with a challenge like http-01 would work, but it >> means playing with the configuration of the server in two places. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
