Jack Repenning, <jackr(_at_)informix(_dot_)com>, writes:
This is a proposal for a new packet type, the "attribute packet,"
Meaning, "for the draft that needs to come out this month"?
It depends on whether agreement can be reached in time.
William H. Geiger III, <whgiii(_at_)invweb(_dot_)net>, writes:
While this is an intresting proposal I have some concerns over keysize.
Current public databases are over 100Mb now and are growing at an ever
increasing rate. I shudder to think what the size will grow to when BLOB's
are added to the keys. Do we really want PGP keysize to grow into the Mb
range?
The attribute packets don't have to be that large. A small thumbnail
graphic can be a K or so, about the size of the key itself with
signatures. Other attribute packets might consist of structured text
(e.g. database records), which would be small. It is an extensible
mechanism for binding data to the key.
If size becomes an issue, key servers could limit the size of individual
keys or reject large attribute packets if they wish. There can be
competition between key servers which have different policies to see
which are most successful.
The question is whether end users will find this a useful capability.
If so there will be pressure on key servers to provide more storage
capacity. Storage costs are low and dropping, so I don't think it is
likely to be much of a problem.
Lutz Donnerhacke, lutz(_at_)taranis(_dot_)iks-jena(_dot_)de, writes:
I'm very unhappy with it. It seems to make no sense at all. Imagine a JPEG
of the owner of a key. Where should it inserted in the database? IMHO it's
related to the UserID. So simply use the URL subpacket of the signature page
or define an new one. But *do* *not* bind it to the key!
The idea is that a userid describes information about the key holder:
his name, and email address. The attribute packet can describe other
forms of information about the keyholder. So conceptually it is an
alternative to the userid, and should be placed at the same level in the
hierarchy.
Binding it to the key means that the signer certifies that the keyholder
possesses the attribute, which is conceptually the same as binding a
userid to the key.
Hal