Architecture for Public-Key Infrastructure (APKI)
Copyright © 1998 The Open Group
<!bookmarks # BOOKMARKF>
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
Establishment of domains of trust and governance
Integrity and authentication (signing)
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
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).
Key Distribution, Revocation, Suspension, Repudiation, and Archive
The PKI must support the following functionality:
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
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.
- 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
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
Policing and policy enforcement (governance model), including the
Policy creation and maintenance;
the policies include those covering key generation, key recovery, key
distribution, revocation, suspension, repudiation, archive, and
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
Concurrent support of multiple policies
Exchange of certificates
Support for continuance of service in the event of transfer of
certificate services from one CA to another
CA policy mapping services to establish cross-certification between CAs
Support for arbitration to determine acceptability of certificates in
the event of multiple conflicting certification paths
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:
Protect the confidentiality, integrity, and availability of the PKI
services; for example, key generation, key distribution, and key
Provide strong non-repudiation services for actions of certificate
Prevent PKI services themselves from repudiating their own actions
Prevent users and subscribers from repudiating their own actions
A universal, networked time service must be available for time stamping.
PKI elements provided by different vendors must interoperate. In
support of interoperability, PKI elements must:
Support international standards for certificates and associated data
Support international standards for certificate services
Support internationalization of all certificates and associated data
Support internationalization of all certificate services
For interoperability there is a dependency upon the definition of
standard APIs to and protocols between the component services of the
Work is required to define and agree profiles of option fields in
Adopt X.509v3 as a basis for certificates in the development of
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
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.
Figure: Protocols in Certificate Management
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
A configuration including both products would have several bad
Neither product's CA could accept key requests from the other product's
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.
Figure: Example Security Products
Example Security Products
illustrates a system on which three security products have been
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
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
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)
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
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.
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
- 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.