> TLS-ALPN addresses the latter problem by requiring the server_name to match > the validation target (which is AFACIT also required by the Baseline > Requirements). This stops claiming arbitary names from allowing > misvalidations.
This was certainly the intent. Never in over two years of some pretty detailed discussions about the mechanics of validation did anyone ever propose it was reasonable to validate domain name A by contacting the web server for a name that is not A (except for the approved the _prefix stuff). I realize that after it was pointed out that TLS-SNI was horribly broken in this regard, there were attempts by some to retroactively claim that such behavior was compliant, but I always found those explanations a bit tortured and unconvincing. Certainly if I a large commercial CA had made them, they would have been laughed at and ridiculed. I would actually love to work with some people on updating the CABF method 10 validation requirements in order to properly express the security requirements that ALPN-01 satisfies. The whole TLS-SNI experience showed that Method 10 does not have sufficiently rigorous requirements to guarantee it actually validates what it claims to validate. Since the CABF VWG is currently working on adding more security rigor to all the approved validation methods, it would be a great time to fix up Method 10. ALPN-01 is a much better validation method, and I'm very thankful to all the people who worked hard to come up with a replacement, which as far as I can tell from looking at it briefly (I wish I had more time) looks pretty secure and robust. -Tim
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
