Common Security: CDSA and CSSM
Copyright © 1997 The Open Group
Extensions to the JavaSoft/Netscape Specification
The JavaSoft signed manifest specification states that:
"It is technically possible that different entities
may use different signing algorithms to share a single
signature file. This violates the standard, and the
extra signature may be ignored."
The Intel-signed manifest specification allows multiple signers to be
included in the PKCS#7 signature block as long as each signer is
signing the same manifest sections.
The only recognized valid MAGIC value for this specification is
Core Set of Name:Value Pairs
This token specifies the referent for the manifest section.
This token is informational only to the section it appears in.
(Digest algorithm ID)
Well-known digest algorithm identifiers are:
MD5, SHA, SHA1, MD2, MD4
This token specifies that some metadata values appearing within this
manifest section must be processed in an order-specific manner. The
order indicated is relative to the signing operation. The verification
operation must reverse the order indicated.
This token is used as a general flagging mechanism. The only associated
value is UsesMetaData.
These tokens specify metadata contexts within which the name:value
pairs have meaning.
This is a well known name that should be defined in every
metadata set. It points to a resource that provides human
readable text describing the metadata set. For instance:
points to a resource where a human readable description of the
Integrity set resides.
Metadata is used to qualify the referent by providing additional
information that cannot be included in the name. The definition of
valid metadata values is an ongoing effort.
incorporates the Dublin Core metadata set
and a new integrity core set to describe the integrity of the referents.
The Integrity Core is a set of minimal values used to describe the
integrity of information resources. The metadata name for this set is
The core elements are:
This token describes how to retrieve the referent object for hashing.
Valid values are:
Reference-hash only the reference, exclude the contents.
Reference-value-this is the default, hash both the name and contents.
Match-match exactly one of the hash values provided for the referent.
Namedsectionvalue-hash the contents identified by the named
Manifest-the referent is itself a signed manifest.
Signedarchive-the referent is an archive which contains a manifest.
A token defines trusted signers for signed dynamic data sources. The
signer must be described in another manifest section as an information
resource. The value for this name:value pair must be the value of the
referent (the value of the NAME token) in the manifest section
where the trusted signer is described.
This token is used to create descriptions, which cannot be expressed
using VerifyData or TrustedSigner. Valid values are:
Match-indicates that the hash value computed must match
one of the values listed.
Ondemand-this serves as a flag indicating that verification
of the referent should be deferred until the point of rendering.
This is useful when the referent is a large streaming object
which will be incrementally verified as well as rendered.
This token defines the format of the partial section to be hashed. This
is used to describe integrity of a portion of a compound object, such
as a Microsoft PowerPoint slide residing in a Microsoft Word document.
This token identifies the section to be hashed.
This token indicates that the referent itself is a signed object, where
the signature envelopes the object or is embedded within the object.
Valid values are:
PKCS-7-the object is a signed message conforming to
Authenticode-object has been signed by Microsoft's Authenticode system.
This token indicates that the location of the referent object changes
over time. An example is an executable image. To describe the integrity
of the object, a manifest must correctly reference the object as a file
(which is far away) and as a loaded, executing memory image (which is
Details of the specification of the Dublin Core set is outside the
scope of this document. Refer to
for details on this metadata set.
PKWARE Archive File Format Specification
Reference documentation can be found at:
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.