Re: [Sks-devel] Displaying user images on index page

[David Shaw]

On Tue, Feb 24, 2004 at 10:18:03PM -0500, Yaron M. Minsky wrote:
> I've heard some requests for the ability to display the actual
> picture associated with the user attribute packet.  Is the contents
> of the user attribute packet standardized enough for this to make
> sense?  How does it work?  Is it always just a JPEG file?

I think this is a great idea.  The user attribute packets are
standardized, and are very similar to v4 signatures in that they are
made up of attribute subpackets that use the same encoding scheme that
signature subpackets use.  You probably have code you can re-use to
parse these.

The relevant bit from the spec is:

5.12. User Attribute Packet (Tag 17)

    The User Attribute packet is a variation of the User ID packet.  It
    is capable of storing more types of data than the User ID packet
    which is (by convention) limited to text.  Like the User ID packet,
    a User Attribute packet may be certified by the key owner
    ("self-signed") or any other key owner who cares to certify it.
    Except as noted, a User Attribute packet may be used anywhere that a
    User ID packet may be used.

    While User Attribute packets are not a required part of the OpenPGP
    standard, implementations SHOULD provide at least enough
    compatibility to properly handle a certification signature on the
    User Attribute packet.  A simple way to do this is by treating the
    User Attribute packet as a User ID packet with opaque contents, but
    an implementation may use any method desired.

    The User Attribute packet is made up of one or more attribute
    subpackets.  Each subpacket consists of a subpacket header and a
    body. The header consists of:

      - the subpacket length (1, 2, or 5 octets)

      - the subpacket type (1 octet)

    and is followed by the subpacket specific data.

    The only currently defined subpacket type is 1, signifying an image.
    An implementation SHOULD ignore any subpacket of a type that it does
    not recognize.  Subpacket types 100 through 110 are reserved for
    private or experimental use.

5.12.1. The Image Attribute Subpacket

    The image attribute subpacket is used to encode an image, presumably
    (but not required to be) that of the key owner.

    The image attribute subpacket begins with an image header.  The
    first two octets of the image header contain the length of the image
    header. Note that unlike other multi-byte numerical values in this
    document, due to an historical accident this value is encoded as a
    little-endian number.  The image header length is followed by a
    single octet for the image header version.  The only currently
    defined version of the image header is 1, which is a 16 octet image
    header.  The first three octets of a version 1 image header are thus
    0x10 0x00 0x01.

    The fourth octet of a version 1 image header designates the encoding
    format of the image.  The only currently defined encoding format is
    the value 1 to indicate JPEG.  Image format types 100 through 110
    are reserved for private or experimental use.  The rest of the
    version 1 image header is made up of 12 reserved octets, all of
    which MUST be set to 0.

    The rest of the image subpacket contains the image itself.  As the
    only currently defined image type is JPEG, the image is encoded in
    the JPEG File Interchange Format (JFIF), a standard file format for
    JPEG images. [JFIF]

    An implementation MAY try and determine the type of an image by
    examination of the image data if it is unable to handle a particular
    version of the image header or if a specified encoding format value
    is not recognized.

What all this boils down to for SKS is:

* Break the attribute packet into subpackets.

* For each subpacket:

    * If the subpacket type is 1, and the subpacket data starts with
      0x10 0x00 0x01 0x01, skip the next 12 bytes and treat the rest
      of the subpacket as a JPEG file.

      Otherwise, skip that subpacket.

Note that there may be multiple subpackets in a given attribute
packet, and that a given key may have multiple attribute packets.

> The real annoyance in implementing this feature is that there's no
> way (at least, none I know of) to have the jpeg be part of the body
> of the HTML file.  Instead, I need to have a link to a URL that is
> used for fetching the image.  It's hardly impossible, but it does
> make it more of a pain to implement.  I guess I mention this only in
> the hope that there's something I'm missing, and there is an easy
> way of embedding a jpeg into the body of an HTML page.

None that I know of.. I think you do need to make a link to a
JPEG-fetching URL.

David