On Thu, Jan 11, 2018 at 09:46:28PM -0600, Matthew D. Hardeman wrote: > > In order to actually be an improvement in security, the ALPN needs > to be more than a mere marker of support. > > Consider: The new mechanism is implemented and Let’s Encrypt > deploys. > > Rather than do the work to ALSO fix the insecure aspects of the > infrastructure, they’ll hastily patch in the “acme" name. > > To add security, perhaps the SNI that is sent should be the actual > domain label that is being validated, along with the “acme” ALPN > name. At this point, an actual ALPN extension should negotiate the > authentication, with the server having the opportunity to bind the > proper target name to a desired authentication and then if and > only if the server has available the account key credentials of the > requestor, would it be able to answer with a proper authentication. > > Just adding a marker with the hammer being that just doing this > without implementing the promises that are supposed to be implied > on pain of violating an RFC is… Likely to get laughed at in a > derisive way by the very web hosts whose behavior now has you > contemplating improvements to the protocol. > > There’s no fast way out of this mess.
The mechanism is presumably bound by "method 10" from current CABForum BRs. The language in the BRs is (paraphrased): 'A random value in a certificate on the name being validated'. So the certificate must contain both the name being validated and the random value. That certificate may be either X.509 certificate (which are apparently a bit nontrivial to generate, I personally don't think it is that bad) or some other format of certificate. However, if one is to keep with cryptographically kosher practices, there are the following constraints: - The account key can not sign X.509 certificate, or any other certificate with format not based on JWS. - The account key can not directly sign TLS key exchange. Also, another certificate format would require a new TLS certificate format. Codepoint assignment needs an RFC, but in practice, those would likely be annoying to implement. Then there are the following implementation constraints: - The key used to sign the TLS key exchange must appear the certificate. -Ilari _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
