File-Based Representation of Signed Manifests

Description

• A manifest description

• Zero or more signer information descriptions

• Zero or more signature blocks

A persistent signed manifest must reside in at least three files. The three files are zipped to create a single credential file in PKZIP format. Each file has an identifying suffix:

• The zipped credential filename suffix is .esw

• The manifest filename suffix is .mf

• The signer information filename suffix is .sf

• The signature block filename suffix identifies the signature type and is one of the following:

  .rsa

  (PKCS7 signature, MD5 + RSA)

  .dsa

  (PKCS7 signature, DSA)

  .pgp

  (Pretty Good Privacy Signature)

The archive format of an .esw file must conform to the archive format specified by PKWARE.

Representation Constraints

All file suffixes must be recognized in upper and lower case.

For each x.sf file there must be a corresponding signature block file.

Before parsing:

• If the last character of the file is an EOF character (code 26), the EOF is treated as whitespace.

• Two new lines are appended (one for editors that do not put a new line at the end of the last line, and one so that the grammar does not have to handle the last entry as a special case, which may not have a blank line after it).

Headers:

• In all cases for all sections, headers which are not understood are ignored.

• Header names are case insensitive. Programs which generate manifest and signer information sections should use the cases shown in this specification.

• Only one "Name:" header may appear in a given section.

Versions:

• Manifest-Version and Signature-Version must be the first token in a manifest and signer's information, respectively. These token names are case sensitive. All other token headers within a section can appear in any order.

Ordering:

• The order of manifest entries is significant only in that the original digest value is computed based on the original ordering.

• The order of signature information entries is significant only in that the original digest value is computed based on the original ordering.

• Manifest and signer information sections entries may not be re-ordered during transmission, because this will adversely effect the digest value.

Line length:

• The line length limit is 72 bytes (not characters), in its UTF8-encoded form. Continuation lines (each beginning with a single SPACE) must be used for longer values.

Errors:

• If a file cannot be parsed according to this specification, a warning should be generated and the signatures should not be trusted.

Limitations:

• Header names cannot be continued, making the maximum length of a header name 70 bytes (followed by a colon and a SPACE).

• Header names must not begin with the character "<".

• NUL, CR, and LF must not be embedded in header values.

• NUL, CR, LF, and ":" must not be embedded in a header.

• It is desirable to support 65,535-byte (not character) header values, and 65,535 headers-per-file.

Algorithms:

• No digest algorithm or signature algorithm is mandated by this specification. However, the following algorithms are expected to be in general use:

  • Digest: at least one of MD5 and SHA1

  • Signature block representation: PKCS#7