[cryptography] Client certificate crypto with a twist

Guido Witmond guido at wtmnd.nl
Wed Oct 10 08:44:31 EDT 2012


Hello Everyone,

I'm proposing to revitalise an old idea. With a twist.

The TL;DR:

1. Ditch password based authentication over the net;

2. Use SSL client certificates instead;

Here comes the twist:

3. Don't use the few hundred global certificate authorities to sign
   the client certificates. These CA's require extensive identity
   validations before signing a certificate. These certificates are 
   only useful when the real identity is needed. 
   Currently, passwords provide better privacy but lousy security;

4. Instead: install a CA-signer at every website that signs
   certificates that are only valid for that site. Validation
   requirement before signing: CN must be unique.

The long version:

Clients can choose the CN they wish to have, that is, they can chooose
their own username under which they wish to be known to your site.
The CA of the web site signs the request (at sign-up time) when the CN
is unique for the site. That's the only requirement.

The certificate is axiomatically accepted by the site that created it, 
the certificate is categorically rejected at every other site. Each
site only trust their own CA.

The certificate binds the username and the users' public key to the
CA. It thus creates a cryptographic pseudonym. The user can use this
pseudonym to establish a reputation at for example, a blog site, movie
critics or shopping recommendations.

This simple uniqueness property without the X500 global identities
gives people the power of cryptograhy with the privacy equivalent of
password authenticated accounts.

In addition, with the right browser plugins, it allows people to write
private messages to each others, properly encrypted and authenticated
with the key and certificates without having to rely on the site to
keep it private. 

The crux, I state it is easier to secure the CA that signs requests
than it is to secure a password database that is needed at every log
in.

If a break-in would happen at either the site, or the CA, there would
be nothing to steal nor could it lead to a compromise of a third party
account of the user. No worries about getting sued by users that reuse
passwords among several sites. The only thing of value is to duplicate
the users' id at the site. And that would be detected by the different
serial number on the certificate.


To improve robustness even more, the CA installs a two-level
CA-structure: The root key signs a sub-key. The root key is kept
offline. The sub-key is used to sign the clients' CSRs. Your sites
accepts every certificate from every certificate chain that leads back
to your root certificate.

Every once in a while, you delete the private key of the sub-key and
replace it with a new one. Sign the new key with your root-key. This
procedure sets the clients certificates signed with the old keys 'in
stone'. If you ever need to revoke a certain certificate from
accessing your website (due to misbehaviour or spamming), just
blacklist the certificate until its expire date. No need for OCSP or
other revocation protocols.



Cheers,
Guido Witmond.

PS. The devil is in the details. Most web browsers cannot handle
client certificates easily. That would require some work.

PPS. To read more: https://github.com/gwitmond/eccentric-authentication
To see a silly example implementation: https://www.ecca.wtmnd.nl/
It only works - more or less - with a Firefox browser.

PPPS. Probably I'm reinventing some existing ideas. I'ld love to hear
about those.



More information about the cryptography mailing list