Previous section.

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


Signed Manifests-An Overview

Signed manifests are used to describe the integrity of a list of digital objects of any type and to associate arbitrary attributes with those objects in a manner that is tightly binding and offers non-repudiation. The integrity description does not change the object being described, rather it exists outside of the object. This means an object can exist in encrypted form and processes can inquire about the integrity and authenticity of an object or its attributes without decrypting the object.

Signed manifests are extensible. Attributes of arbitrary type can be associated with any given digital object. This specification defines the framework for a signed manifest with a minimal set of well known name:value pairs that are common to all signed manifests. The set of valid defined names for name:value pairs will increase over time.

Signed manifests are generated by an application using the Common Security Services Manager Integrity Services Library (CSSM ISL) and are verified by either using ISL or the Embedded Integrity Services Library (EISL). EISL may operate on only a subset of the signed manifest name:value pairs defined in this specification. For further details on manifest constraints for EISL verification, see the Appendix.

Overview of the Common Data Security Architecture

Signed manifests are essential to the integrity services provided by the Common Security Services Manager (CSSM) within the Common Data Security Architecture (CDSA). CDSA defines an open, extensible architecture in which applications can selectively and dynamically access security services. The Common Data Security Architecture for all Platforms shows the three basic layers of the CDSA:

CDSA is intended to be the multi platform security architecture that's horizontally broad and vertically robust.

The CSSM is the core of CDSA. CSSM manages categories of security services and multiple discrete implementations of those services as add-in security modules. CSSM:

Applications request security services through the CSSM security API or via layered security services and tools implemented over the CSSM API. The requested security services are performed by add-in security modules.

Over time, new categories of security services will be defined, and new module managers will be required. CSSM supports elective module managers that dynamically extend the system with new categories of security services. Again CSSM manages the extended security perimeter using signed manifests to ensure integrity and authenticity of the dynamic extensions.

Figure: The Common Data Security Architecture for all Platforms

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