marcel wrote:
I'm wondering if that wouldnt be a nice feature to do something similar as MS's solution; not fully automatical but instead e.g. having a website where a user can have a look whether a newly encountered cert is trustworthy or not.
I think that's stretching the limits of the CA model.
One of the assumptions is that when you receive the cert, as long as it is signed by a CA on the root list, it is good. It has to be this way, as otherwise the model would have to cope with CA1 being different to CA2, and fairly quickly, the model becomes unworkable (because there is no internal way of dealing with CA1 != CA2 and there is an assumption that the model is internally complete - hence can of worms is opened.)
If you walk along the path of certificate revocation, the same question arises - "why don't we check this cert at some online site." The problem with this journey is that it leads one inevitably to the notion of online real time checking. Which also means that you don't need CA-signed certs... I first heard this from Ron Rivest at a revocation panel, and I've never yet seen an answer to it, systems thinking wise.
In strategic senses it all seems to come down to: use the CA model, as it is, trust the keys, and don't rely on revocation or online checking. If you find you need online checking or revocation, that may be a sign that the CA model doesn't work for your app.
Why? - Today when a web site (e.g. a spoofed version of your online bank) presents a rogue cert, you're asked if you trust that. I believe most users just click yes: They dont know enough to decide on their own, so they're up to the informations they get - from the web site asking to install the cert!
Right. That breaches the CA model, and according to the above analysis (which I just scratched down very quickly) you are now onto the path of bandaids and string, so don't expect too much.
Luckily, the notion that an attacker would present a rogue cert is rather unlikely. Currently, pretty much most of the phishing that goes on is without a cert / without SSL. And, yes the user just clicks through. I have seen one phishing case that used an SSL cert, and after investigation, it was clear that the user would continue to click through.
(This will keep happening until the browser security model starts to engage the user in the SSL process, and relates the differences to the user between a trusted session with a bank versus an untrusted session with something that looks like the bank. A bit like the thunderbird notion of spam filtering.)
In this view, MS's solution is like consulting a trusted third party (MS), and I think thats what the user needs in such a situation to decide accurately.
That's what I mean by bandaids and string. That's a can of worms.
In my opinion, a link inside the "do you want to trust this certificate?"-dialogue to a mozilla web site listing the different CA's and their status of trustworthiness would be a nice feature.
What do you think about this?
See above, CA1 != CA2 isn't part of the model.
btw, I'm speaking for myself only; doing my diploma thesis on these kind of things (rogue CA).
Nice topic. I've recently (from talking to people on this group) come to realise that this is a key weakness (CA1 != CA2) within the CA model, but the observation has been floating around for some time.
iang _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
