Date: Wed, 22 Nov 1995 10:11:00 -0800 (PST) From: Raph Levien <raph@c2.org> Subject: Re: Design proposal: crypto-capable generic interface Message-Id: <Pine.SUN.3.91.951122094209.29001A-100000@infinity.c2.org>
In restrospect, "daemon" was a poor choice of words to describe my proposal. "Slave process" gets the idea across much better,
I'm a great fan of programming by cooperating processes -- but I still worry when it comes to crypto. What we need to do, if we want real security, is hold all the crypto secrets (therefore the crypto itself) in a device (PCMCIA card?) in the physical posession of the user. The cooperating-process model could make that easier -- but, if designed wrong, it could call for the device to give up a secret to be sent by IPC over to the slave process.
This requires that keys have some nonforgeable names, which is unfortunately not a feature of PGP 2.6.2. S/MIME will do it just fine, if you buy into the Certifcation Authority (<wink> at Nick Szabo).
Public keys, if that's what you're talking about, have perfectly good nonforgeable names -- themselves. They are unique. They are the proper name which can collect all the attributes of that key which are of interest (e.g., permission to spend $, name of a human who knows the private key, attributes about that human, etc.).
Ok. But public keys have one serious disadvantage: their size. [...]
I propose using the MD5 hash of the whitespace-free MOSS representation of the public key, in hex. It's simple enough to be described in one sentence, but does everything I want.
That sounds fine -- but why deal with a text MOSS representation? It's the modulus which is unique -- so just hash the binary bytes of the modulus, MSB first. There's no need to force anyone checking a key to have all the MOSS printing software in the loop. You might also consider using SHA instead of MD5 -- but that adds to the character count on your business card. [I printed up my own business cards with PGP fingerprints for my 2 primary keys -- and it took up about 1/4 of the card, in a readable font.]
Note that PGP 2.6.2 does _not_ allow the use of a public key as the name of a public key, unless you do a horrible hack such as replace the pubring.pgp file with the one public key of interest.
PGP keyring structures do use the key as its own name, I believe. The UserID is a separate entity, associated with the stand-alone key. A signature applies to a pair (UserID,Key). If I could change the PGP keyring structure, I'd add a new entity -- an Attribute block -- a string and my key ID, with a signature on the Attribute+ObjectKey. This can be done today with the UserID and signature -- and I've even tried it. It works, but PGP is used to accessing keys by the text in a UserID field and that's not appropriate. The Attribute would give a statement I'm prepared to stand by, giving testimony about the key being signed or the person who has demonstrated the ability to sign something I've verified with that key. We might need to add something like MOSS's aliases, for my use only, to let me access keys. If I know someone as Bobby -- that's an association in my own head -- not applicable to anyone else. When I access him by that alias, that's for my use. Therefore, only I should define it and only I should sign the association. This is what I'd use instead of PGP's UserID blocks -- alias blocks. I commend TIS/MOSS's aliases to people's study. The MOSS guys have used the alias structure not only to define nicknames of importance only to me but also to define crypto-lists (like mailing lists). Needless to say, the assignment of aliases needs to be protected. An attacker mustn't be allowed to slip a new alias and/or new key into your ring -- especially if it's a crypto-list definition.
Thanks for the suggestion. However, my concerns are with implementation and deployment, not research. I am perfectly willing to consider cryptographic algorithms to be black boxes that do what they say they will. I think the charter exists to start a new list. John Gilmore has already offered to start a "coderpunks" list on toad.com. Shall we take him up on it?
My suggestion is that if you want this limited in content, it'll have to be moderated. - Carl +--------------------------------------------------------------------------+ |Carl M. Ellison cme@tis.com http://www.clark.net/pub/cme | |Trusted Information Systems, Inc. http://www.tis.com/ | |3060 Washington Road PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2| |Glenwood MD 21738 Tel:(301)854-6889 FAX:(301)854-5363 | +--------------------------------------------------------------------------+