Hi Ben,
Ben Bucksch wrote:
Actually, not even that is necessary. Classes each have their own root
cert, so we can simply match root certs to level in our software,
using a list that is just as hardcoded as our root certs, and matches
the assigned levels.
So your idea might be a good one, I'm afraid there are some problems
with this. Let me explain:
In this case, an extra effort would have to be invested into doing this.
This is something Gerv correctly prefers to avoid. Of course it could be
possible, provided there is enough manpower for it. But there is another
problem...
As you might know, the Mozilla CA policy encourages to use separate root
certificates *or* separate intermediate certificates under a single root
for the issuance of certificates (see
http://www.mozilla.org/projects/security/certs/policy/ section 13).
Personally I think, all CAs should use intermediate CA certificates for
the signing and leave the root certificate completely protected and
off-line!
But this also means, that the intermediate CA certificates are not
stored in the NSS certificate store and are changed/renewed rather
frequently compared to the CA root (In our case for example the
intermediate certificates have a life-time of 5 years and are changed
every four years (leaving the last year for validity of the already
issued certificates and for revocation). Therefore it would be difficult
to hard code anything here.
Now, the phrase "Class 3" or similar is not a defined standard and every
CA handles that differently - if at all. It would be very difficult to
fetch such a phrase on the fly and make the right assignment. This is
the reason why we came up with the OID stuff, since currently there is
no unified standard or policy anywhere (the core of the problem we are
trying to solve here?). The proposed OID could be added by the CA almost
over night and code implemented at the NSS library for its detection as
well in a short time.
More than that, there might be some CAs, which labeled their CA as
"Class 3", but issue "domain validated" or trial certificates from this
root. To make matters worse, some CAs issue all certificates from the
same root, for all kinds of verification levels. (Something which should
be discouraged strongly. The proposal will help with this.)
And at last, I indicated in a previous mail, that it would be most
likely healthier for Mozilla to let the CA make this assignments. In
this way, the responsibility remains with the CA and Mozilla doesn't
make this decision, instead of or for the CA. Legal advice could be
certainly helpful in order to support my logic here....
In fact, if I wanted to do that in Beonex, I could implement Eddy's
proposal plus UI all in JavaScript. I simply match the root cert name
or ID with a hardcoded list, and if it's VeriSign's Class 3 or
StartCom's Class 3, I show the realname and address in the UI, because
I know they check these properly, and otherwise I won't do anything
special. Just as example.
If the OID detections for the UI would be possible in Javascript I don't
know.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Phone: +1.213.341.0390
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
