On Wed, 22 Nov 1995, Carl Ellison wrote:
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.
What I am getting from you is "worry." This does not convince me. I want solid technical criticism. Sorry for being so harsh, but that's how I feel. In fact, I propose that the security of the "slave process" model is _better_ than the realistic alternatives. Without it, the application stuff (for example, displaying pretty MIME content) and the crypto stuff must share an address space. A bug in the application stuff could corrupt or compromise the crypto data structures. As we have seen demonstrated several times, it is just not practical to build large, complex applications which are worthy of the highest level of trust. Factoring it into two processes helps. Tokens are nice, but I think there's a lot to be said for software solutions as well. At the very least, I don't consider the existence of tokens to be an argument that software crypto systems shouldn't be built.
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.]
I would accept SHA as a reasonable alternative. Using the modulus alone is not good enough. A bogus key with the same modulus and a different exponent could be used to mount a denial-of-service attack. Note that the PGP 2.6.2 key fingerprint scheme suffers from a similar problem; since the sizes of the modulus and exponent fields are not included in the hash, it is possible to generate bogus keys with the same fingerprint. Specifying the key size and fingerprint together is, however, unforgeable. I looked at the MOSS representation of the key (I'm talking PK's here only, not all the X.509 stuff). I don't think it would be that hard to code.
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).
I was referring to the interface that PGP presents to the outside world, not its internal keyring structures. These issues come up whenever using PGP from the command line, or trying to interface it with other applications.
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.
I understand that Matt Blaze's forthcoming "Policymaker" will do all this and more.
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.
This is fine, but it's one more thing to manually maintain. How is the user going to verify that the alias is really right? This is another place where a 32- (or 40-) hex digit unique name would come in handy.
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.
I agree that a moderated list would be better, but I do not have the time do it myself. One suggestion that I think is very good is to moderate on the basis on the basis of sender, rather than message. The best way to do this would be to keep a keyring of "approved" senders, and match the signature of each message against the keyring. As I say, I'm not volunteering, but if somebody else was so moved, I think it would be a valuable service. Raph