On Thu, Jun 21, 2018 at 1:40 PM, Tim Hollebeek <[email protected]> wrote:
> 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. > I think TLS-ALPN documents why this is true, but we know multiple CAs that implemented either TLS-SNI or alternatives viewed it the same at the time. I am greatly appreciative of hindsight being 20/20, but I think it's important to recall that it is hindsight. As part of the introduction of 3.2.2.4.10, CAs were actively discussing about how this avoids the need to do such matches, and the CA/Browser Forum Validation WG acknowledged it as a correct interpretation. This is not about strict interpretations - this is about documented and uncontested discussion in the Validation WG. However, as to the remainder of the message, it seems we're echoing each other - that a well-specified TLS-ALPN that concretely documents the processing mode is of great benefit to the community, both in terms of client implementers knowing what edge cases to expect that may cause an ACME server to reject their response, and ACME servers to consider in implementing when considering the validation level of the client's request. My hope, then, is that any energy that might be directed at trying to duplicate this work in 3.2.2.4.10 in the CA/Browser Forum might otherwise be more productively and holistically directed at this effort within the IETF and TLS-ALPN, allowing both broader participation and review, and resulting in a state such that 3.2.2.4.10 can simply be replaced, wholesale, with a statement "Using TLS-ALPN as specified is acceptable". > 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 > > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
