[TrustBar] [Fwd: Re: Low assurance SSL CAs]

[Amir Herzberg]

Duane,

If I understand correctly, your proposal can  be  broken down to two:
1. You suggest that browsers should expose to users the different level 
of assurances of different certificates.
2. You suggest a particular scheme of levels/grades of assurances.

I am very supportive of your first proposal. In fact, what TrustBar 
already does is allow the user to select name/logo for each CA (by 
default this is the name of the CA, or logo if it is a CA we took the 
trouble of putting the logo in our code - currently only for VeriSign 
but we hope to add few more soon; and it is very easy to select a logo 
by the user). This already allows user to distinguish between more 
trusted and less trusted identifications (e.g. by verisign cf. to by 
some of the less careful CAs - and many CAs make very limited validations).

Furthermore, I just discussed this matter with folks from VeriSign, and 
indeed they are very anxious to allow users to differentiate between 
their different products (and levels of assurance). The best solution 
may be to allow the CA to choose a `product` or `assurance level` logo 
which TrustBar will display adjacent to the CA logo.

What do you think (of the current TrustBar UI and of this possible 
improvement)?

Best,

Prof. Amir Herzberg
Dept. of computer science, Bar Ilan University
http://AmirHerzberg.com

Duane wrote:
> 
> Someone suggested I post my ideas in the hope they might be incorporated 
> into this plug-in...
> 
> There is a discussion going on the netscape news groups at present over 
> how current browser security is binary, either on or off in the form of 
> seeing a lock or no lock.
> 
> My thinking is that this isn't good enough, and there is no standard way 
> to represent different grades of how much trust should be put into 
> certificate providers. Even though some providers have "Class 1/2/3" on 
> their root certificate this isn't standardised in any way, even web 
> trust doesn't sanitise the information on root certificates, it judges 
> what's listed in CPS documents and verify they match the CA practise. 
> Below is my suggestions on how it might be better handled.
> 
> Question I have is, is my ideas are feasible at all?
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> Re: Low assurance SSL CAs
> From:
> Duane <duane at cacert.org>
> Date:
> Tue, 15 Feb 2005 21:50:55 +1100
> 
> Newsgroups:
> netscape.public.mozilla.crypto
> 
> 
> 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...
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> TrustBar mailing list
> TrustBar at mozdev.org
> http://mozdev.org/mailman/listinfo/trustbar