On 9/1/09 03:52, Julien R Pierre - Sun Microsystems wrote:
If a server changes to a new cert with a new key, how will KCM work
"much better" ?
If the new cert is authentic, then this will cause some form of alert,
which would be this case:
If you follow the KCM logic, you would have to give an application
warning, which is completely unwarranted under current standards.
If the new cert is unauthentic, then it would cause some form of alert
that would be entirely warranted. Currently, a false cert will slip
through without any change.
Think of a bookmark. Add a cert. add a few whizzbangs in the bookmark
manager, go from there....
It doesn't matter whether you type it or not when you are talking about
SSL. Only what's on the network matters, ie. the cert that the server
sends. The content of the cert is supposed to confirm the identity of
the server.
Right. Tell it to the UI guys. The content of the cert does not
confirm the identity of the server, because only now are we seeing
prominent displays.
The problem is well-hashed. The SSL stuff was supposed to just "work",
so the UI guys dropped all the info. This meant it was easy to trick,
something the original designers knew well, but apparently was not
really appreciated.
There has to be *integration* between the user's actions and the site's
actions. End-to-end. Bookmarks would be (are) one way of doing this.
You can think of a bookmark+cert as similar or like a poor-man's client
certificate if you like.
Much like, when you call somebody over the phone, their
voice print (usually) confirm who you are talking to. URLs get
redirected, phone numbers change. In all cases authentication is needed,
whether somebody has fat fingers or is using bookmarks, or the redial
button on a phone, whether somebody has a bad cold and sounds
significantly different than using (their key changed :)). You still
have to do your authentication. You may have a particular expectation of
what key or what person is on the other end, but still you don't
normally start communicating before you have confirmed the identity.
Right. But look at the end-user's question in another thread. It isn't
being answered. The issue here is that Firefox is acting like a
blackbox, and can't be seen inside. The equation is too complex.
The difference between an old phone and a new Firefox is that the white
box that is the phone has two analogue wires, a dialtone, and a telco at
the other end with various protections. It was possible to reliably
show what was going on, even without an electrical engineering degree,
and generate some security that all was well.
Now, however, we have a question whereby Firefox generates the key,
sends the CSR for signing, gets back the cert, displays various cert
indications, includes special features for key escrow, tells you the
connection is secure ... all within a black box.
It feel rather annoyed if I'd have to confirm every new cert
encountered.
Yes, on the web we usually cannot do that ourselves, that's why we trust
CAs to do the work for us. If we aren't happy with a particular CA's
job, we don't have to trust them...
Were you following the threads of December? Approximately three cases
of trickiness. I'm not saying that the PKI is about to meltdown, but
some of the flaws in the system that we've know for a long time became
apparent. And no solution in site, except more of the "trust me" rhetoric.
It is policy, more or less, that end-users don't get to trust a
particular CA. They only get to trust Firefox's black box magic, and if
they lose, they lose. Just how inspiring is that?
It is policy, more or less, that *any* CA's cert is good. Gee. It is
also policy, more or less, that CAs work to identity and control, and
identity fraud and tricking computer systems is a crook's dream.
It is policy, more or less, that nobody accepts the responsibility for this.
Do you believe in all that?
iang
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
