OK, I'll accept that. So your message for the "good" certs is what?
"If you put your CC number into here and get ripped off, it might be possible for you to find the guy who did it."
Just about. As a consumer, I'd be happier with that than "Hey, if you get ripped off, it's not our fault. No guarantees, see? You can just whistle for your money. We're not going to do anything to protect you."
Do you really want to tell people that you know that this particular cert is good for commerce?
I want to distinguish certs where there's a good chance of tracing back to a real person from certs where there's no chance, yes.
Um. Which still leaves the question of just who is doing all these things, and who it is that is sitting in judgement over these CAs and saying a) they are doing good enough verification, and b) I'm prepared to bet my users on it.
Actually, I think the CAs might have an answer to that question.
One approach might be: "Hey guys, we're coming up with a way that lets you charge a lot more money for certs and differentiate yourselves in the market place. All you need to do is help us come up with some decent verification standards, set up an independent body to oversee them, and you can start charging $1000+ for certs. We'll do the UI and the PR push. How's that sound?"
So we should wash our hands of the whole issue and say "we're not going to say anything about security because you might sue us. You're on your own"?
Nope. We stop standing there and saying we are responsible.
I'm not saying we say we are responsible. We are just providing more information to help the user make the decision about whether to trust the connection with their CC number or not.
Perhaps "safe for commerce" was a bad choice of words. My actual current UI thought is a golden $ sign next to the lock.
I really _must_ get around to writing up the four-level security UI idea properly.
Instead, we say, "we do browsers." And, we also say "CAs do certs, and here's the CA that's doing the cert today."
So (just to be clear) a corollary of this position is that we should admit any root cert to the browser store without any sort of vetting or checking.
Right. But Mozilla does browsers, it isn't the world's commerce policeman. The browsers are a tool for users, not their guardian angel.
So the default settings of Mozilla browsers should be to accept all cookies, even third party ones? We should remove the alert when you download an .exe saying "Be careful about this file - it could be dangerous."?
The tool browses, and it provides forms. It gets numbers to the other side, sometimes even securely. What it doesn't say is where is a good place to do that with.
Oh, it does, even now. Ask an average web user what that lock means.
Are you planning to set up a really big table in your UI that lists all the CAs and whether they are "commerce rated" or not?
Yep, just about.
That would make you a super-CA.
Well, it would make whoever decided what that table said reasonably responsible. But it's about the same as the responsibility of admitting the cert in the first place.
What happens if they decide to issue an identity cert and a domain-control cert, under the same root?
See discussion in .crypto.
Please don't tell me you plan to drop their cert from your table ;-)
Why not actually read the discussion? :-)
Some CAs issue certs from different sub-roots; we may be able to include them and give them different levels of trust. Others, you'd pick the lowest trust value and use that. If they wanted better, they'd sort out their issuing policies.
What happens if they convince you that it really is an identity cert, then wait until your UI is out there in its glorious millions, and then they switch to domain control? (Bait and switch, a favourite trick...)
Then we issue a security update either pulling their certs for bad faith, or changing the bits on it.
Ah. So everyone who is ripped off after that is ...
what? Out of luck?
They are in the same position as anyone who suffers loss of some sort after a security update because they hadn't patched. This isn't a browser-specific problem.
Has a legal action against you?
Well, does anyone rooted through an IE hole have a legal action against Microsoft?
OK, what is the average half-life of an upgrade? That is, what is time for half the users to be upgraded once a security alert goes out?
For Microsoft it's measured in years... For Firefox, can we do better?
Again, not a browser-specific problem.
Or, here's the alternate. An injunction is filed in court preventing you from doing these things.
Are you suggesting a CA could file an injunction to prevent mozilla.org from removing their cert from the root cert store? If not, how does changing their trust level within that store differ? If so, then it's a problem we have now anyway.
(Quick note, injunctions are normally granted.
So should I file an injunction to prevent you leaving your house? :-)
Apart from the one where the user says "so, can I put my credit card into this page or not?"
Right. That ain't your problem.
If it isn't, whose is it? The user is staring at their screen. They have a browser UI, and a website they have to decide whether to put info into or not. So they can either look at the browser to decide, or the website content. Which is it? :-)
merchant
i.e. the user should look at the site to assess its trustworthiness.
user
On what basis? That's the question we're asking!
CA
Er... that's what I'm arguing for. The browser UI would reflect the amount of verification the CA had done.
credit card issuer
> bank
So the user should call their issuer or bank before using their card on the net?
You are however an authority on browsers. You might be an authority on certificates. And SSL. You could stand in court or stand in front of destitute grandma and say:
"GeoTrust issued this cert to that domain"
And she says something like "Who?". Or "What you talkin' 'bout, boy?", or "Your UI said this site was secure! There was this little lock and everything!" or "But GeoTrust issue all sorts of certs, some of which are well verified and some of which are not. Which sort is this?"
Gerv _______________________________________________ Mozilla-security mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-security
