On Fri, May 12, 2017 at 10:33:40PM +0000, Zach Shepherd wrote: > For use of a token with http-01, it seems like the relevant section of > the baseline requirements would be 3.2.2.4.6 Agreed‐Upon Change to > Website. Is that correct?
Yes, that is correct. > That section seems to explicitly state "where the Request Token or > Random Value MUST NOT appear in the request". Including the token > (which the document seems to refer to as the "Random Value") in the > request path (as http-01 does) would seem to violate this normative > language. Am I misunderstanding the content of that section? This was actually briefly discussed on this list. I had the same understanding, that was apparently mistaken. On changing validation methods, the current Key Authorization does not seem to be sufficient. It does not bind the name to be validated. Now, HTTP and DNS validation weakly binds the validated name (via host header and owner name, respectively). Even this weak binding is sufficient to consider the domain itself validated (the validation can be deputized). However TLS-SNI (including -02) does not bind the name in any way. This results in TLS-SNI failing to actually validate the domain name itself, instead validating the underlying IP address (it is not possible to deputized the validation). Furthermore, I have real problems matching up TLS-SNI-02 and method #10 (Section 3.2.2.4.10) validation. Reading the phrases in a way that would match seemingly unavoidably results other validation methods with the same phrases becoming very insecure. This is ignoring other problems with method #10 validation (e.g. seemingly allowing the PZB's insecure certificate chaining validation, due to seemingly not restricting random values properly). -Ilari _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
