In <199803110107.RAA00856@xxxxxxxxxxxxxxxxxxxxx>, on 03/10/98 at 08:07 PM, Hal Finney <hal@xxxxxxxx> said: >William H. Geiger III, <whgiii@xxxxxxxxxx>, 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:
pgp00032.pgp
Description: PGP signature