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

[Duane]

On Tue, February 22, 2005 20:15, Amir Herzberg said:

> 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).

Any chance of adding a logo for CAcert by default as well? :)

> 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.

I think for this to be useful it needs some sane defaults, and leaving it
up to the CAs won't be the most useful imho, they could possibly overstate
how much they really should be trusted. Ideally (and I've said this a
number of times to the mozilla news groups) we need more then binary
security, the original design didn't eventuate how anyone thought it
might, we have to deal with how things turned out not bury our heads in
the sand and hoped they were better.

At present there is a bunch of certificates in browsers, they state many
many different things and it's all simple marketing, unless people
actually read the CPSs they won't know how much is truth and how much is
over stated, and it's left me with the feeling SSL is as Ian put it a
"placebo security" because it's not really practical to attack the
encrypted stream, but much easier to attack servers, CAs and social
attacks on people. For the most part it's also very difficult to attack
CAs, people have to own the DNS and while DNS spoofing is possible, there
are easier and more wide spread social attacks on people using what looks
like the real DNS...

I'm getting a little side tracked, but what is needed is a way to quantify
CAs, and more to the point, the practises that lead to issuing a
certificate, how much checking is performed, or how little which ever is
more rellivant. I've even seen some home brew CAs wanting to get their
root certificates in browsers and they're not only doing no checking but
issuing the private key to their users, I'd like to black list any
certificate they issued.

I'm sure there is a point in there somewhere :)

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

At present it could be extended a little to incorporate my suggestions
without too much effort from what I've seen...

It comes across a certificate issued by a CA... in the defaults that root
certificate according to the CPS the CA was auditted on says they require
the person to front up to a police station and do an aferdavid out to make
a sworn statement (with some police verification) they are who they say
they are. I'd say this was due diligence and the root CA should be issued
with a reasonable level of trust... On the other hand the same CA issues
certificates from a different root certificate that only required email
confirmation, I only expect to trust this certificate for things like
webmail and smtp/imap etc, both are valid means to check verification, but
the uses and amount of faith placed in the certificate should also be
relivant, not simply ignored or written off as marketing and ignored by
the security guys because they're too busy with their heads in the sand
that one size fits all...

-- 
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."