From: Carl Ellison <cme@TIS.COM>
Date: Thu, 23 Nov 1995 03:11:00 +0800
To: raph@c2.org
Subject: Re: Design proposal: crypto-capable generic interface
Message-ID: <9511221840.AA24587@tis.com>
MIME-Version: 1.0
Content-Type: text/plain


>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       |
 +--------------------------------------------------------------------------+