Gerv, thank you for the useful objections in this mail! Seriously - I
mean it! You've touched a few points (some of it was already discussed,
but never mind), which require either a good answer or some improvement...
Gervase Markham wrote:
You misunderstand my concern - I apologise for not explaining better.
Let me try again.
Why will they "have to" mark their certificates as corresponding to
the level which matches its policy, rather than marking them at a
higher level? What happens if the CA and the browser vendor disagree
about what level a particular type of certificate should be?
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). 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. 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.
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.
Will you be a policeman with EV?
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.
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. Second I
believe that the public might complain at some point as well.
I don't think that any existing practices are as strong as EV. (I'd be
interested if you could prove me wrong by pointing me to a public
document detailing validation practices, in use by a CA today, which
is as strong or stronger).
OK, time allowing, I'll dig up something...
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). 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!
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). Now this is indeed serious stuff, because the cert
in question is misleading to say the least. We need to be able to
differentiate between this claims first of all. CA adherence to the
Mozilla policy would be the second step after that.
(Again EV will not solve this problem and I'm really sorry about the way
EV is handled today and the direction they took. They should have come
up with the proposal we made, not us...Seeing these facts about the
various certificates you pointed out, I really question myself now even
more, what's the use...But hey, Comodo and XRamp are members of this
very club, can we expect anything better than that? Their practice is
more than questionable, which doesn't really gives anybody of us a
better feeling towards the CAB forum either.)
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.
I agree it is not good to lump everything into one category,
Good!
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. Should it
happen nevertheless, Mozilla must have a clear definition what it is
going to do in such a case. This should be an effective and binding policy.
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?
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Phone: +1.213.341.0390
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
