File: png-iSIg-proposal-20080503.txt

This proposal is a companion to the recently-approved dSIG chunk.

It is proposed that this chunk be documented as a revision or addendum
to the dSIG chunk specification.

The dSIG chunk is used to sign an entire PNG (or JNG or MNG) datastream.
Any modification of the file, except for the addition or deletion
of the outer pair of dSIG chunks, will invalidate the signature.

This proposal is for a more robust method, in which only the image
data (including transparency) is signed.  Changes to ancillary
chunks other than tRNS, recompression of the IDAT data, reordering
of chunks, and any other changes that do not change the canonical
form of the image data, will not invalidate the signature.

Like dSIG, the iSIg chunks appear in pairs.  One of each pair must
appear anywhere ahead of the IDAT chunk(s) and the other must appear
anywhere following the IDAT chunk(s).

Each iSIg chunk bears a one-byte identifier as the first byte of
the data.  Both chunks of a pair must contain the same identifier,
and the identifier must be unique to a pair of iSIg chunks.  Otherwise,
the contents of the introductory and following iSIg chunk is the same
as that of a dSIG chunk.  Instead of being calculated over the entire
PNG datastream, the signature is calculated over a canonical form
of the image data, namely the image data promoted to 16-bit-per-sample
RGBA form, including the transparency values determined from either a
tRNS chunk or from an alpha channel.

Promotion of less-than-16-bit samples to 16-bit must be done by
left-bit-replication as described in the PNG specification, without
regard to the sBIT or any other ancillary chunk other than the tRNS chunk.
If an alpha channel is not present or if the tRNS chunk is not present
or is invalid, all pixels in the canonical image must be given an
alpha value of 0xffff (fully opaque).

The bytes of the 16-bit samples must be presented to the signature
calculator in big-endian order, and the samples must be presented in
the order {red, green, blue, alpha}.  Pixels must be presented in
left-to-right scanline order, top to bottom, without any PNG filter
bytes.

Applications creating or decoding an iSIg signature should make it
clear to the user that, unlike the scope of the dSIG chunk,  it is
the image data only, not the entire PNG datastream, that is being signed.

The dSIG and iSIg chunks may both be present in a PNG datastream.  If
so, the iSIg chunks must be located inside the innermost dSIG pair.