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 then we 
know we're happy, otherwise who knows?

Consider, 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 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 as well, aspects of 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

Reply via email to