Export/Import (Was: Re: Proposal for new Attribute packet)

In <v04003a0db12b6cd10461(_at_)[161(_dot_)69(_dot_)9(_dot_)131]>, on 03/10/98 
   at 02:37 PM, Jon Callas <jon(_at_)pgp(_dot_)com> said:

> One of the things we discussed for putting in OpenPGP was what I've
> called "SDSI names." These are local name or other user IDs. The
> consensus I've seen is that while people think it's a good idea, there
> was no implementation proposal for it.
> There is presently an -- ummm -- situation (I don't know if it's a bug)
> with the way keys work. There is no reason why anyone can't add a
> username to a key, which is not necessarily a good thing. Arguably, a key
> server should trim off any user id that is not self-signed, because it's
> the self-signature that says that the key owner agrees to be known by
> that name.
> On the other hand, SDSI names, local names, or whatever you want to call
> them are a Good Thing. It strikes me that the Attribute packet could
> easily have a constant in there for a local name -- a text user id that
> acts like any other user id, except that it won't be exported.
This brings up and interesting subject: the export of attributes.

I have brought this up in the past that that things like trust attributes
(SDSI names also) have a legitimate use to be exported with a key. One of
the thing I have been working on is the use of a local PGP CA for a
company. In such a situation you would want trust, SDSI, and other
attributes exported along with the keys when a local user retrieved keys
from the local server. On the other hand you would not (or only under
certain conditions) want these same attributes imported to the local
server when a key is uploaded (you may even wish to put restrictions on
who can upload keys at all). 

You can also get into interesting things like distributed "web of trust"
over multiple keyrings. Rather than importing trust packets on a key
(which has some problems of it's own) the client PGP can query the local
PGP server for WoT data for calculating the trust of a given key.
Something like this could be extended to the Public Keyservers sort of an
extended PathServer built into the keyserver protocols.

While I agree that public keyservers should strip all such attributes from
a key before it is added to the server, I think unilaterally preventing
them from being exported is needlessly restrictive.

-- 
---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/esecure.html                
        
---------------------------------------------------------------
 
Tag-O-Matic: If at first you don't succeed, work for Microsoft.

pgpulB5xdgFRH.pgp
Description: PGP signature