Re: Proposal for new Attribute packet

[Will Price <wprice@xxxxxxx>]

That's why the capability for non-owners of the key to add User IDs to a
key was removed from the 5.X client, because it generally makes no sense in
the context of a user ID representing information about the key's owner --
information which generally should be modified only by the key's owner.
However, I think this conversation is now far away from the topic at hand.
The fact is that the format of UserIDs technically allows anyone to add a
UserID and old PGP 2.X didn't even add a self-signature on that data unless
told to do so.

We are only talking about formats here.  Whether somebody wants to add a 10
MB Photoshop file, the collected works of shakespeare, fingerprint
information, a voiceprint, or a simple 20 character user ID is not relevant
here.

The only intent is to extend the user ID packet format to allow extensions
in the future so that we're not locked into a non-extensible format which
supports only strings.  What a particular implementation decides to do with
that ability is again outside the scope of the discussion.  For convenience
and because it is simple, a photo ID constant has been defined and I'm sure
at a later point in time, other uses will be defined by this group.

-Will


At 3:48 PM -0500 3/10/98, William H. Geiger III wrote:
>In <>, on 03/10/98
>   at 01:15 PM, Jack Repenning <jackr@xxxxxxxxxxxx> said:
>
>>I'm not sure this addresses the use Hal had in mind.  An implication of
>>allowing an attribute packet "wherever a userid packet may be" is that it
>>can be signed by another party.  I imagine the UI he has in mind would
>>allow this other party to add the attribute, rather than (or, "in
>>addition to") the key owner doing so.  The end goal is (I think) the
>>ability to express the meaning of your signature ... "I certify this key
>>for business purposes, but I wouldn't trust this blighter with the
>>personal secrets of a snail."
>
>>You might do this with additional UserIDs, but only if you allow them to
>>be added by non-owners (a capability recently retracted by PGPInc
>>implementations); you also would have some conflict over whether to match
>>values in the attributes when searching for a key.
>
>>At least, I think that's the sort of thing he was getting at.  Perhaps a
>>bit more info about intended use, and structure of the packet to support
>>it, would be in order.
>
>I'm not sure I like this at all. It is one thing to allow 3rd parties to
>attach their verification of the userID of a key. It is quite another
>thing to allow then to add any information they wanted to. There are quite
>a few nasty and malicious people out there and I for one would not support
>letting them have the ability to add extra information of any kind to my
>public keys.
>
>The more I think about this the less I like it. Seems to be opening a real
>can of worms.
>
>--
>---------------------------------------------------------------
>William H. Geiger III  http://users.invweb.net/~whgiii

Will Price
Architect/Sr. Mgr.
Total Network Security Division
Network Associates, Inc.
(650)473-2906