The confidentiality point was a minor one, certainly, but it would represent an improvement.
TLS-SNI is a protocol already, but it's more complicated than it needs to be. Certificate generation is a pretty big lift compared to the other challenges. On Fri, Jan 12, 2018 at 2:29 PM, Jonathan Rudenberg <jonat...@titanous.com> wrote: > >> On Jan 11, 2018, at 22:26, Martin Thomson <martin.thom...@gmail.com> wrote: >> >> If you are using a new protocol, all of the concerns Peter have come >> into play. If you are there, why wouldn't you do the challenge >> validation within the new protocol rather than using the certificate >> (which is sent in the clear in current TLS versions). That might be >> easier to implement than generating the self-signed certificate… > > I don’t think an entirely new protocol makes sense. In order to do the > TLS/SNI/ALPN handshake a certificate is already sent in the ServerHello, so > there’s no reason not to use it to transport the authorization token. > Generating a self-signed certificate is trivial, and I’m not aware of any > relevant security concerns around fetching the authorization in the clear > (the dns-01 and http-01 challenge types are plaintext as well). _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
