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?
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.
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.
Hal