Ben Laurie wrote:
So, I've heard many complaints over the years about how the UI for
client certificates sucks. Now's your chance to fix that problem -
we're in the process of thinking about new client cert UI for Chrome,
and welcome any input you might have. Obviously fully-baked proposals
are more likely to get attention than vague suggestions.

The fundamental problem with certificates is getting them.

OK, suppose you hit a web site that wants a client side certificate, maybe it wants a claimed email address with proof that you can receive email at that address, maybe it wants proof you are over 18, maybe it is run by the company you work for and wants proof you are an employee and wants to know which employee you are. Maybe it wants evidence that you a member in good standing of the committee to slay infidels.

If we suppose your browser *has* such a certificate, and merely needs permission from you, the user, to show it, then the problem is relatively easy - which however does not stop existing browsers from fouling up mightily, perhaps because they are designed around verisign's
business model, rather than anything the user might actually want to

But the problem is much harder, much much harder, if we suppose you do *not* have the certificate.

I will ignore the easy problem, because I am sure that anyone worth talking to can figure out the solution, even though existing browser writers have failed to do so.

OK. Hard Problem: You the user have hit a website that wants a certificate with certain characteristics, and either you do not have it, or you have it somewhere, but your browser does not know you have it, perhaps because it is on another browser on another computer.

It appears to me that existing solutions to this problem are designed around Verisign's business model, rather than user needs. If a client certificate is to identify you to examplecorp as an employee of examplecorp, why does Verisign need to get involved? It's easier for examplecorp to issue its own @#$%^ certificates.

So, assuming you are pretty smart, as I know you to be, and assuming your boss is not evil and not in Verisign's pocket, which I do not know at all ...

So where *would* you have a certificate? Where would you keep it, and what would it look like?

The kind of things that people are used to storing in a browser are bookmarks: Bookmarks have the convenient property that they implement Zooko's triangle: petname, nickname, and guid. They also have the property that if you click on them they take you somewhere. So a certificate should act like some kind of smart bookmark and look to the user like a smart bookmark, which if clicked on should bring you to your logged in web page with the authority issuing the certificate. Your secret key is something like a a secret link or bookmark that automatically logs you in to something like your facebook page, and your public key is something like a link or bookmark that enables other people to view something like your facebook page. Maybe it is your employee page at examplecorp, which shows any records pertaining to you in the company database, some of which, such as contact information, are editable by you, but most of which are not.

And the "something like your facebook page as seen by others" is almost the same link the live authorization that your certificate is still valid.

So how do you *get* a certificate? Suppose, for example, your certificate identifies you to your company, in which case your boss probably gave it to you. What would he give you? Well, obviously, he would give you a username and password, or more likely you would create an account, a username and password, which he would then authorize.

Which username and password would I expect enable you to get to that logged in web page with the authority issuing the certificate, in this case some location on the company web server. And you get to that web page, you would then get an "install <certificate title>" dialog, and if you accept, get something that looks and acts like a bookmark, though it is in fact a company issued certificate, certifying that you are username, where username is also a primary key in the company employee database.

But the trouble with this, of course, is that usernames and passwords can be phished.

The solution to that is password login and account creation in the chrome, not in the web page implementing password-authenticated key agreement, so that the phisher can gain nothing, so long as the user attempting to use the chrome login facilities, rather than html web page login facilities.

It should have been obvious that logging in on a user interface provided by a web page, provided by html code, was entirely insecure - the problem of spoofed logins was well known at the time. So what we needed, from day one, was a secure login that was in the browser chrome, not the web page - and no other form of secure login supported.

When the user creates a username and password, this should by default automatically create a bookmark in his contacts folder, much as an email client usually does when you post a reply. To reduce the risk that the user may be fooled into using a hostile client, the user interface for entering password and username should never pop up except by the user clicking on a login button in the browser chrome, or clicking on a login bookmark. Not only should the user never enter his password and user name on a web page, but also there should never be login
buttons on a web page.

If the user enters the user name and password incorrectly, then he has to pass a reverse Turing test before entering the password again, to prevent scripts from trying millions of passwords. So if an attacker has tried to guess passwords, the website will inform the user that n unsuccessful login attempts have taken place against his user name and ask him to pass the reverse Turing test.

The user interface to create a connection never pops up spontaneously, but only as a direct result of the user choosing to cause it to pop up, typically by clicking on a bookmark in his account list, or by clicking on the login widget in the browser chrome.

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to

Reply via email to