That would be the right place. At the time there was not universal desire for these validation mechanisms to be what I'd call 'fully specified'; the point of having them written this way was to leave room for individuality in meeting the requirements.
Of course, having a few carefully-specified-and-validated mechanisms instead of individuality has worked rather well for other security-critical operations, like the very transport security this whole infrastructure exists to support. Perhaps that argument could be re-opened. J.C. On Thu, Jan 18, 2018 at 3:25 PM, Matthew Hardeman <[email protected]> wrote: > > > On Thu, Jan 18, 2018 at 4:14 PM, J.C. Jones via dev-security-policy < > [email protected]> wrote: > >> As one of the authors of 3.2.2.4.10, Alex's logic is exactly how we walked >> through it in the Validation Working Group. The ADN lookup is DNS, and >> what >> you find when you connect there via TLS, within the certificate, should be >> the random value (somewhere). 3.2.2.4.10 was written to permit ACME's >> TLS-SNI-01 while being generic enough to permit CAs to accomplish the same >> general validation structure without following the ACME-specified >> algorithm. >> >> J.C. > > > I would presume that the CABforum would be the place to explore further > details, but it seems that the specifications for the #10 method should be > reexamined as to what assurances they actually provide with a view to > revising those specifications. At least 1 CA so far has found that the > real world experience of a (presumably) compliant application of method #10 > as it exists today was deficient in mitigating the provision of > certificates to incorrect/unauthorized parties. > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
