Eddy Nigg (StartCom Ltd.) wrote:
This is a good question! Let me explain, because there is not *one*
answer to this...First of all, by assigning a certain level to a
certificate, the CA makes a promise, that the certificate in question
matches the relevant verification level of the Mozilla CA policy (I have
mentioned it previously).
Right. But if I promise you a pony, it doesn't mean you'll get one.
Since the definition of the various levels
will be strait forward and very clear about what they mean and which
verification have to be performed in order to assign a certain OID to
the certificate, there will be not much room to play for the CA.
Is this database good enough for a cross-check? What about that one over
there? This country has entirely different business registration rules.
That country treats companies as people, the other country doesn't.
There's a fine line to walk between strait-jacketing the CAs into a
single set of verification practices (which is unworkable, given country
variations) and having it so loose that there's leeway for cheating.
Writing such a standard is not easy.
For
example the Mozilla CA policy is very clear about its minimum
verification procedure and its a requirement. I view the proposal a
natural extension of this Mozilla CA policy.
It's very clear about some simple, baseline things like domain control
verification - and there aren't very many ways to do that. When you get
on to verifying organisation names and companies, things get much more
complicated.
But this discussion would be less abstract if you were to come up with a
more detailed proposal, that gave (for example) the definition of what
would be required for a Level 3 certificate.
Additionally by having the CA confirm and sign the Mozilla CA policy,
the CA is bound to it! No but and no when! Should a problem arise, all
parties involved can refer to the same definition, i.e. the Mozilla CA
policy.
So no-one in the real world ever has a dispute over a contract, because
they can just refer to the contract language to clear things up? :-)
No, because the CA validation practices will get audited against the
public documents on the cabforum.org website. So Ernst and Young, KPMG
and friends are the policemen.
>
So I have some objections about your statement above, in that respect
they are also the policemen of any other policy they audited, which
means, that there is a similarity at least. However I don't view them as
policemen's at all, it's not their job.
It is. Auditors make sure you are doing something you have committed to
do. That is their job. And that's exactly what we want.
If the motives of the CA are solely to be completely honest about it,
yes. But given that they can make more money if they can pass less
validated certs off as more validated certs, there's a big incentive
to say "well, this set of practices corresponds to level 3" when in
fact we might think it corresponds to level 2.
>
In such a case, a CA would have to live up to their claim! I suspect,
that a CA wouldn't take on a higher level, because of the promise
involved. First of all, should a problem arise, the CA would be
responsible up to the level it assigned the certificate.
In what way would they be responsible? Does your proposal include
liability? If so, how much, and under what circumstances?
The certificates in questions are most likely domain validated.
Nope. Organisationally validated. Check the certificate contents, and
match them up with the relevant CA's products.
OK, now this is actually a very good case for our proposal! First of all
I'd like to point out, that the certificate signed by XRamp might be a
domain validated only certificate - I couldn't figure it out (Another
good reason why we need the levels).
I'm told it's OV; if you can show differently, that would be interesting.
However the second certificate was
issued by Comodo Class 3 and in common practice at CAs would have to be
a fully verified certificate (similar to EV, i.e. Class/Level 3).
Obviously this is not the case here, which is why we *need* to have our
proposal implemented!
How would your proposal prevent this happening?
No-one lied to get that certificate. The company named in it really
exists. To reduce the incidence of confusing O fields, you need a
standard for exactly what can be put in it. Like, er, the one EV has.
In case of the Comodo certificate, they couldn't have marked it as Level
3 (as the issuer certificate might indicate) and if they'd have done
that nevertheless, it would have been a breach of contract (That between
Mozilla and the CA).
Why, exactly? What did they not do that they should have?
Domain validated certificates have the domain name in the O field, not
a name like this.
Not really. Some CAs issue certificates including personal name and/or
organization name in the organization field, respectively the common
name field for client certificates. However usually they are also marked
with "Persona not validated" or similar and are signed from a Class 1
issuer.
Do you have an example of a DV SSL cert which has something other than a
domain in the O field?
but I say that it's unavoidable without documented and
third-party-audited standards so we can meaningfully discriminate.
Having the Mozilla project find resources to do our own audit is just
out of the question.
Right! But Mozilla can provide the foundation and framework for having
certificates marked correctly. The Mozilla CA policy can be the
definition (Call is standard if you want). The CAs get audited as before
and the subscribers and relying parties (i.e. the public) are the people
making the judgment (with the help of a good UI). When thousands of
people are able to know about a certificate a lot more than today - with
a clear definition in place - no CA will dare to cheat.
I just don't see that world ever happening. Most of the planet has far
better things to do than learn about certificates and CAs.
BTW, perhaps you might ask the CAB forum, why they didn't think about
such a plan like our proposal. Why should 99% of the SSL certificates
remain unclassified and broken in the browsers? Shouldn't have this
specific forum come up with a solution for all certificates?
Because they agreed with me that there was no possibility of imposing
standardisation on the existing product set.
Gerv
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
