So the disagreement is whether the it is sufficient to merely use the name for the
DNS lookup, and then accept whatever happens afterwards, or whether the intent was that the web page should be retrieved in much the same way as it is retrieved by browsers. Matching them as closely as possible makes the validation more reliable. Unfortunately, historically, the requirements are underspecified, and there is freedom to implement the validation mechanism badly. There are improvements that were discussed in the excellent discussion in Virginia, but even today, we aren’t there yet. So yes, it is possible by using a very strict, technical reading, an argument can be made that TLS-SNI is compliant. I’m just not a fan of that argument. When the BRs say “retrieve a […] web page”, I believe that includes a responsibility to interpret that provision in a way that meets the intent of the validation method, and doesn’t introduce security risks. -Tim On Thu, Jun 21, 2018 at 8:40 AM, Tim Hollebeek <tim.holleb...@digicert.com <mailto:tim.holleb...@digicert.com> > wrote: > 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). That's not what is done under TLS-SNI.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
