Lutz Donnerhacke, <lutz(_at_)taranis(_dot_)iks-jena(_dot_)de>, writes:
I see. Is is now allowed to add a zero certificate to the key as described
in the formal draft? Zero certificates can hold the key expiration time and
related entities. So defining a JPEG subtype in the signature allows to
bind it even to the key, but this cannot be certified by others.
I don't know what your "formal draft" says a zero certificate is.
There is nothing in the draft OpenPGP Message Format spec called a
"zero certificate".
The idea of the attribute is that it is certified by others, like
the userid. It is intended to be a generalization of the userid.
Jack Repenning, <jackr(_at_)informix(_dot_)com>, writes:
I'm still not at all sure I grasp the purpose of this packet. But as the
discussion progresses, I'm becoming very concerned about the timeliness of
the data (size bothers me as well, but that's already been touched). We
already have problems, both conceptual and practical, with expired user IDs
(changing mail addresses, for example). Why do we suppose this as-yet only
vaguely understood (at least, by me) "attribute" will be any less
ephemeral? Might it, for example, be a JPG of my lovely face? What if I
shave my beard?
To the extent that timeliness is an issue, it applies to attribute packets
as well as userids. Attribute packets don't make the problem any worse,
but they don't solve it, either. The timeliness issue is therefore
independent of whether we add attribute packets.
Generally, timeliness can be dealt with by using signature expirations
and signature revocations. If a userid or attribute is no longer valid,
signatures on it can be revoked. If it is anticipated that the userid or
attribute may be valid only temporarily, signatures can be issued with
expiration dates, and re-issued as needed. These are fairly standard
procedures for dealing with certification issues.
Hal