Previous section.

Common Security: CDSA and CSSM
Copyright © 1997 The Open Group

Format Specification

This section presents the format specification for the components that make up a signed manifest.

The Manifest

The purpose of the manifest is to unambiguously describe a list of referents so that its integrity and authenticity may be established. This is accomplished by including:

A manifest is composed of header information followed by a list of sections. A section unambiguously describes a referent. The use of metadata is defined below.3.2.1

Manifest Header Specification

A manifest begins with the manifest header, which contains at a minimum the version number: 
 

Manifest-Version: 2.0

Optionally, a version required for use may be specified: 

 

Required-Version: 2.0

Manifest Sections

The manifest section describes a referent, attributes about that referent, and the integrity of the referent (hash value). A manifest section is extensible, therefore it is not possible to define the entire list of headers that may be used. The minimum required headers and a list of well-known extended headers is provided to support interoperability with other implementations.

Well formed manifest sections begin with the Name token and a corresponding referent as a value.

For a listing of the common headers and their meanings see the appendix.

Multiple hash algorithms may be listed and the corresponding hash value must be present for each algorithm used.

Name values must be unique within a manifest. For example: 

 

Name: SomeObject
MAGIC: UsesMetaData
Integrity-TrustedSigner: Some Certificate

Name: SomeObject
Digest_Algorithms: MD5
MD5-Digest: xxxx

is not a valid construction, because the sections cannot be distinguished.

If duplicate sections are encountered only the first is recognized. Nonrecognized headers are ignored.

Format Specification

The sections specifies the grammar for the manifest description and signer information descriptions. Each begins with a header which serves to distinguish its version or required version numbers followed by a list of sections. The header specification for both manifest and signer descriptions is presented first followed by the specification for sections.

In this specification, terminals are specified in all capital letters with non-terminals being specified in lower case. An asterisk indicates 0 or more of the item that follows, while a plus (+) indicates 1 or more of the item that follows.

The format specification for the header of a manifest description is: 

 

manifest: "Manifest-Version: 2.0" newline
           +manifest-entry

manifest-start: section

; Optional header is
; Required-Version: number "." number
;
; Required-Version indicates that only tools of the given version
; or later can be used to manipulate the file.

; The value of Digest-Algorithms is a whitespace-separated-list:

whitespace-separated-list: +headerchar *whitespace
                    whitespace-separated-list
                    | +headerchar

The format specification for signer information is: 

 

signer-information: "Signature-Version: 2.0" newline
          +signer-info-entry

signer-info-entry: section

; Optional header is
; Required-Version: number "." number
;
; Required-Version indicates that only tools of the given version
; or later can be used to manipulate the file.

The format specification for a section (both manifest and signer information) is: 

section:nameheader  *header +newline
newline: CR LF
       | LF
       | CR (not followed by LF)

nameheader:"Name:" *header+newline
        *continuation

header: alphanum *headerchar ":" SPACE *otherchar newline
        *continuation

continuation: SPACE *otherchar newline

; RFC822 defines +(SPACE | TAB) as the continuation.
; Using SPACE *otherchar newline
; ensures that continuations are always recognized

alphanum: {"A"-"Z"} | {"a"-"z"} | {"0"-"9"}

headerchar: alphanum | "-" | "_"

otherchar: any Unicode character except NUL, CR and LF

whitespace: SPACE | TAB

; Also: To prevent damage to files sent via simple e-mail, no
; headers can begin with the four letters "From".

; When version numbering is used:

number: {"0"-"9"}+

; The number 1.11 is considered to be later than 1.9
; Both major and minor versions must be 3 digits or less.

A section begins with the Name token and ends when a new section begins or an end of file is encountered.

MAGIC-A Flagging Mechanism

The keyword MAGIC is used as a general flagging mechanism. It indicates to the verification mechanism that it must be able to parse and interpret the value associated with this keyword:value pair or the verifier cannot properly verify the integrity of the referent object. The UsesMetaData value indicates that this manifest section contains metadata statements which specify how to properly digest and verify the referent object.

Metadata

Metadata qualifies either the manifest or the referent object. Definition of a specification language for metadata is ongoing research. This specification uses the Dublin Core set and a new framework developed as part of this specification called the integrity core set. (See the appendix for details on these specification languages).

Metadata is described by using name:value pairs, where the format of name specifies both the metadata set being used as well as the name element from the set: 

 

(Meta Data Set ID)-(Element Name):Value

For example the Integrity Core set element TrustedSigner would be described as: 

 

Integrity-TrustedSigner: Some Certificate

Ordering Metadata Values

When metadata attributes must be processed in some order-dependent manner, the token Ordered-Attributes must be specified by the manifest definer and used by the manifest verifier. An example of an order-dependent process is a referent object that is first hashed and then compressed before being transmitted with the manifest. The verifier must decompress the referent before computing the digest value of the object. An example of a manifest section with ordering metadata is: 
 

Name: ExampleFile
SectionName: Example of ordered operations on a referent
Ordered-Attributes: SHA1_Digest, Compression
Digest_Algorithms: SHA1
SHA1_Digest: <base64 encoded value>
Compression: SomeSuperFastAlgo

This manifest section specifies that the referent has ordered attributes of SHA1_Digest and Compression. The values that appear as the Ordered-Attributes, must be further qualified by other attributes appearing within this manifest section. The values of the Ordered-Attributes token must be an exact match with the names for other attributes within the section.

The listed order is relative to the signing operation, which implies that the verification operation must reverse the order of these operations.

Manifest Examples

  Manifest-Version: 2.0

  DublinCore-Title: Signed Manifest Format Proposals

Name: http://developer.intel.com/ial/security/CSSMSignedManifest.ps
  SectionName: Intel Manifest Format
  Digest_Algorithms: MD5
  MD5-Digest: (base64 representation of MD5 hash)
  MAGIC: UsesMetaData
  Integrity-Verifydata: Reference-Value
  DublinCore-Title: Signed Manifest File Format
  DublinCore-Subject: Manifest Format
  DublinCore-Author: CSSM Manifest Team
  DublinCore-Language: ENG
  DublinCore-Form: text/postscript

  Name: http://www.javasoft.com/jdk/SignedManifest.html
  SectionName: JavaSoft Manifest Format
  Digest_Algorithms: MD5
  MD5-Digest: (base64 representation of MD5 hash)
  MAGIC: UsesMetaData
  Integrity-Verifydata: Reference-Value
  DublinCore-Title: JavaSoft Signed Manifest Specification
  DublinCore-Subject: Manifest Format
  DublinCore-Author: Someone from JavaSoft
  DublinCore-Language: ENG
  DublinCore-Format: text/html

Signer's Information

The signer's information records the intent of a signer, when signing a manifest. This allows the signer to indicate which sections of the manifest are being signed, and to embed attributes or assertions in headers supplied by individual signers, rather than the manifest owner.

Signing Information Header

The header is the first token in the signer's information description. It must contain the version number for this specification. 
 

Signature-Version: 2.0

General information supplied by the signer that is not specific to any particular referent should be included in this header.

Signer's Information Sections

Each section contains a list of manifest section names. Each named section must be present in the manifest file. Additional metadata statements may be included here. A digest value of the named manifest section is also present.

Referents appearing in the manifest sections but not in the signer's information are not included in the hash calculation. This allows subsets of the manifest to be signed.

A signature section begins with the Name token. There must be an exact match between a Name:value pair in the manifest file.

The following are required: 

 

Name: URL or relative pathname
Digest_Algorithms: MD5
(algorithm)-Digest: (base-64 representation of hash)

Signing Information Examples

 

Signature-Version: 2.0

Name: ./MyFiles/File1
SectionName: File1 Section
Digest_Algorithms: MD5
MD5-Digest: (base64 representation of MD5 hash)

Name: ./MyFiles/File2
Digest_Algorithms: MD5
MD5-Digest: (base64 representation of MD5 hash)

Signature Blocks

A signature block contains the actual formatted signature generated as part of the digital signing process. The signature is computed by hashing the corresponding signer's information and then encrypting that hash using the signer's private key. Signature block encoding is determined by the type of signature block being used. For example, PKCS#7 signatures use BER/DER encoding.
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.

Contents Next section Index