Previous section.

Common Security: CDSA and CSSM, Version 2
Copyright © 1999 The Open Group

Signed Manifests-Examples

The following is a list of examples that serve to illustrate how this specification meets the requirements for signed manifests.

Static Referent Objects

The manifest: 


 

Manifest-Version: 2.0

Name: pictures/ocean.gif
SectionName: Ocean picture
Digest_Algorithms: MD5
MD5-Digest: base64(md5-hash of ocean.gif)

Name: audio/ocean.au
SectionName: Ocean Sounds Audio File
Digest_Algorithms: MD5 SHA1
MD5-Digest: base64(md5-hash of ocean.au)
SHA1-Digest: base64(sha1-hash of ocean.au)

The signer's information description: 



 

Signature-Version: 2.0

Name: audio/ocean.au
SectionName: Ocean Sounds Audio File
Digest_Algorithms: MD5
MD5-Digest: base64(MD5 Digest of manifest section entitled "Ocean Sounds")

The signature block is not shown here, but it would be represented as an ANS.1 encoded PKCS#7 signature block.

Note that the manifest includes two digests for audio/ocean.au, and the signer's information includes only one. At verification time the manifest section that is hashed is treated as opaque data; hence SHA1 digest is included in the hash.

Dynamic Referent Objects with Verified Source

This example describes a dynamic data source (such as a stock quote service) and its integrity. The manifest names the dynamic data source and qualifies that name with the Integrity Core metadata set. There is no hash value associated with the dynamic referent, rather integrity is based on verifying trust in the source of the data. The data source is specified in the token Integrity-TrustedSigner.

Stock Quote Service

The manifest: 


 

Manifest-Version: 2.0

Name: SomeCompany.cert
SectionName: Trusted Root Certificate
Digest_Algorithms: SHA1
SHA1-Digest: XXXX

Name: http://www.stockquote.com
SectionName: Dynamic Stock Quote Service
DublinCore-Format: message/x-pkcs7
MAGIC: UsesMetaData
Integrity-TrustedSigner: Trusted Root Certificate

Trusted signer specifies the key holder that must have signed the dynamic object. The manifest section entitled "Trusted Root Certificate" contains a referent to a file where the trusted signer's certificate resides. The integrity of the Trusted Root Certificate is specified by including the hash value of the actual certificate in the manifest. This verifies the identity of the signer.

In this example, the signer has signed all sections of the manifest. The signer's information description appears as follows: 



 

Signature-Version: 2.0

Name: SomeCompany.cert
Digest_Algorithms: MD5
MD5-Digest: xxxx

Name: http://www.stockquote.com
Digest_Algorithms: MD5
MD5-Digest: xxxx

The PKCS#7 signature block is not shown.

Embedded or Nested Referent Objects

Signed Objects Whose Signatures Serve to Carry the Object

PKCS#7 signed messages are objects that serve as a carrier for the object being signed as well as the signature for the object. When these enveloped objects are signed using the manifest, the whole object is hashed, treating it just as a generic blob of bits, ignoring its internal structure. To verify these types of objects, the entire object will be hashed and compared to the value in the manifest. If the digest values match, the next step is to verify the integrity of the enveloped object. This two-level verification check is described in the manifest by using the token Integrity-Envelope where the token value defines how the internal object must be verified. In the case where the internal object is enveloped by a PKCS#7 signed message, the value would indicate PKCS-7. The manifest description for a PKCS-12 signed object is similar to the manifest description for the PKCS-7 referent shown here. 


 

Manifest-Version: 2.0

Name: ExamplePKCS7Data.pk7
SectionName: PKCS#7 Signed Message
Digest_Algorithms: MD5
MD5-Digest: (base64 representation of MD5 hash)
MAGIC: UsesMetaData
Integrity-Envelope: PKCS-7

Signed Objects Whose Signature Blocks are Embedded

Referent objects can be other signed objects, where the signature is embedded inside the object itself. When including these objects in a manifest, the entire object (including the embedded signature) is treated as a generic blob of bits during the digest process. However, during verification, it is desirable to verify the embedded signature after all of the manifest components have been verified. This is accomplished by delegating the verification of the embedded signature to the proper verification routines. These verification routines must be identified by the value of the Integrity-Envelope token. 


 

Manifest-Version: 2.0

Name: http://www.activecontrols.com/shareware/KillerControl.ocx
SectionName: Embedded Signature Object
Digest_Algorithms: MD5
MD5-Digest: (base64 representation of MD5 hash)
MAGIC: UsesMetaData
Integrity-Envelope: Authenticode

The manifest section representing the object with an embedded signature indicates this using the Integrity-Envelope token. The token specifies that the signature was generated by and can be verified by the Authenticode system from Microsoft. No trusted signer is specified because the knowledge of "who" is trusted to have signed the executable is embedded in the specialized signature checker.

Nested Manifests

Nesting a signed manifest within another signed manifest is used to associate additional signatures and attributes with a package as it travels through its normal channel of handling. For example, in electronic software distribution, the software publisher creates a manifest representing their software product. The product and the manifest are archived together and electronically transmitted to several distributors. Distributors add advertisements, logos, and so on, and create a new manifest that references all the newly-added material and the original archive (including the signed manifest) from the publisher. The distributor transmits this new archive to its resellers who add branding information specific to their location. The reseller creates a manifest referencing their branding material and the material from the distributor, creating three levels of nested manifests.

An example manifest for a software publisher's release includes: 



 

Manifest-Version: 2.0

Name: KillerApp.exe
SectionName: Killer Internet Application
Digest_Algorithms: SHA1
SHA1-Digest: XXXX

Name: KillerApp.hlp
Digest_Algorithms: SHA1
SHA1-Digest: XXXX

Name: KillerApp.doc
Digest_Algorithms: SHA1
SHA1-Digest: XXXX

Name: Readme.txt
Digest_Algorithms: SHA1
SHA1-Digest: XXXX

Name: EULA.txt
Digest_Algorithms: SHA1
SHA1-Digest: XXXX

The signer information description is: 



 

Signature-Version: 2.0

Name: KillerApp.exe
SectionName: Killer Internet Application
Digest_Algorithms: SHA1
SHA1-Digest: YYYY

Name: KillerApp.hlp
Digest_Algorithms: SHA1
SHA1-Digest: YYYY

Name: KillerApp.doc
Digest_Algorithms: SHA1
SHA1-Digest: YYYY

Name: Readme.txt
Digest_Algorithms: SHA1
SHA1-Digest: YYYY

Name: EULA.txt
Digest_Algorithms: SHA1
SHA1-Digest: YYYY

Once the manifest has been created and signed the publisher archives the software release and the signed manifest, and transmits them to a set of distributors.


Figure: Relationship of Publisher's Archive and Signed Manifest

The distributor creates a new manifest referencing the archive sent by the publisher: 



 

Manifest-Version: 2.0

Name: distributor1logo.gif
SectionName: Distributor 1's logo
Digest_Algorithms: SHA1
SHA1-Digest: XXXX

Name: KillerAppArchive
Digest_Algorithms: SHA1
SHA1-Digest: XXXX

The distributor's signature information is: 



 

Signature-Version: 2.0

Name: distributor1logo.gif
SectionName: Distributor 1's logo
Digest_Algorithms: SHA1
SHA1-Digest: YYYY

Name: KillerAppArchive
Digest_Algorithms: SHA1
SHA1-Digest: YYYY

The distributor creates a new archive, combining the new manifest and the original archive sent by the publisher. This new archive is transmitted to resellers.


Figure: Relationship of Distributor's Archive to Publisher's Archive

The reseller creates another new archive, adding their own specific digital objects and including the archive sent by the distributor: 



 

Manifest-Version: 2.0

Name: reseller1logo.gif
SectionName: Reseller 1's logo
Digest_Algorithms: SHA1
SHA1-Digest: XXXX

Name: distributorarchive
Digest_Algorithms: SHA1
SHA1-Digest: XXXX

The reseller's signature information is: 



 

Signature-Version: 2.0

Name: reseller1logo.gif
SectionName: Reseller 1's logo
Digest_Algorithms: SHA1
SHA1-Digest: YYYY

Name: distributorarchive
Digest_Algorithms: SHA1
SHA1-Digest: YYYY

Figure: Relationship of Reseller to Distributor to Publisher

The reseller's archive includes the distributor's archive, which contains the distributor's manifest. The distributor's archive includes the publisher's archive which contains the publisher's manifest. This results in a manifest being implicitly embedded within another manifest which has in it an implicitly embedded manifest. The embedding is implicit because the manifests are referenced indirectly as part of the archive files.

Signed Portion of an HTML Page 



 

Manifest-Version: 2.0

Name: http://www.scripts.com/index#script1
SectionName: Useful Javascripts demo home page
Digest_Algorithms: SHA1
SHA1-Digest: xxx
MAGIC: UsesMetaData
Integrity-VerifyData: namedsectionvalue
Integrity-NamedSectionForm: javascript

Only the named section "script1" is used in calculating the signature.

Foreign Language Support-Multiple Hash Values

URLs are not unique names for objects. When a browser activates an URL, different documents are returned based on the language preference set in the browser. If the Catalan page is requested, it may not be returned. If there is no Catalan page for that referent, then the default language page is returned. A manifest section must unambiguously describe a referent, therefore the manifest must include a hash value for each of the language representations for a document. 


 

Manifest-Version: 2.0

Name: http://www.intel.com/developer/ial/security/
Section Name: Intel's Data Security Home Page
Digest_Algorithms: SHA1
SHA1-Digest: xxx
SHA1-Digest: yyy
SHA1-Digest: zzz
MAGIC: UsesMetaData
Integrity-VerifyIntegrity: match

Three hash values are provided, each for a different language representation of the referent object. The integrity token Integrity-VerifyIntegrity specifies that the hash of the referent must match one of the three hash values.

Dynamic Sources with no Associated Data

It is possible to have dynamic referent objects that do not provide associated data. This example is distinct from the stock quote service where the dynamic referent provided data. 


 

Manifest-Version: 2.0

Name: telnet://mit.edu/
SectionName: Blessed telnet site

It is not feasible to hash the results of a telnet session. It is useful to list the telnet session as a referent of a manifest because it aggregates the session with other referent objects in the manifest. No hash values are provided for the telnet session because the section hash and hence the referent URL hash are provided in the signature information description.

Resources that Transform Locations

A referent in a manifest section can describe a resource that is either near (a memory image or local file) or far (an http address to a web server). A manifest section can also describe the integrity of an object without specifying its exact location. Consider a referent to an audio file. The file can be on a local file system or on a remote audio file server accessible using the Internet. A single manifest can be used to describe the integrity of this object using the token ResourceProxy. 


 

Name: MyAudioFile.hqa
Section Name: High Quality Audio File
MAGIC: UsesMetaData
Integrity-ResourceProxy: http://www.HighQualityAudio.com\
                         /cgi-bin/StreamAudio?SKU=21339191XW

Name: http://www.HighQualityAudio.com/cgi-bin/StreamAudio?\
                                              SKU=21339191XW
Digest_Algorithms: SHA1
SHA1-Digest: xxx

Integrity-ResourceProxy informs the integrity verifier of two facts concerning the referent:

When verifying the referent MyAudioFile.hqa, if the file does not exist in the local directory, then it can be found at: http://www.HighQualityAudio.com/cgi-bin/StreamAudio?SKU=21339191XW

No digest value is indicated in the manifest section for MyAudioFile.hqa. The digest value is specified in the section describing the ResourceProxy.

It is an error to specify a digest value within the same manifest section where Integrity-ResourceProxy has been specified. If encountered the specified digest value will be ignored.

Click here to return to the publication details.

Contents Next section Index