Frontmatter

©December 1997, The Open Group All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the prior permission of the copyright owners.

Any comments relating to the material contained in this document may be submitted to The Open Group at:

The Open Group
Apex Plaza
Forbury Road
Reading
Berkshire, RG1 1AX
United Kingdom

OGSpecs@opengroup.org

Preface

The Open Group

The Open Group is the leading vendor-neutral, international consortium for buyers and suppliers of technology. Its mission is to cause the development of a viable global information infrastructure that is ubiquitous, trusted, reliable, and as easy-to-use as the telephone. The essential functionality embedded in this infrastructure is what we term the IT DialTone. The Open Group creates an environment where all elements involved in technology development can cooperate to deliver less costly and more flexible IT solutions.

Formed in 1996 by the merger of the X/Open Company Ltd. (founded in 1984) and the Open Software Foundation (founded in 1988), The Open Group is supported by most of the world's largest user organizations, information systems vendors, and software suppliers. By combining the strengths of open systems specifications and a proven branding scheme with collaborative technology development and advanced research, The Open Group is well positioned to meet its new mission, as well as to assist user organizations, vendors, and suppliers in the development and implementation of products supporting the adoption and proliferation of systems which conform to standard specifications.

With more than 200 member companies, The Open Group helps the IT industry to advance technologically while managing the change caused by innovation. It does this by:

• consolidating, prioritizing, and communicating customer requirements to vendors

• conducting research and development with industry, academia, and government agencies to deliver innovation and economy through projects associated with its Research Institute

• managing cost-effective development efforts that accelerate consistent multi-vendor deployment of technology in response to customer requirements

• adopting, integrating, and publishing industry standard specifications that provide an essential set of blueprints for building open information systems and integrating new technology as it becomes available

• licensing and promoting the Open Brand, represented by the "X" mark, that designates vendor products which conform to Open Group Product Standards

• promoting the benefits of the IT DialTone to customers, vendors, and the public.

The Open Group operates in all phases of the open systems technology lifecycle including innovation, market adoption, product development, and proliferation. Presently, it focuses on seven strategic areas: open systems application platform development, architecture, distributed systems management, interoperability, distributed computing environment, security, and the information superhighway. The Open Group is also responsible for the management of the UNIX trademark on behalf of the industry.

The Development of Product Standards

This process includes the identification of requirements for open systems and, now, the IT DialTone, development of CAE and Preliminary Specifications through an industry consensus review and adoption procedure (in parallel with formal standards work), and the development of tests and conformance criteria.

This leads to the preparation of a Product Standard which is the name used for the documentation that records the conformance requirements (and other information) to which a vendor may register a product.

The "X" device is used by vendors to demonstrate that their products conform to the relevant Product Standard. By use of the Open Brand they guarantee, through the X/Open Trade Mark Licence Agreement (TMLA), to maintain their products in conformance with the Product Standard so that the product works, will continue to work, and that any problems will be fixed by the vendor.

Open Group Publications

The Open Group publishes a wide range of technical documentation, the main part of which is focused on specification development and product documentation, but which also includes Guides, Snapshots, Technical Studies, Branding and Testing documentation, industry surveys, and business titles.

There are several types of specification:

• CAE Specifications

  CAE (Common Applications Environment) Specifications are the stable specifications that form the basis for our Product Standards, which are used to develop X/Open branded systems. These specifications are intended to be used widely within the industry for product development and procurement purposes.

  Anyone developing products that implement a CAE Specification can enjoy the benefits of a single, widely supported industry standard. Where appropriate, they can demonstrate product compliance through the Open Brand. CAE Specifications are published as soon as they are developed, so enabling vendors to proceed with development of conformant products without delay.
  

• Preliminary Specifications

  Preliminary Specifications usually address an emerging area of technology and consequently are not yet supported by multiple sources of stable conformant implementations. They are published for the purpose of validation through implementation of products. A Preliminary Specification is not a draft specification; rather, it is as stable as can be achieved, through applying The Open Group's rigorous development and review procedures.

  Preliminary Specifications are analogous to the trial-use standards issued by formal standards organizations, and developers are encouraged to develop products on the basis of them. However, experience through implementation work may result in significant (possibly upwardly incompatible) changes before its progression to becoming a CAE Specification. While the intent is to progress Preliminary Specifications to corresponding CAE Specifications, the ability to do so depends on consensus among Open Group members.
  

• Consortium and Technology Specifications

  The Open Group publishes specifications on behalf of industry consortia. For example, it publishes the NMF SPIRIT procurement specifications on behalf of the Network Management Forum. It also publishes Technology Specifications relating to OSF/1, DCE, OSF/Motif, and CDE.

  Technology Specifications (formerly AES Specifications) are often candidates for consensus review, and may be adopted as CAE Specifications, in which case the relevant Technology Specification is superseded by a CAE Specification.

In addition, The Open Group publishes:

• Product Documentation

  This includes product documentation-programmer's guides, user manuals, and so on-relating to the Pre-structured Technology Projects (PSTs), such as DCE and CDE. It also includes the Single UNIX Documentation, designed for use as common product documentation for the whole industry.

• Guides

  These provide information that is useful in the evaluation, procurement, development, or management of open systems, particularly those that relate to the CAE Specifications. The Open Group Guides are advisory, not normative, and should not be referenced for purposes of specifying or claiming conformance to a Product Standard.

• Technical Studies

  Technical Studies present results of analyses performed on subjects of interest in areas relevant to The Open Group's Technical Program. They are intended to communicate the findings to the outside world so as to stimulate discussion and activity in other bodies and the industry in general.

Versions and Issues of Specifications

As with all live documents, CAE Specifications require revision to align with new developments and associated international standards. To distinguish between revised specifications which are fully backwards compatible and those which are not:

• A new Version indicates there is no change to the definitive information contained in the previous publication of that title, but additions/extensions are included. As such, it replaces the previous publication.

• A new Issue indicates there is substantive change to the definitive information contained in the previous publication of that title, and there may also be additions/extensions. As such, both previous and new documents are maintained as current publications.

Corrigenda

Readers should note that Corrigenda may apply to any publication. Corrigenda information is published on the World-Wide Web at http://www.opengroup.org/corrigenda.

Ordering Information

Full catalogue and ordering information on all Open Group publications is available on the World-Wide Web at http://www.opengroup.org/pubs.

This Document

This document is a CAE Specification (see above).

The CDSA specification is divided into thirteen parts in order to address the needs of a number of distinct audiences. Most of the parts are normative (they define programming interfaces), and a small number are descriptive and/or informative.

The 13 parts are as follows:

• Part 1: Common Data Security Architecture (CDSA)

  Presents the overall CDSA architecture, with emphasis on the Common Security Services Manager. It explains the four-layer architecture as consisting of:

  1. Applications

  2. Layered services and middleware

  3. Common Security Services Manager (CSSM) infrastructure

  4. Security Service Provider Modules

• Part 2: Common Security Services Manager (CSSM) API

  Defines the base application programming interfaces available in all CSSM implementations, as follows:

  • CSSM Core Services API

  • Cryptographic Services API

  • Trust Policy Services API

  • Certificate Library Services API

  • Data Storage Library Services API

  These are a subset of the APIs that can be supported and available to applications and add-in service modules through the CSSM.

• Part 3: CSSM Key Recovery API

  Defines the elective application programming interface that applications and other add-in service modules can use to access key recovery services. Applications use these services explicitly. CSSM dynamically incorporates extended services when required. From the application's perspective, basic services and elective services are accessed through the CSSM in the same manner.

• Part 4: CDSA Embedded Integrity Services Library API

  Defines the application programming interfaces provided by the static Embedded Integrity Services Library (EISL). These services are available to applications, add-in security service modules, and to CSSM itself. This also includes documentation of the bilateral authentication procedure for integrity and identity checks between two parties, and the specification of manifests as an aggregator of heterogeneous signed objects.

• Part 5: CDSA Signed Manifest Specification

  This is a Descriptive/Informational specification document.

  It defines the structure and use of signed manifests. A manifest aggregates the description of the integrity of a set of heterogeneous signed objects. A manifest is one of the credentials required for each dynamic component of the CDSA.

• Part 6: CSSM Elective Module Manager

  Defines CSSM-internal interfaces for elective module managers. These interfaces include installation, dynamic attach, function registration, and mechanisms for state sharing among module managers.

• Part 7: CSSM Add-In Module Structure and Administration

  Defines the architecture and management interfaces for all add-in security service modules. Modules must implement this interface to dynamically attach to CSSM and provide their services to applications through the CSSM APIs.

• Part 8: CDSA Mechanisms for Policy Compliance

  This is a Descriptive/Informational specification document.

  It defines architectural extensions and feature enhancements to support a wide range of government-specified and enterprise-specified policies that control the use of cryptography or other security services. These extensions affect all components in the four-layer architecture: applications, layered security services, the Common Security Services Manager (CSSM), and add-in service provider modules.

• Part 9: CSSM Cryptographic Service Provider Interface

  Defines the interface that cryptographic service providers must conform to in order to be accessible via CSSM. Individuals interested in making cryptographic services available under the CSSM interface will need to be familiar with the CSSM SPI. This part also provides key information regarding the expected behavior of a cryptographic service provider as well as implementation examples, which may be of use to the cryptographic service provider developer.

• Part 10: CSSM Trust Policy Interface

  Defines the interface that trust policy modules must conform to in order to be accessible via CSSM. Individuals interested in developing trust policy features available under the CSSM interface will need to be familiar with the CSSM TPI. This part also provides key information regarding the expected behavior of a trust policy module, as well as implementation examples which may be of use to the trust policy module developer.

• Part 11: CSSM Certificate Library Interface

  Defines the interface that certificate libraries must conform to in order to be accessible via CSSM. Individuals interested in developing certificate library features available under the CSSM interface will need to be familiar with the CSSM CLI. This part also provides key information regarding the expected behavior of a certificate library module, as well as implementation examples which may be of use to the certificate library module developer.

• Part 12: CSSM Data Storage Library Interface

  Defines the interface that a data storage library must conform to in order to be accessible via CSSM. Individuals interested in developing data storage library features available under the CSSM interface will need to be familiar with the CSSM DLI. This part also provides key information regarding the expected behavior of a data storage library module, as well as implementation examples which may be of use to the data storage library module developer.

• Part 13: CSSM Key Recovery Interface

  Defines the service provider interface that key recovery modules must conform to in order to be accessible as an elective service via CSSM. Individuals interested in developing key recovery mechanisms and making them accessible through the CSSM interface will need to be familiar with the CSSM KRI. This part also provides critical information regarding the expected behavior of a key recovery module, as well as implementation examples which may be of use to the key recovery module developer.

A glossary and index are also provided.

Intended Audience

Part 1 provides an overview of the CDSA for Independent Software Vendors (ISVs), Independent Hardware Vendors (IHVs), and platform vendors who develop security products as complete applications in a monolithic environment. This audience includes:

• Experienced software and hardware designers

• Security architects who work in high-end cryptography

• Advanced programmers

• Sophisticated integrators familiar with numerous forms of network computing

This audience understands their requirements and the advantages of a ubiquitous, extensible security infrastructure upon which they can build security-aware application products, or through which they can offer their plug-in security service products.

The CDSA specifications are partitioned to address the needs and perspectives of three audiences-application developers, security service providers, and infrastructure providers.

Developers and providers, having read Part 1, may choose to selectively read other parts of the document, since particular specifications will satisfy the needs of the different categories of reader:

• Application Developers who implement applications, layered services and middleware, will find Parts 2, 3, 4, and 5 useful.

• CSSM Infrastructure Providers who implement the Common Security Services Manager will find Parts 2, 5, 6, 7, and 8 useful.

• Security Service Module Providers who implement dynamic plug-in security services will find Parts 5, 9, 10, 11, 12, and 13 useful.

The intended audience for various parts of the book is summarized here:

Part 2

This part is intended for use by Independent Software Vendors (ISVs) who will develop their own application code to interact with CSSM services. These ISVs are highly experienced software and security architects, advanced programmers, and sophisticated users. They are familiar with network operating systems and high-end cryptography. We assume that this audience is familiar with the basic capabilities and features of the protocols they are considering.

Part 3

This part is intended for use by Independent Software Vendors (ISVs) who will develop exportable and importable application code to interact with CSSM services. These ISVs are highly experienced software and security architects, advanced programmers, and sophisticated users. They are also familiar with local and foreign government regulations on the use of cryptography and the implication of those regulations for their applications and products.

Part 4

This part should be used by Platform Vendors and Independent Software Vendors (ISVs) who want to enhance product security by including integrity and authentication checks in the core of their products. These developers must have a good understanding of:

• The principles of integrity and authentication in an executing software environment

• The role of digital credentials in authenticating a software object

• The structure of a secured manufacturing environment for authenticate-able software products

It is also assumed that these developers have a working knowledge of signed manifests as digital credentials.

Part 5

This part is essential for all developers whose products involve the expression and/or validation of the integrity of a collection of digital objects. This includes those developing:

• Add-in security service modules for CSSM

• Elective Module Managers for CSSM

• Applications that:

  • Package a collection of digital objects or services

  • Make assertions about a collection of digital objects or services

  • Verify the integrity of a collection of digital objects or services

  • Establish trust in the assertions being made about a collection of digital objects or services

Part 6

This part should be used by Independent Software Vendors (ISVs) who want to develop categories of security services different from the four basic CSSM service categories: trust policy, certificate library, data storage library, and cryptographic services. These ISVs should be highly experienced software and security architects and advanced programmers. This audience is familiar with high-end cryptography, digital certificates, and features of the security protocols they are considering.

Part 7

This part should be used by Independent Software Vendors (ISVs) who want to develop their own add-in modules to support one or more of the CSSM Service Provider Interfaces. These ISVs should be highly experienced software and security architects, advanced programmers, and sophisticated users. They are familiar with data storage systems, high-end cryptography, and digital certificates. It is assumed that this audience is familiar with the basic capabilities and features of the protocols they are considering.

Part 8

This part should be of interest to a broad audience of CDSA developers and CDSA system administrators.

• CSSM Developers-engineers who implement or port CSSM can use this document as a design specification for enhanced mechanisms.

• Component Developers-engineers who design and develop add-in security service modules can use this document as the definition of software procedures that add-in modules must incorporate to inter-operate with an enhanced CSSM. These procedures are the responsibility of a CDSA add-in module manufacturer.

• CSSM and Component Vendors-product deployment engineers can use this document as a guide to required business practices and procedures for packaging and shipping an enhanced product.

• Policy Definers-corporate and government entities that define system-wide policies on the use of security services can use this document as a guide to determine whether the enhanced CSSM meets their compliance requirements.

Part 9

This part should be used by Independent Software Vendors (ISVs) who want to develop CSSM add-in service modules providing cryptographic services such as digital signing and verification, encryption and decryption, digesting, key generation, and random number generation. These developers must have a very strong understanding of:

• The cryptographic algorithms they intend to implement

• Standard formats for cryptographic keys

• All legal constraints on their product defined by the government of their local jurisdiction

It is also assumed that these developers have a working knowledge of how the cryptographic services they provide can be used to provide integrity, authentication, confidentiality, and non-repudiation of data and actions.

Part 10

This part is directed toward security software developers who want to develop their own Trust Policy module. These developers should be familiar with cryptography and digital certificates. This document assumes the reader is familiar with the basic capabilities and features of security protocols associated with authentication, integrity and privacy. These developers should be highly experienced software architects, advanced programmers, or sophisticated users, who have a strong understanding of public-key infrastructures.

Part 11

This part should be used by Independent Software Vendors (ISVs) who want to develop add-in service modules providing creation and manipulation of digital certificates and certificate revocation lists through the CSSM APIs. These developers should have a strong understanding of:

• One or more digital certificate standards

• Public-key infrastructures

• certification Authority (CA) protocols

• Certificate life cycle services

It is also assumed that these developers are knowledgeable users of cryptographic services.

Part 12

This part should be used by Independent Software Vendors (ISVs) who want to develop CSSM add-in service modules providing persistent storage for security-related objects, such as digital certificates, certificate revocation lists, cryptographic keys, and security policy statements. These developers should have a strong understanding of:

• Underlying storage mechanisms to be used in an implementation

• Traditional database-implementation techniques

• Data server interface protocols

It is also assumed that these developers have a working knowledge of cryptographic services.

Part 13

This part is intended for use by Independent Software Vendors (ISVs) who will develop products that provide key recovery services through the CSSM APIs. These ISVs are highly experienced software and security architects and advanced programmers. They are also familiar with local and foreign government regulations on the use of cryptography and the implication of those regulations for their products.

Trademarks

Motif,® OSF/1,® UNIX,® and the "X Device"® are registered trademarks and IT DialTone^TM; and The Open Group^TM; are trademarks of The Open Group in the U.S. and other countries.

Other product and corporate names may be trademarks of other companies and are used only for explanation and to the owner's benefit, without intent to infringe.

Acknowledgements

The Open Group gratefully acknowledges that this document is the result of a co-operative effort and exchange of ideas of participating industry leaders. The specification was initiated by Intel Architecture Labs, and led to the development efforts of CDSA, having attained the support and participation of organizations such as Entrust, Hewlett-Packard, IBM, Motorola, Netscape, Sun, and Trusted Information Systems, together with the many member organizations of the PKI (Public Key Infrastructure) Task Group, meeting regularly under the auspices of The Open Group.

Referenced Documents

ASN.1

ITU-T Recommendation X.200: Abstract Syntax Notation One (ASN.1).

ITU was formerly CCITT (Comit[??] Consultatif Internationale Telegraphique et Telephonique).

BER

ITU-T Recommendation X.209: Basic Encoding Rules for Abstract Syntax Notation One (ASN.1).

BSAFE

BSAFE Cryptographic Toolkit, RSA Data Security, Inc., Redwood City, CA.

Cryptography

Applied Cryptography, Second Edition, Protocols, Algorithms, and Source Code in C, Bruce Schneier: John Wiley & Sons, Inc., 1996.

Cryptography Usage

Handbook of Applied Cryptography, Menezes, A., Van Oorschot, P., and Vanstone, S., CRC Press, Inc., 1997.

CSSM Java

CSSM Java Application Programming Interface (API) Specification, Intel Architecture Labs, 1996.

DER

ITU-T Recommendation X.690: Distinguished Encoding Rules.

DSA

Federal Information Procurement Standard (FIPS) 186, Digital Signature Standard.

Key Escrow

A Taxonomy for Key Escrow Encryption Systems, Denning, Dorothy E., and Branstad, Dennis, Communications of the ACM, Vol 39, No. 3, March 1996.

OIW

Stable Implementation Agreements, Open Systems Environment Implementors Workshop, June 1995.

PKCS

The Public-Key Cryptography Standards, RSA Laboratories, RSA Data Security, Inc., Redwood City, CA.

SDSI

SDSI: A Simple Distributed Security Infrastructure, R. Rivest and B. Lampson, 1996.

SHA

Federal Information Procurement Standard (FIPS) 180, Secure Hash Algorithm.

SPKI

Simple Public Key Infrastructure, Internet Draft: draft-ietf-spki-cert-structure-03.txt (Expires 26th May 1998).

X.509

ITU-T Recommendation X.509: The Directory - Authentication Framework, 1988.

---

LICENSE AGREEMENT FOR CDSA SPECIFICATIONS

This license agreement is in respect of the compilation of 13 specifications relating to Common Data Security Architecture "(CDSA)" and Common Security Services Manager "(CSSM)", published together by The Open Group under the title "COMMON SECURITY: CDSA AND CSSM", Document Number C707, ISBN 1-85912-194-2 ("the Specification").

YOU CANNOT USE THIS SPECIFICATION ("THE SPECIFICATION") FOR SOFTWARE DEVELOPMENT UNTIL YOU HAVE CAREFULLY READ AND AGREED TO THE FOLLOWING TERMS AND CONDITIONS. THE PERSON WHO ORIGINALLY ACQUIRED THIS PUBLICATION THROUGH THE WORLD-WIDE WEB OR AS HARD COPY EXPLICITLY AGREED TO THESE TERMS AND CONDITIONS. AS THE READER OF THIS DOCUMENT YOU ARE BOUND BY THE SAME TERMS. THE TERMS OF THIS LICENSE AGREEMENT ALSO APPLY TO REVISIONS OF THIS SPECIFICATION MADE AVAILABLE TO YOU BY THE OPEN GROUP.

LICENSE: The Open Group grants you a non-exclusive copyright license to read and display the Specification, and to use the Specification to develop and distribute a conformant software implementation of the Specification on the terms set out in this Agreement. For the avoidance of doubt, this License does not authorize you to edit, republish or distribute the Specification or create any derivative work therefrom.

CONFORMANCE: A software implementation must be and remain a complete and conformant implementation of the CSSM. A conforming implementation of CSSM provides and supports all the application programming interfaces and service provider interfaces defined in the Specification, and for each elective module the implementation must provide and support all the application programming interfaces and service provider interfaces for that module. A software implementation of CSSM may be tested for conformance using the CDSA Conformance Test Suite ("the Test Suite"), available from The Open Group web site. You are not permitted to use the Test Suite for any other purpose, nor to disclose or make any claim that any product has "passed" the Test Suite test. You can not make any claims that your software product conforms to CDSA or CSSM or the Specification unless such product is registered under the Open Brand program.

LIABILITY: THE SPECIFICATION AND ANY OTHER MATERIALS PROVIDED BY THE OPEN GROUP UNDER THIS AGREEMENT ARE PROVIDED "AS IS", AND THE OPEN GROUP MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AND EXPRESSLY DISCLAIMS ANY WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT OF INTELLECTUAL PROPERTY RIGHTS AND FITNESS FOR A PARTICULAR PURPOSE.

TO THE MAXIMUM EXTENT PERMITTED BY LAW, THE OPEN GROUP HEREBY EXCLUDES ALL LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE, ARISING OUT OF OR RELATING TO THE USE BY ANY PERSON OF THE SPECIFICATION OR ANY OTHER MATERIAL PROVIDED HEREUNDER. IN NO EVENT SHALL THE OPEN GROUP BE LIABLE FOR ANY INDIRECT OR CONSEQUENTIAL LOSSES INCLUDING, WITHOUT LIMITATION, ANY LOSS OF PROFITS, CONTRACTS, PRODUCTION OR USE.

TERMINATION OF THIS LICENSE: The Open Group may terminate this license at any time if you are in breach of any of its terms and conditions. Upon termination, you will immediately cease use of the Specification.

APPLICABLE LAW: This Agreement is governed by the laws of England and Wales, and you hereby agree to the non-exclusive jurisdiction of the English courts.

 

[??] Some characters or strings that appear in the printed document are not easily representable using HTML.