|Document Number: C707|
©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 Groupor by electronic mail to:
Berkshire, RG1 1AX
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:
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.
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.
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 (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
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.
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:
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.
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 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.
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:
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.
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 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:
Presents the overall CDSA architecture, with emphasis on the Common Security Services Manager. It explains the four-layer architecture as consisting of:
Defines the base application programming interfaces available in all CSSM implementations, as follows:
These are a subset of the APIs that can be supported and available to applications and add-in service modules through the CSSM.
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.
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.
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.
Defines CSSM-internal interfaces for elective module managers. These interfaces include installation, dynamic attach, function registration, and mechanisms for state sharing among module managers.
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.
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.
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.
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.
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.
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.
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.
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:
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:
The intended audience for various parts of the book is summarized here:
It is also assumed that these developers have a working knowledge of signed manifests as digital credentials.
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.
It is also assumed that these developers are knowledgeable users of cryptographic services.
It is also assumed that these developers have a working knowledge of cryptographic services.
Motif,® OSF/1,® UNIX,® and the "X Device"® are registered trademarks and IT DialToneTM; and The Open GroupTM; 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.
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.
ITU was formerly CCITT (Comit[??] Consultatif Internationale Telegraphique et Telephonique).
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.