Previous section.
Common Security: CDSA and CSSM, Version 2
Copyright © 1999 The Open Group
File-Based Representation of Signed Manifests
Description
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
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
Filenames for the manifest file, signer information file and
signature block file are restricted to the printable characters
A-Z a-z 0-9 and dash and underscore. Base filenames consist of
at most eight characters.
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
Click here to return to the publication details.