DSIG - Digital Signature Table

The DSIG table contains the digital signature of the OpenType font. Signature formats are widely documented and rely on a key pair architecture. Software developers, or publishers posting material on the Internet, create signatures using a private key. Operating systems or applications authenticate the signature using a public key.

The W3C and major software and operating system developers have specified security standards that describe signature formats, specify secure collections of web objects, and recommend authentication architecture. OpenType fonts with signatures will support these standards.

OpenType fonts offer many security features:

• Operating systems and browsing applications can identify the source and integrity of font files before using them,
• Embedded font files can identify the publisher (the user who posted the font on the internet),
• Font developers can specify embedding restrictions in OpenType fonts, and these restrictions cannot be altered in a font signed by the developer.

Anyone can obtain identity certificates and encryption keys from a certifying agency, such as Verisign or GTE's Cybertrust, free or at a very low cost.

The DSIG table is organized as follows. The first portion of the table is the header:

Type	Name	Description
ULONG	version	Version, set to 1
USHORT	numsigs	Number of Signatures
USHORT	flag	Set to 1 to indicate that the existing signature should not be replaced

This header information is followed by entries for each of the signatures in the table specifying format and offset information:

Type	Name	Description
ULONG	format	Signature block format
ULONG	cbSignature	Length of signature block in bytes
ULONG	offset	Offset to the signature block from the beginning of the table.

This information is then followed by one or more signature blocks:

Type	Name	Description
ULONG	bSignature	Signature block in one of the defined formats

The format identifier specifies both the format of the signature object, as well as the hashing algorithm used to create and authenticate the signature. Currently only one format is defined, but at least one other format will soon be defined to handle subsetting scenarios. Format 1 supports PKCS#7 signatures with X.509 certificates and counter-signatures, as these signatures have been standardized for use by the W3C with the participation of numerous software developers.

For more information about PKCS#7 signatures, see ftp://ftp.rsa.com/pub/pkcs/ascii/pkcs-7.asc

For more information about counter-signatures, see ftp://ftp.rsa.com/pub/pkcs/ascii/pkcs-9.asc

Format 1: For whole fonts, with either TrueType outlines and/or CFF data

PKCS#7 or PKCS#9. The signed content digest is created as follows:

1. If there is an existing DSIG table in the font,
   1. Remove DSIG table from font.
   2. Remove DSIG table entry from sfnt Table Directory.
   3. Adjust table offsets as necessary.
   4. Zero out the file checksum in the HEAD table.
2. Hash the full stream of bytes using a secure one-way hash (such as MD5) to create the content digest.
3. Create the PKCS#7 signature block using the content digest.
4. Create a new DSIG table containing the signature block.
5. Add the DSIG table to the font, adjusting table offsets as necessary.
6. Add a DSIG table entry to the sfnt Table Directory.
7. Recalculate the checksum in the HEAD table.