File-Based Representation of Signed Manifests

• A manifest description

• Zero or more signer information descriptions

• Zero or more signature blocks

There are two representations for a signed manifest in the file system. The first representation maintains compatibility with existing implementations of signed manifests, while the second representation relaxes some of the constraints imposed by the first.

The META-INF Directory-First File-Based Signed Manifest Representation

The signer information is placed in the META-INF directory under the filename x.SF, for some string x containing only the characters A-Z 0-9 and dash or underscore. x must not be more than eight characters, for instance MySig.SF.

Signature block filenames must share the base filename of the corresponding signer's information file. The filename extension identifies the signaturing type:

    .RSA      (PKCS7 signature, MD5 + RSA)
    .DSA      (PKCS7 signature, DSA)
    .PGP      (Pretty Good Privacy Signature)

The ESW File-Archive-Based Signed Manifest Representation

The archive format of an .ESW file must conform to the archive format specified by PKWARE. (See http://www.pkware.com/download.html for additional information.)

The signed manifest file set that appears in a .ESW archive must conform to the filename formats stated in the previous section, for example, an .ESW archive must:

• Have all manifest file names must be relative to META-INF

• Contain only one META-INF/MANIFEST.MF

• Contain zero or more META-INF/x.SF files

• Contain zero or more META-INF/x.(RSA, DSA, and so on) files

It is the responsibility of the verification program to select the correct .ESW file for the objects to be verified.

Representation Constraints

The names "META-INF", "MANIFEST.MF", and the filetype ".SF" should be generated as upper case, but must be recognized in upper and lower case.

File system pathnames appearing in a manifest must be relative to the parent directory of META-INF.

There can exist only one MANIFEST.MF file in a META-INF directory.

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 don't put a new line at the end of the last line, and one so that the grammar doesn't have to special-case the last entry, 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 so the maximum length of a header name is 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 65535-byte (not character) header values, and 65535 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