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 majord...@metzdowd.com
