Tim Berners-Lee
Date: 2015-02-15, last change: $Date: 2015/03/28 20:46:46 $
Status: personal view only. This is not a formal W3C director view, nor view of the TAG or the Consortium as a whole. It is a contribution to the discussion. It consists of a number of related observations, which could have gone into separate notes, but in the end seemed to be all fairly connected. Editing status: first draft.

Up to Design Issues


Web Security - Client side certs

Authenticating both sides is important

When you are browsing the news and interacting with incoming information, you may be happy not to be identified or even keen to be anonymous. There are times, though, when you want to be well identified yourself, whether moving money around at the bank or chatting with friends. Normally, we do this with passwords.

Public key cryptography is a really wonderful gift from mathematics. We should be making better use of it. Above I have sketched a few areas in which we can improve the way we use it to authenticate the server in this client-server system. We use it occasionally to authenticate the client. We should I think do that much more often.

When I ask people about "client-side certs" (Public Key certificates used by the browser to authenticate the user), a typical response if they are going out of fashion, that they are difficult to use, and that browsers aren't really supporting them properly. But then if you ask people about passwords, then scream that they hate passwords. In fact, key pairs are just so much better than passwords in many ways.

For passwords, you should think of a massively big one which is therefore impossible to remember so you end up relying on your computer to remember it, and it should of course be a different one for each of the things you do business with, and the other party has store a copy of this, and your code has to send it across the net risking it being ensnared within your system or their system, and then they have to store it, which can be pretty insecure, to judge from history. Whereas with public keys, you generate a private key which is stupendously long and unguessable, use it for many different other parties, and you never have to send it to them, and they never see it or store it. That has got to be better. Yes, you can't scribble your secret key on a Post-Itâ„¢; note but that is actually an advantage.

These are the functions a browser needs to provide me as a user.

  1. Create a new public/private key pair, storing the private on the laptop (or on phone or hardware)
  2. Select which cert to use to log on to a given website, saving that preference, with a simple display but with enough information to be able to distinguish the certs.
  3. Display around the URL bar (on the right?) the identity with which I am logged in just as the bowser currently displays the identity of the site I am logged into
  4. Log out: Cancel any authentication in this browser or window, remove the credentials I currently have there, and optionally re-authenticate with a differnt identity.
  5. Manage those preferences of which cert I use for which site, or for this session.
  6. (For extra credit) Back up my private keys and sync them between devices.

Here are some poinst to note.

Just do it

Many of the things which I hear people wish for, mentioned in this article or not, are often put out into the conversation but with a sigh and the caveat that "It would be nice, but that's not how browsers work".

The bowsers are code, in many cases open source code. They are being changed all the time. Unlike a decade ago, they are also being upgraded all the time, because of the need for security-related bug fixes, and so a new idea can be tried out in browsers really fast. When security is an issue, as it is for all the above, browser manufacturers are in a position to make changes. So let us not wring our hands over the fact changes we want to make are not how browsers work today. Let's just change it.


This is the last of four related notes:

  1. "HTTPS Everywhere" considered harmful
  2. Model Real Trust
  3. The Same Origin Policy - Origin Granularity
  4. Client-Side Certificates

References

Up to Design Issues

Tim BL