cryptoIDs

Trevor Perrin trevp at trevp.net
Sun Nov 2 12:07:41 PST 2003


Hi cypherpunks,

First-time poster.  I've lurked awhile.  I'm working on a system for key 
infrastructure, and I'd like to invite criticism, comments, help, etc., 
from anyone interested.  You can find the paper and code here:
http://trevp.net#cryptoID


Here's a summary -

The system is based on a critique of X.509-style PKI.  The critique is 
this:  Any key infrastructure has to handle the twin tasks of:
  - Public-key distribution (Bob finding Alice's public-key)
  - Private-key management (Alice keeping her private-key(s) secure yet 
accessible)

PKI handles the former through certificates, and the latter through 
certificate revocation.  These force a tight coupling between subjects 
(e.g. Alice) and CAs - subjects must contact CAs to get their certificates, 
and also to revoke keys and renew certificates.

Since the function of Trusted-Third-Parties (e.g. CAs) is to provide 
information to *relying parties* (e.g. Bob), I argue that this coupling of 
*subjects* with TTPs is inappropriate for a decentralized environment like 
the Internet.

In such an environment, different relying parties will trust different 
TTPs.  For the subject to procure certificates that would satisfy all these 
RPs, he'd have to predict the future to know which RPs will contact him, 
read the minds of these future RPs to know what they care about, and then 
contact the hundreds of TTPs these different RPs trust to procure relevant 
certificates.

It would be better to decouple subjects from TTPs, so that subjects could 
perform private-key management without the involvement of TTPs, and so that 
TTPs could perform key distribution without the involvement of subjects.

The key to this separation of tasks is to use fingerprints as the interface 
between the "private" and "public" domains: the subject will use 
private-key management to perpetuate a long-lived public-key.  The 
fingerprint of this key will be the subject's "cryptographic identifier" - 
it will be passed around by TTPs and RPs to "speak about" the subject.

Now, private-key management and public-key distribution can proceed 
independently.  For private-key management, the subject will most likely 
keep his long-lived "root key" in a safe place, and use it only 
occasionally to certify "subkeys".  The subject may also do things such as 
splitting the root key into shares, using proactive and/or threshold 
signing schemes, using "threshold subjects" a la SPKI, using multiple 
layers of subkeys as "intermediate CAs", using revocation/revalidation to 
quickly disable compromised subkeys, or even just giving his root key to 
someone he trusts who has better security, and more competence with these 
techniques, than himself.

For public-key distribution, online trusted directories (such as DNS, LDAP, 
XKMS, etc.) should replace CAs.  Users would have address books containing 
trusted fingerprints, which they populate manually or by querying directories.

In sum, the argument is that fingerprints are better than certificates for 
key distribution, but that fingerprint key distribution is most effective 
when supported by cert-based private-key management, to secure the long 
life of the fingerprints.

This is similar to PGP (without the Web of Trust) - PGP uses fingerprints 
to authenticate distributed keys, and has subkeys that can be used for 
private-key management.

However, if you take this approach seriously, PGP's fingerprints and 
subkeys aren't good enough.  PGP fingerprints are too long, and PGP subkeys 
don't support important techniques like revalidation, threshold subjects, 
or multiple layers of subkeys.

So the paper presents "cryptoIDs", which are 20-character-long 
fingerprints; and cryptoID certificates, which are a certificate format 
designed solely for private-key management.


Anyways, I'm interested to hear what anyone thinks.  Thanks,

Trevor





More information about the cypherpunks-legacy mailing list