PKI Architecture and Summary of Recommendations

PKI Architecture Overview

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

• System Security-enabling Services provide the functionality which allows a user's or other principal's identity to be established and associated with their actions in the system.

• Cryptographic Primitives and Services provide the cryptographic functions on which public-key security is based (including secret-key primitives, such as the Data Encryption Standard (DES)).

• Long-term Key Services permit users and other principals to manage their own long-term keys and certificates and to retrieve and check the validity of other principals' certificates.

• Protocol Security Services provide security functionality (data origin authentication, data integrity protection, data privacy protection, non-repudiation) suitable for use by implementors of security-aware applications, such as secure protocols.

• Secure Protocols provide secure inter-application communications for security-unaware and "mildly" security-aware applications.

• Security Policy Services provide the policy-related information which must be carried in secure protocols to enable access control, and provide access control checking facilities to security-aware applications which must enforce policy.

• Supporting Services provide functionality which is required for secure operation, but is not directly involved in security policy enforcement.

PKI Architecture Overview illustrates the PKI Architecture:

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:

• IETF RFC 2511: Internet X.509 Certificate Request Message Format

• Internet X.509 Public Key Infrastructure Certificate Management Message Formats

• IETF RFC 2510: Internet X.509 Public Key Infrastructure Certificate Management Protocols

• Certificate Management Messages over CMS

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:

• Internet X.509 Public Key Infrastructure Online Certificate Status Protocol

• Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP

• Internet X.509 Public Key Infrastructure Operational Protocols: LDAPv2

• Internet X.509 Public Key Infrastructure LDAPv2 Schema

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:

• CA Agent

• Local Registration Authority

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

• The preferred interface for session-oriented protocol security services is IETF RFC 2078: The GSS-API, Version 2. (The C bindings for this specification are defined in Generic Security Service API, Version 2: C Bindings.)

• The preferred interface for store-and-forward protocol security Services is IETF RFC 2479: IDUP-GSS-API.

• The preferred interface for non-repudiation services is IETF RFC 2479: IDUP-GSS-API.

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 CORBASEC¹ 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.