ietf-openpgp
[Top] [All Lists]

Re: Proposal for new Attribute packet

1998-03-12 06:59:16
In 
<199803110107(_dot_)RAA00856(_at_)s20(_dot_)term1(_dot_)sb(_dot_)rain(_dot_)org>,
 on 03/10/98 
   at 08:07 PM, Hal Finney <hal(_at_)rain(_dot_)org> said:

William H. Geiger III, <whgiii(_at_)invweb(_dot_)net>, writes:
Well if we are going to modify the userID field so that any binary data
can be used then I think that it is improtant that we add some type of
field identifyer so that the applications processing this data have some
idea of what they are dealing with.

That's in there.  The format I proposed has a representation of the type
of data, then the data itself.

I did get a suggestion in private mail that rather than defining a type
for "JPEG data in JFIF format", it would be better to define the type
more generically as "Image data".  Then the body would have the image
data format, in this case JFIF, and the formatted data.

The advantage would be that if we added more image formats in the future
we wouldn't have to define new top-level attribute types, and it would
set a similar precedent for other kinds of attributes.

Another point which has been raised in the past is the issue of number of
bytes.  Is one byte enough for the type?  Should we use four bytes in the
interests of future expandability?

I prefer the method of using a text type field for the userID's. This
allows the greatest flexibility for the type identifiers. We could have a
predefined list of ID types yet allow the ability of application specific
types to be added. Perhaps we could borrow from the MIME identifiers
(image/jpeg, audio/wav, ...ect). 

I don't like the generic type much as it requires 2 separate checks to
determine the data. In the case of image files it requires the PGP app to
have knowledge of the various image formats (my graphics program support 
~50 different formats). I invisioned a mechanism similar to how many MIME
mailers handle displaying the variety of MIME types by giving the user a
means of assigning viewers and defining new types.

I would like to see some of the most common userID types pre-defined.
Things like e-mail address, real name, url, ldap, ...ect. Perhaps an ID
class of types: ID/email, ID/realname, ID/url, ...ect.

The use of biometrics has been brought up. Type identifiers of image/jpeg
or audio/wav may not be enough. One may wish to use bio/face/image/jpeg or
bio/voiceprint/audio/wav. Perhaps those working with biometrics could jump
in as to wether they feel a specific "biometric" sub-type is needed.

I don't have any "set in stone" format for the type identifier but it
should be somthing that is flexible yet structured enough to be of use. I
would hate to see 5 different implementations using 5 different
identifiers all for the same data.

IMHO it is a little late in the game to be adding things to the spec. I
think that there are some more pressing issues like the ability to revoke
userID's if modifying the format is still open game.

The direction I'd like to go on this would be to say that if a userid is
not self-signed, it should not be used.  Then you could revoke a userid
by revoking your self-signature.  This also solves the problems of people
adding fake names to other people's keys.

It has backwards compatibility problems, though, because a lot of old
signatures are not self-signed.  You'd have to get people with old keys
to self-sign all their (valid) userids.

I don't think that would be too big of an issue. My understanding is that
all 5.x versions of PGP do this already.

A variant would be to accept unsigned userids, but if the userid has a
REVOKED SELF SIGNATURE then that would mean that the keyholder is
explicitly saying not to use this key anymore.

I think that you ment that a revoked self signature would mean not to use
the UserID anymore.

I have noticed that there is a real user "education" problem when it comes
to the meaning of signing of keys. This is not a OpenPGP format problem
but *is* somthing we should be aware of when designinging our user
interfaces.

-- 
---------------------------------------------------------------
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: My best view from a Window was through OS/2.

Attachment: pgp1SdGfYla1I.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>