Common Security: CDSA and CSSM
Copyright © 1997 The Open Group
File-Based Representation of Signed Manifests
This section describes the file system based representation of a signed
manifest. A signed manifest consists of:
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 first representation is as a file set which resides in a well-known
directory called META-INF. This directory is relative to the file-based
referents in the manifest. The manifest description is written in a
file called MANIFEST.MF. All pathnames appearing in
the sections of MANIFEST.MF are relative to the parent directory of META-INF.
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 constraints placed by the first file-based representation are
relaxed by archiving the signed manifest file set into one file. This
archive file is called an Electronic Shrink Wrap file and must end in
the filename extension .ESW. The .ESW file must reside in the parent
directory relative to all pathnames of file-based referents in the
The archive format of an .ESW file must conform to the archive format
specified by PKWARE. (See
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.
Filenames appearing in the META-INF directory are restricted to the
characters A-Z 0-9 and dash or underscore.
Base filenames consist of at most eight characters.
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.
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).
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.
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.
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.
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
If a file cannot be parsed according to this specification, a
warning should be generated and the signatures should not be trusted.
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.
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
Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy
of this publication.
You should also read the
legal notice explaining the terms and conditions relating to
the CDSA documentation.