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