File: png-iSIG-proposal-20080502.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 from either a tRNS chunk or
from an alpha channel.

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.