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

• Establishment of domains of trust and governance

• Confidentiality (sealing)

• Integrity and authentication (signing)

• Non-repudiation

• End-to-end monitoring, reporting, and auditing of PKI 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:

   • Facilities for the distribution of keys to appropriate storage devices and directories

   • Ability of a Certification Authority (CA) to revoke certificates for individual keys under the terms of the applicable policy

   • Ability of a CA to suspend and reactivate certificates for individual keys under the terms of the applicable policy

   • Ability of a CA to force delivery of revocation, suspension, and reactivation notices

   • Facilities to enable a user to repudiate his public key under the terms of the applicable policy

   • Facilities to enable a user to suspend and reactivate his public key under the terms of the applicable policy

   • Facilities to enable the user and subscriber to retrieve revocation, suspension, and reactivation notices

   • Facilities to enable the user and subscriber to determine the status (for example, revoked or suspended) of a specific certificate

   • Facilities to enable the archive and subsequent retrieval of certificates in support of the retrieval and verification of long-term information in accordance with governance policy

   • Warranted retrieval-the PKI must support implementations which enable the following warranted retrieval scenarios:

     • Law enforcement retrieval (subject to policy conditions)

     • Corporate agency retrieval (subject to policy and authorizations)

     • Individual retrieval (subject to policy and authorizations)

     The following functionality is required in support of warranted retrieval:

     • An electronic vehicle for the delivery of a notarized electronic warrant, to support the automation of key retrieval under due process (this must be able to take advantage of existing legal agreements)

     • A permanent, non-repudiable, and independently verifiable record of key retrieval operations must be maintained

     Note:

     Warranted retrieval policy includes policy regarding disclosure or non-disclosure of key retrieval to the owner of the retrieved key.

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:

   • Use of key recovery facilities implies acceptance of a mandatory policy for the protection and recovery of keys. The policy defines how the keys are to be protected and under what conditions and to whom a key will be made available. The mandatory aspect of policy arises as the operations of a key recovery facility may be regulated by legislation or procedures required under commercial contracts for liability management.

   • It must be possible to ensure that only key recovery-enabled systems shall be usable within a PKI implementation, where this is required.

   • A key recovery facility shall be unconditionally trusted and be liable to uphold the stated policy with redress for loss arising from failures to uphold policy through contractual liability and penalties.

   • A key recovery center shall be able to verify the legitimacy of a key submitted to it for storage.

   • A user of a key recovery repository shall be able to verify that it is an authorized repository.

   • The PKI shall provide for coordination between the management of public and private keys in the PKI and in data recovery centers.

     Note:

     Public and private key parts do not have the same lifecycle and key parts may be archived.

   • The PKI shall support aging, revocation, and repudiation of keys.

   • The PKI shall support discretionary key fragmentation between key recovery facilities.

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:

   • Policy creation and maintenance; the policies include those covering key generation, key recovery, key distribution, revocation, suspension, repudiation, archive, and warranted retrieval.

   • Ability to register a key and the binding between the key and a name.

   • Ability to query which keys are bound to a name.

   • Policies (for services built on PKI access control) must not be required to be based on individual identity.

   • Certification of the binding between a public key and a directory name shall be mandatory.

   • Certification of the binding between additional attributes and a directory name shall be discretionary.

   • Auditing and support for the monitoring of policy compliance is required.

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

Protocols in Certificate Management illustrates two Certificate Management products:

• Product 1 communicates key requests to the CA via electronic mail, and receives keys and certificates from the CA via electronic mail.

• Product 2 communicates key requests to the CA using a proprietary protocol and retrieves keys from a directory service using the LDAP protocol.

A configuration including both products would have several bad characteristics:

• Neither product's CA could accept key requests from the other product's clients.

• Applications using product 1 clients and wishing to advertise their certificates in the directory service would require installation of a separate directory-access product.

• Applications using product 1 clients and wishing to retrieve partners' certificates from the directory service would require installation of a separate directory-access product.

This example illustrates the benefit of standard protocols:

• Applications supporting standard protocols can interoperate, even if produced by different providers.

Interfaces

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

• Product 1 includes a protocol and all the security functionality needed to protect data flowing over that protocol. Only the secure protocol's interface is exposed; the underlying security functionality is not available to other applications.

• Product 2 also includes a protocol and its requisite security functionality, but it exposes the data protection functionality through a public interface so that other applications can use it. It does not permit direct access to cryptographic functionality.

• Product 3 is a hardware cryptographic adapter; it comes with a software driver permitting access by applications to its cryptographic functionality.

This configuration has several bad characteristics:

• Because neither product 1 nor product 2 accesses cryptographic functionality through a standard interface, neither can use the cryptographic adapter. Furthermore, because both product 1 and product 2 embed cryptographic functionality without exposing an interface through which it can be accessed, neither can use the other's cryptographic software. The end result is that three different cryptographic subsystems (two software and one hardware) must be installed on the system, even if all three products use the same cryptographic algorithms!

• Because product 1 and product 2 embed cryptographic functionality rather than accessing a separate cryptographic subsystem through a published interface, they will not be deployable (without code changes) in countries whose regulatory environment restricts or forbids use of the cryptographic functions they embed.

The benefits of using standard interfaces include:

• Replaceability of services (for example, cryptography) without change to exploiting applications

• Elimination of duplicate service implementations in configurations in which multiple applications require the same kind of service

• Reduced programmer training costs (programmers need learn only one standard interface for a service rather than learning the proprietary interfaces of multiple products providing the same service)

• Reduced application porting complexity (code exploiting services through standard interfaces need not be changed, or requires only minimal changes, when porting from one platform supporting the standard interface to another such platform)

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:

• Systems conforming to an environment's profile will interoperate.

• Systems conforming to an environment's profile will be well-protected against that environment's risks.

• Profiling helps to assure that mechanisms in use work together appropriately and securely.

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:

• Which mechanisms and protocols they both (or all) share

• Which mechanism and protocol, among the shared set, best supports the desired quality of protection

Note:

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