[cryptography] Client certificate crypto with a twist

Thierry Moreau thierry.moreau at connotech.com
Wed Oct 10 23:53:18 EDT 2012


Jon Callas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Oct 10, 2012, at 6:52 AM, Jonathan Katz wrote:
> 
>> Looking at this just from the point of view of client-server authentication, how is this any better than having the website generate a cryptographically strong "password" at sign-up time, and then having the client store it in the password cache of their browser?
>>
>> Note that both solutions suffer from the same drawback: it becomes more difficult for a user to log on from different computers.
> 
> An excellent point, Jonathan.
> 
> I also wonder why there has to be any certification at all?
> 
> Right now, web sites store a user name and a representation of a password. (Note that a password, a hash of a password, etc. are all representations of that password.)
> 
> Why not store a representation of a *key* (a hash is a representation of a key) and then prove possession of the key? It doesn't need to be certified. I can store that key on as many computers as needed via a keychain or something like it.

The server then binds a public key to an account. I refer to this as 
"first party certification" (relying party maintains its own trust 
database and has no need to issue certificates). It suggests a user 
mental model where the PPKP (public-private key pair) becomes the 
authenticating data element. The public key certificate becomes irrelevant.

> 
> Of course, one could have that key be part of a certificate for the times that that is necessary.

When needed, e.g. for TLS session negotiation, it can be either 
self-signed, or auto-issued with the AIXCM dummy CA 
(http://www.connotech.com/public-domain-aixcm-00.txt).

Self-signing (or self-issuing) on-the-fly leaves the X.509 details out 
of the key store.

Maybe a single (or a few) PPKP(s) would be easier to migrate from one 
device to the other (easier than a full key store synchronization).

A single PPKP solves the Yet Another Account concern raised by others, 
at the cost of privacy protection (maybe one can't have his cake and eat 
it -- within the TLS paradigm).

Tools to manage the single PPKP would preferably be independent of a 
specific browser. In applying the openssl utilities to this task for a 
proof of concept, one notices the many inconsistencies of PKCS#? and the 
endless X.509 details.

You may guess I am investigating these avenues. However, my primary 
focus is not the low-value authenticated web session use case. 
Accordingly, some of the observations above may be out-of-sync with the 
real world challenges.

- Thierry Moreau



More information about the cryptography mailing list