Previous section.

Architecture for Public-Key Infrastructure (APKI)
Copyright © 1998 The Open Group

PKI Architecture and Summary of Recommendations

PKI Architecture Overview

The PKI Architecture components are grouped into the following broad functional categories:

PKI Architecture Overview illustrates the PKI Architecture:

Figure: PKI Architecture Overview

Public-Key Infrastructure Components describes each of these categories in more detail (listing the components in each category), and identifies interfaces and protocols which may be candidate bases for standardization of each component.

Note:
While the architecture described in this document could be implemented on insecure operating system platforms, implementors of the architecture must ensure that keys, security context data, and policy data are appropriately protected in such environments.

Summary of Recommendations

System Security-Enabling Services

It is not anticipated that the Internet PKI will define any interfaces, protocols, profiles, or negotiation mechanisms in the area of system security-enabling services.

Cryptographic Primitives

Protocols
N/A.

Interfaces
Standardization of cryptographic primitive interfaces is not viewed as essential. However, the use of CSSM from CDSA, Version 2.0 is recommended.

Profiles
Profiles need to be developed for PKI environments of interest.

Negotiation
N/A.

Cryptographic Services

Protocols
N/A.

Interfaces
The PKI Task Group believes that it is important to standardize a single interface for cryptographic services, and recommends that CSSM from CDSA, Version 2.0 be chosen as the basis for the standard.

Profiles
Cryptographic service profiles will have to be developed for PKI environments of interest (including, for example, the Internet, OMG CORBA, OSF DCE, Financial, and so on). These profiles will have to be developed with international deployment issues in mind. Each profile should be expressed in terms of the parameters used to select cryptographic services (and implementations of cryptographic services, often called "mechanisms") through the cryptographic service interface (see Negotiation for more information on service and mechanism selection).

Negotiation
N/A.

Long-Term Key Services

Protocols
The PKI Task Group endorses use of the IETF PKIX management protocols as the basis for standardization of the relevant PKI Architecture Certificate Management protocols. These IETF PKIX specifications are:

The PKI Task Group endorses use of the IETF PKIX operational protocols as the basis for standardization of the relevant PKI Architecture Public-Key Delivery and Verification protocols. These IETF PKIX specifications are:

Interfaces
The PKI Task Group recommends that the Key Lifecycle Management interface should be standardized and endorses the use of CSSM from CDSA, Version 2.0.

The PKI Task Group recommends that the Key Recovery interface should be standardized and endorses the use of the CSSM Key Recovery API from CDSA, Version 2.0.

The PKI Task Group recommends that the Public-Key Delivery and Verification interfaces should be standardized. The PKI Task Group endorses the CSSM API from CDSA, Version 2.0 as the base document for this interface standard.

The PKI Task Group recommends that the following Certificate Management interfaces should be standardized at a minimum:

The PKI Task Group endorses the CSSM API from CDSA, Version 2.0 as the base document for this interface standard.

Specification of the Publication Authority interface would also be useful to providers of repositories and communications protocols who wish to make their products available as certificate and CRL transmission media; a standard Publication Authority interface would allow them to provide Publication Authority services without requiring changes to CA Agent code.

Profiles
A profile (for the Internet PKI environment) for certificate format, contents, and extensions exists as IETF RFC 2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile.

A policy profile for the Internet PKI environment has been published as IETF RFC 2527: Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework.

Negotiation
N/A.

Protocol Security Services

Protocols
Multiple protocols will continue to be required. Therefore no single standard is proposed in this area.

Interfaces

In addition to these interfaces, the PKI Task Group recommends that interfaces for protection mechanism negotiation and privilege and delegation management should be standardized. The preferred interfaces for these services are IETF RFC 2478: The Simple and Protected GSSI Negotiation Mechanism and IETF CAT XGSS-API, respectively.

Profiles
Profiles will need to be developed, but the PKI Task Group is not aware of any such profiles that have been defined.

Negotiation
A negotiation mechanism for GSS-API has been proposed and is described in IETF RFC 2478: The Simple and Protected GSSI Negotiation Mechanism.

Secure Protocols

Protocols
The IETF IPsec Working Group has produced work on secure protocols, notably IPsec (see Referenced Documents) and IKE (see IETF RFC 2409: The Internet Key Exchange (IKE)).

Interfaces
Each secure protocol typically has its own interface.

Profiles
It is not yet clear whether profiles will be established for which Web transaction security protocols (for example, SHTTP, HTTPS, HTTP-over-GSS-API, and so on) should be used in which contexts.

Negotiation
The PKI Task Group considers that negotiation of secure protocols is outside the scope of the PKI (or even Security Infrastructure) effort.

Security Policy Services

Protocols
Formats for privilege attribute tokens to be transported within secure protocols will need to be standardized. The most prominent existing privilege attribute format definitions today are those defined by ANSI X9, OSF DCE, SESAME, and the OMG CORBASEC1 standard. Privileges could be carried in X.509v3 certificate extensions, or in separate privilege attribute tokens.

Interfaces
It is not anticipated that the Internet PKI will define interfaces to privilege attribute services or access control services.

Profiles
Interoperation of systems in differing security management domains will require standardization of privilege attribute types and of the semantics of values of those types. No proposed standard profile for privilege attributes exists today.

Negotiation
N/A.

Supporting Services

Protocols
The Distributed Audit Service (XDAS) specification defines an API as well as a common audit record format that is applicable.

It is recommended that IETF RFC 2030: Simple Network Time Protocol (SNTP) is adopted as the time service protocol for use within the PKI Architecture.

It is recommended that IETF RFC 2251: Lightweight Directory Access Protocol, Version 3 (LDAPv3) is used as the basic directory service protocol within the PKI Architecture.

Interfaces
It is recommended that the XDAS Distributed Audit Service API is adopted as the security auditing service API.

Components of the PKI Architecture will access time via the interface provided by the supporting operating system.

It is recommended that the C LDAP Application Program Interface is used as the interface to directory services.

Profiles
Profiles are currently not defined in the areas of audit and time services. Profiles for directory-based services are being developed within both The Open Group and IETF based upon the LDAP protocol. See http://www.opengroup.org/ldap.

Negotiation
N/A.


Footnotes

1.
Further information about OMG and CORBA can be found at: http://www.omg.org.


Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents Next section Index