On Wed, Jan 10, 2018 at 5:53 PM, Matthew Hardeman <mharde...@gmail.com> wrote:
> For comparison of "What could be worse", you could imagine a CA using the >> .10 method to assert the Random Value (which, unlike .7, is not bounded in >> its validity) is expressed via the serial number. In this case, a CA could >> validate a request and issue a certificate. Then, every 3 years (or 2 years >> starting later this year), connect to the host, see that it's serving their >> previously issued certificate, assert that the "Serial Number" constitutes >> the Random Value, and perform no other authorization checks beyond that. In >> a sense, fully removing any reasonable assertion that the domain holder has >> authorized (by proof of acceptance) the issuance. >> > > That, indeed, is a chilling picture. I'd like to think the community's > response to any such stretch of the rules would be along the lines of "Of > course, you're entirely correct. Technically this was permitted. Oh, by > the way, we're pulling your roots, we've decided you're too clever to be > trusted." > GlobalSign proposed this as a new method - https://cabforum.org/pipermail/validation/2017-May/000553.html Amazon pointed out that .10 already permitted this - https://cabforum.org/pipermail/validation/2017-May/000557.html Your reaction means you must be one of the "worrywarts who treat certificate owners like criminals" though, in the words of Steve Medin of Symantec/Digicert - https://cabforum.org/pipermail/validation/2017-May/000554.html , who was also excited because of the 'brand stickiness' it would create (the term typically used to refer to the likelihood or difficulty for someone to switch to another, potentially more competent CA - in this case, due to the ease of the lower security) _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
