This is a proposal for a new packet type, the "attribute packet,"
which is a generalization of the userid packet. Attribute packets can
appear in a PGP key structure anywhere a userid packet could appear.
An attribute packet contains information which is being bound to the
key by signatures, just as a userid packet does. However an attribute
packet allows more kinds of information to be bound than do userid
packets.
Possible examples of attribute packets would include biometric data
regarding the key holder, such as a photograph, fingerprint, or voice
print. A signature on such an attribute packet binds it to the key
and represents an assertion that the key holder does possess the
biometric attribute. Other kinds of attribute packets could be
defined to specify other characteristics which are being bound to the
key.
An attribute packet consists of one or more subpackets (usually just
one subpacket). Each subpacket has a type and some data. The
contents of the data portion will depend on the type.
The only type defined initially is a JPEG photo, in the JPEG File
Interchange Format (JFIF) [ftp://ftp.uu.net/graphics/jpeg/jfif.txt].
The subpacket data is the JFIF data which holds the image.
The format of attribute subpackets is proposed to be similar to
signature subpackets. On Feb 12, 1998 I proposed a generalization of
the mechanism used to express packet and subpacket lengths, to allow
four-octet packet lengths, by preceding them with an octet of 255. It
is proposed that this same mechanism be used to specify subpacket
lengths in attribute packets, with the non-four-octet encodings being
deprecated.
Accordingly, the format of an attribute packet would be
1 or more instances of an attribute subpacket; the format of an
attribute subpacket would follow that of a signature subpacket with
the restriction that four-octet lengths are used:
Each subpacket consists of a subpacket header and a body. The header
consists of:
- subpacket length (5):
Length includes the type octet but not this length.
1st octet = 255
2nd through 5th octets encode subpacket length in big-endian form
- subpacket type (1 octet):
- subpacket specific data:
Note that this length encoding is intended to be consistent with the
encoding for signature subpackets and other packets, except that the
short lengths are deprecated. If we don't choose to add the four-octet
option to those cases, then it would be simpler to just define a new
subpacket format whose length is simply the first four octets. However
I would prefer to see the various lengths unified as I proposed earlier
for ease in description and implementation.
Proposed constants:
Attribute Packet tag: 17
JFIF subpacket type: 1
Hal Finney
PGP, Inc.