My recollection is that there were a number of CA/B forum participants (including me) who asked repeatedly if method #10 could be expanded beyond a single sentence.
I don't remember anyone speaking up in opposition, just silence. I continue to support making sure that all of the validation methods have enough detail so that their security properties can be fully analyzed. Hopefully that would help avoid incidents like this in the future. -Tim > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > bounces+tim.hollebeek=digicert....@lists.mozilla.org] On Behalf Of J.C. Jones > via dev-security-policy > Sent: Thursday, January 18, 2018 3:34 PM > To: Matthew Hardeman <mharde...@gmail.com> > Cc: Doug Beattie <doug.beat...@globalsign.com>; mozilla-dev-security- > pol...@lists.mozilla.org; Alex Gaynor <agay...@mozilla.com> > Subject: Re: TLS-SNI-01 and compliance with BRs > > 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 > <mharde...@gmail.com> > wrote: > > > > > > > On Thu, Jan 18, 2018 at 4:14 PM, J.C. Jones via dev-security-policy < > > dev-security-policy@lists.mozilla.org> 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 > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
