Client Certificate UI for Chrome?

[James A. Donald]

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

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 majordomo at metzdowd.com