Nelson Bolyard wrote:
I think we (er, MF) *could*, if MF was willing to require, in its CA cert policy, that CAs for SSL and Code Signing must use a specified minimum level of authentication in the issuance of those certs. But presently, it seems the policy is willing to give any WebTrust-attested CA whatever trust bits they request. So, at the moment, no, I cannot say it is still the case.
To kill 2 birds with one stone I'll respond to Julian's posting as well...
Is it a safe assumption to make that generally while the class system is mostly informational and that it is slightly standardised, or worst case someone could make a judgement to sanitise the CAs slightly based on their own CPS. 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.
Nelson, I'm guessing you'd be a good person to make lines in the sand as to what is and what isn't acceptable, for example.
Perhaps the current class system isn't granular enough, and we need to have classes 0 to 10, to better describe how much trust you should put in each CA root certificate based on the policies they issue certificates for.
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
Basically anything exceeding the above checks would be rounded down to the closest variation, these are only example suggestions and they may be too strict or too loose, I'll leave the specifics up to someone else to comment on, however if we get some balance that everyone mostly agrees on, even if it isn't implemented in the browser itself could it be implemented as a plug-in? (more below)
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? Or maybe this is something someone can make to incorporate both (Ian?) have a system of interacting with the root certs, and based on finger print of the root certs have a stored set of information (something like the above IDVL examples), after judging the CPS (see above) and then have it show information on the chrome etc...
If the main developers don't want to do it surely there is someone that can? Obviously if a user wishes to bump a CA into a different category they should be allowed to, the whole point of suggesting all this is to give more decision making power to the user. Perhaps this plug-in could also track certificate finger prints and do warnings if they change, or allow the new finger print to also be added to the plug-in database as also acceptable...
--
Best regards, Duane
http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://happysnapper.com.au - Sell your photos over the net! http://e164.org - Using Enum.164 to interconnect asterisk servers
"In the long run the pessimist may be proved right,
but the optimist has a better time on the trip."
_______________________________________________
mozilla-crypto mailing list
mozilla-crypto@mozilla.org
http://mail.mozilla.org/listinfo/mozilla-crypto
