Previous section.

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

Requirements on a Public-Key Infrastructure

Baseline Requirements for a Global PKI

An interoperable global Public-Key Infrastructure (PKI) is required to provide privacy and digital signature services in support of international commerce, balancing the legitimate needs of commerce, governments, and privacy of citizens. The global PKI must support multiple governance policy models within a single global PKI framework, and must enable the enforcement of all existing governance policy mandates.

Required Services

Required Functionality and Characteristics

Key Lifecycle Management

The actual lifecycle of a key depends on whether it is used for confidentiality or signature purposes. Key lifecycle facilities to be supported are:

  1. Key Generation Facility

    The method of key generation shall be discretionary, subject to commercial decision and business requirement. Selection of key quality, uniqueness, secrecy, and recoverability of keys must be left to the discretion of the organization generating the keys (and any governance authorities to which it is subject).

  2. Key Distribution, Revocation, Suspension, Repudiation, and Archive

    The PKI must support the following functionality:

  3. Key Recovery Facilities

    The PKI shall specify key recovery functionality for use in environments which require such functionality. This document takes no position on key recovery policy issues. Implementations of the PKI may omit key recovery functionality, or may disable its use, in environments in which it is not required. PKI implementations which provide key recovery functionality should do so using the interfaces and/or protocols specified herein. Key recovery facilities shall provide the following functionality:

Distributed Certificate Management Structure

The PKI must provide distributed Certificate Management functionality, driven by the requirements of the transaction or business domain. The following Certificate Management functions must be provided by the PKI:

  1. Policing and policy enforcement (governance model), including the following:

  2. Concurrent support of multiple policies

  3. Exchange of certificates

  4. Support for continuance of service in the event of transfer of certificate services from one CA to another

  5. CA policy mapping services to establish cross-certification between CAs

  6. Support for arbitration to determine acceptability of certificates in the event of multiple conflicting certification paths

  7. Support for separation of the CA and repository functions in accordance with the governance policy-changes to certificate repositories must be transactional (for example, two-phase commits)

Security of the PKI

The PKI itself must be secure. In particular, the PKI must:

  1. Protect the confidentiality, integrity, and availability of the PKI services; for example, key generation, key distribution, and key storage

  2. Provide strong non-repudiation services for actions of certificate services

  3. Prevent PKI services themselves from repudiating their own actions

  4. Prevent users and subscribers from repudiating their own actions

Time Service

A universal, networked time service must be available for time stamping.

Interoperability

PKI elements provided by different vendors must interoperate. In support of interoperability, PKI elements must:

  1. Support international standards for certificates and associated data

  2. Support international standards for certificate services

  3. Support internationalization of all certificates and associated data

  4. Support internationalization of all certificate services

Known Issues

For interoperability there is a dependency upon the definition of standard APIs to and protocols between the component services of the PKI.

Work is required to define and agree profiles of option fields in certificates.

Recommendations

Adopt X.509v3 as a basis for certificates in the development of the PKI.

Adopt and adapt existing standards and protocols wherever possible; invent new standards or protocols only as a last resort. In particular, adopt the service interfaces defined in CDSA, Version 2.0 and the protocols defined in the PKIX series of IETF draft standards.

The Importance of Architecture

The PKI Task Group feels that a robust, flexible, standard, open PKI Architecture is critical to the success of secure systems based on public-key technology. This section explains why.

What is Architecture?

The architecture of a software system is the set of interfaces through which its functions are accessed, and the set of protocols through which it communicates with other systems.

The remainder of this section discusses the importance of standardizing the interfaces and protocols which comprise the PKI Architecture.

Protocols

Figure: Protocols in Certificate Management

Protocols in Certificate Management illustrates two Certificate Management products:

A configuration including both products would have several bad characteristics:

This example illustrates the benefit of standard protocols:

Interfaces

Figure: Example Security Products

Example Security Products illustrates a system on which three security products have been installed:


This configuration has several bad characteristics:

The benefits of using standard interfaces include:

Profiles

Many of the services in the PKI Architecture can be implemented using a variety of different mechanisms and protocols (for example, data privacy protection can be implemented using a variety of different cryptographic algorithms). This variety of mechanisms and protocols has arisen in part because different environments impose different security requirements.

Multiplicity of mechanisms means that different providers' implementations of the PKI Architecture will not necessarily interoperate-even though they support the standard interfaces and a selection of the standard protocols.

A profile defines the set of mechanisms and protocols which should be used in a particular environment. The mechanisms and protocols comprising a profile are usually chosen on the basis of their strength against the attacks which are common in the environment supported by the profile. Profiling has the following advantages:

Negotiation

Some profiles will allow multiple mechanisms and protocols in order to support different qualities of protection, or to accommodate a fragmented security product market. In these environments, it is desirable to provide a negotiation meta-protocol which allows communicating partners to determine:

Note:
It is important to note that negotiation does not always require an on-line dialog between the negotiating entities.

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