Duane, I will respond to fragments of what you wrote:
Is it a safe assumption to make
no. :)
that [...] the class system is mostly informational
Today, each CA defines its own classes.
and that it is slightly standardised,
It doesn't seem standardized at all.
IIRC, the first CA to have "classes" was Verisign. I think some other CAs have followed Verisign's lead in the definition of classes, and have defined their own classes based loosely on Verisign's definitions. But I wouldn't say that makes any of the class definitions standardized.
If I'm mistaken, and there is some body of work from some standards body that is attempting to standardize classes, someone please enlighten me.
or worst case someone could make a judgement to sanitise the CAs slightly based on their own CPS.
That's the sticky wicket. Making a judgement. You'll recall it was the prospect of mozilla having to make judgements about CAs that got us all down this long CA policy path in the first place.
If I may attempt to summarize where that got us, mozilla got out of the judgement business. It now relies on "qualified" and "independent" third parties to make those judgements, based on any of a growing number :( of sets of possible criteria for judgement.
Also, an important part of Mozilla's present policy is that it is based in some large measure on what the CA says its own policies are. The third parties exist only to confirm that it honors its own stated policies.
I do realise this would require a fair bit of work for someone, or maybe hassle the CAs for the information and their own sanitising otherwise they get set to class one equivalency until they do provide the information to the contrary.
I think we'd have to do something similar to what we've done with the rest of the policy issues. Perhaps mozilla's cert policy could require the CAs to make some sort of self-identification of the "classes" of assurance employed for each of their CA certs, and require that the evaluators assess those claims.
Perhaps instead of using the existing class system and confusing things more come up with a different naming scheme, like IDVL (IDentity Verification Level), so this strictly relates to how well or how poorly each CA does verification checking on each type of certificate issued under what root certificate.
No verification = IDVL 0
email only verification = IDVL 1
faxed in verification (photo copied ID etc) = IDVL 2
web of trust like CAcert runs with in person meetings and formalised documentation and policies = IDVL 3
public notary and original documents sent in or meet in person at the CA office = IDVL 4
police ID check = IDVL 5
government/military background checking via police and other sources = IDVL 6
That's an interesting list. Here are a few observations about it.
1. It seems to deal only with verification of personal identity (e.g. personal name), and not with organizational relationships. If a person wanted a cert that include "O=Mozilla Foundation", how would you verify that the person is indeed affiliated with that organization? A similar question applies to DNSnames in SSL server certs. The binding of personal names/identities to organizational ones seems particularly challenging to do well, as Juarj Bednar pointed out.
2. I think the idea of "police ID check" doesn't work in all nations. In the US, where we don't (yet) have national ID cards, the closest thing we have to ubiquitous ID is our drivers' licenses. The police do not issue drivers' licenses, and the police are not considered authoritative with respect to the accuracy of the DLs.
Yes. I very much wish we could get the UI czars for FF/TB engaged in the discussions in n.p.m.security, but I'm not optimistic.
Ignoring the main interface, how hard/easy would it be to do something like this as a plug-in instead? [snip]
If the main developers don't want to do it surely there is someone that can?
Seems plausible. Maybe the creators of trustbar? Maybe we should be trying to recruit them to join the ranks of the "main developers" (as you called them).
-- Nelson B _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
