On Monday, 1 May 2017 22:02:58 UTC+1, Lee wrote: > Maybe it's because I've worked with some incredibly bad auditors, but > the way I read the proposal, doing anything other than one of those > exact 10 methods is risking an audit failure.
> How would you word the policy to make it clear that while a CA is > required to use one of those 10 methods, the CA is also allowed to do > additional/stricter checks? I don't think it's necessary to spell out that a CA can do additional checks. The CA can also own a pizzeria, or teach all its employees to dance, and the policy rightly says nothing about that. On the other hand, whether other checks are "stricter" may be in the eye of the beholder. If they comply exactly with the relevant section of 3.2.2.4 then we know we're happy, otherwise who knows? Consider 3.2.2.4.6, a 112-bit random token chosen by a CA employee rolling a bunch of fair hexadecimal dice and writing down what they got is fine for passing 3.2.2.4.6. If a CA wishes to instead use UUIDs (assuming they have a good quality random number generator spitting out version 4 random UUIDs) that's fine too. Arguably implementing ACME http-01 validation is better, because that binds the validation to the applicant, closing a hole often found in validations today. But regardless of whether you think that's important, http-01 complies with 3.2.2.4.6 as well, aspects of 3.2.2.4.6 were actually modelled on it. On the other hand, maybe a CA comes up with something quite different, maybe they want to validate web sites by having a path famous-ca-name/validation.dll and they pass in an XML input which the remote server needs to process and respond to. What we do NOT want in this policy is to either make it Mozilla's job to examine every such new method and figure out if it's safe, or to just let the CA vouch for it as being "stricter" on their say so. Although we have occasionally caught CAs just straight up lying, much more often the problem is _incompetence_. The people running a CA are not experts on this stuff, so when they invent a new method there's a good chance it's flawed not because they intentionally designed in a weakness but because they lack the skills internally to identify a risk, and because they have no public review process by which others might spot it for them. So Ballot 169 (and this Mozilla policy) eliminate the problem by telling them not to roll their own. There will still probably be implementation flaws, that can't be entirely prevented, but I believe this (whether as Mozilla policy) or in the BRs represents a step firmly in the right direction. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
