Each of the following sections describes one of the PKI Architecture's
categories in detail, enumerating its components, and describing
component functions, interfaces, and protocols.
System functions (for example, operating system functions) are needed to support user logon, user credential acquisition, and association of security state information with user processes and threads. For example, once a user has acquired credentials by authenticating himself to a Smartcard, that user's processes should be able to use the Smartcard interface to sign data using a private key stored on the Smartcard. This will only be possible (and secure) if the system has maintained security state information associating the user's processes with the handle returned when the user authenticated himself to the Smartcard.
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.
These components provide access to low-level cryptographic primitives such as key generation, hash function application to a data buffer, encryption of a data buffer using secret-key or public-key algorithms, decryption of a data buffer using secret-key or public-key algorithms, and so on.
Cryptographic primitives are typically called locally; it is not anticipated that any cryptographic primitive protocols will be defined.
Candidate interfaces for access to cryptographic primitives include:
Other interfaces which may support some or all of the cryptographic primitive function include:
Standardization of these interfaces would be of interest to developers of cryptographic service modules and to providers of cryptographic primitive modules. Standardization of an interface for access to cryptographic primitives would facilitate "pluggable" implementations of cryptographic services. The consensus of the PKI Task Group, however, is that cryptographic functionality will ordinarily be used through the cryptographic service interfaces rather than through the cryptographic primitive interfaces.
Recommendation: Standardization of cryptographic primitive
interfaces is not viewed as essential. However, the PKI Task Group
recommends the use of CSSM from CDSA, Version 2.0.
Applications request security services through the CSSM Security API, or layered security services and tools implemented over the CSSM API. The requested security services are performed by add-in security modules. Four basic types of module managers are defined:
CSSM supports elective module managers that dynamically extend the system with new categories of security services providing for future extensibility. See CDSA, Version 2.0 for further details.
Most cryptographic modules provide support for multiple primitives. Many primitives are subject to legal restrictions on deployment (including both intellectual property encumbrances and national and international regulatory constraints on export, import, and deployment).
Cryptographic primitive profiles will have to be developed for PKI environments of interest (including, for example, the Internet, OMG CORBA, OSF DCE, Financial, and so on).
Cryptographic primitives are ordinarily used only by the implementors of cryptographic services. Negotiation should be used to establish which cryptographic service(s) from which provider are to be used, rather than to establish which primitives should be used. Ordinarily this negotiation is done at a higher level than that of the cryptographic primitives and services themselves. No protocol for negotiating cryptographic primitives should be required.
These components provide access to cryptographic services such as data integrity and confidentiality protection ("data" here might be a file, a message, an I/O stream, and so on), key import and export, digital signature, keyed hash, and so on.
Cryptographic context management provides the facilities through which applications initialize the cryptographic subsystem, activate keys for encryption and decryption, and clean up the state of the cryptographic subsystem after use.
Key usage controls permit control over a variety of aspects of key use, including how many times a key may be used, for what purposes it may be used (for example, for signature only, for confidentiality only, for both signature and confidentiality), and so on.
Key derivation services permit generation of cryptographic-quality keys from non-key values such as passwords.
Cryptographic services are built on cryptographic primitives. A cryptographic service may support multiple implementations, each of which uses a different cryptographic primitive.
Descriptions of a few Data Encryption Standard (DES)-based services will illustrate the difference between primitives and services; note that these are only examples:
Cryptographic services are typically called locally; it is not anticipated that any cryptographic service protocols will be standardized.
Candidate interfaces for cryptographic services include:
Other interfaces which may support some or all of the cryptographic primitive function include:
Standardization of these interfaces would be of interest to developers of long-term key service and protocol security service modules, and to providers of cryptographic service modules.
Recommendation: 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.
Most cryptographic modules provide support for multiple services. Many cryptographic services are subject to legal restrictions on deployment (including both intellectual property encumbrances and national and international regulatory constraints on export, import, and deployment).
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
Profiles will need to specify, in addition to mechanism information, the data formats which each service can accept and return.
Negotiation of cryptographic services to be used by secure protocols and other security-aware applications is generally done at a level higher than that of the cryptographic services themselves. The cryptographic service interface therefore must allow selection among available cryptographic services, and among available implementations of a single service, but it need not support negotiation.
The functions this component provides include key generation, certificate request, key revocation, key repudiation, key expiration, and related services.
This component supports preparation of keys for recovery, and permits later recovery under policy control.
The Virtual Smartcard service component permits users and other principals to store long-term personal security information (including private keys, certificates, and other information) in protected storage, to activate personal keys for use via an authentication procedure, and to use those keys for encryption, decryption, and signature activities.
The Virtual Smartcard service is still subject to debate and therefore
a detailed discussion of this service component is deferred to
The Certificate Management component allows users, administrators, and other principals to request certification of public keys and revocation of previously certified keys. It may optionally generate key pairs and provide key-pair recovery services. There are four Certificate Management sub-components:
This component allows a program to retrieve any principal's certificate, verify its validity, and extract the principal's certified public key from the certificate.
Key Lifecycle Management is supported by the following IETF PKIX specifications:
Key Recovery request and response formats are defined in:
Key request/response protocols are defined in:
The Virtual Smartcard service is still subject to debate and therefore
a detailed discussion of this service component is deferred to
Protocols must be defined to permit creation, revocation, and
refreshment of certificates.
The PKI Task Group recommends that the following protocols should be standardized at a minimum:
Recommendation: In order to standardize the relevant PKI Architecture Certificate Management protocols, the PKI Task Group endorses the use of the following IETF PKIX specifications:
Protocols must be defined to transport certificates and CRLs from the repositories in which they reside to the requester's machine. In the diagram, these protocols are represented by the arrows from the Publication Authority to the public-key Delivery and Verification component (Protocols C, D, and E). The PKI Task Group recommends that these protocols should be standardized. At least LDAP, email, and HTTP versions of these protocols should be defined.
Candidate protocol draft specifications have been published as follows:
Recommendation: In order to standardize the relevant PKI Architecture Public Key Delivery and Verification protocols, the PKI Task Group endorses the use of the following IETF PKIX specifications:
Readers are referred to the latest versions of the PKIX work accessible at http://www.ietf.org/ids.by.wg/pkix.html.
Candidate interfaces for this component include:
Recommendation: 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).
Candidate interfaces for this component include:
Recommendation: 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 Virtual Smartcard service is still subject to debate and therefore
a detailed discussion of this service component is deferred to
Candidate interfaces for this component include:
Other interfaces which may support some or all of the public-key Delivery and Verification function include:
Recommendation: The PKI Task Group recommends that the public-key Delivery and Verification interface should be standardized. The PKI Task Group endorses the CSSM API (from CDSA, Version 2.0), as the base document for this interface standard.
Candidate interfaces for this component include:
Other interfaces which may support some or all of the Certificate Management function include:
Recommendation: 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.
It is anticipated that multiple CAs will exist in typical PKI environments; individual servers may require the use of certificates with specific properties (signing CA, supported extensions, name format, and so on). Profiles for certificate format, contents, extensions, and policy will be needed for PKI environments of interest, including the Internet, Financial Industry, Credit Card Industry (for use with SET), Government, and Healthcare Industry environments.
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.
It is not anticipated that any of the long-term key services components will require negotiation protocols. The Certificate Management interfaces will need to provide a mechanism through which callers can identify which CA should issue certificates and CRLs requested through its interface, in case more than one CA is available.
The Virtual Smartcard service interface will need to support selection of user/principal certificates for environments in which users have more than one certificate.
Protocol security services are divided into two fundamental classes:
These components provide security services appropriate for use by designers of protocol stacks. Specifically, these components:
The PKI Task Group believes that multiple protocol security services will continue to be required to meet the needs of diverse environments. Therefore, no single standard for session-oriented, store-and-forward, or non-repudiation protocol security services is proposed. The protocol security services component interfaces will need to provide negotiation (for environments in which more than one service is available), and protocol security service profiles will have to be established for PKI environments of interest.
A wide variety of protocol security services can be used to provide security for session-oriented protocols; examples which are described in existing or proposed Internet standards include SPKM (which is public-key based-see IETF RFC 2025: The Simple Public-Key GSS-API Mechanism (SPKM)), Kerberos (which is secret-key based), and SESAME (which has public-key, secret-key, and hybrid variants). Some of these services define their own protocols for run-time access to on-line security servers of a variety of types. All of them define formats for protected message tokens to be transported by their callers.
Only a few protocol security services suitable for protection of store-and-forward protocol messages have been defined. The IDUP (see IETF RFC 2479: IDUP-GSS-API) and SESAME services are proposed for Internet standardization. Both of these services define formats for protected message tokens to be transported by their callers.
These services must define formats for non-repudiation evidence tokens to be transmitted along with notarized data, and protocols implementing non-repudiable delivery and non-repudiable receipt.
Recommendation: The PKI Task Group recommends that all of the protocol security services interfaces should be standardized.
The structure of the protocol security services is illustrated in
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.
Recommendation: In addition to the interfaces described above, 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.
Other interfaces which may support some or all of the protocol security services functionality include:
GSS-API and IDUP GSS-API are capable of supporting multiple security mechanisms; each API also allows selection of a wide range of qualities of data protection (for example, strength of supported confidentiality protection, delegation mode, and so on) for each supported security mechanism.
Profiles will have to be developed to describe the set of preferred mechanisms and data protection quality parameters for PKI environments of interest. The PKI Task Group is not aware of a draft profile in this area.
Because they will be deployed in environments which require and provide multiple data protection mechanisms, the protocol security services interfaces will need to support negotiation (of both protection mechanisms to be used and quality of protection to be applied).
A negotiation mechanism for GSS-API has been proposed and is described in IETF RFC 2478: The Simple and Protected GSSI Negotiation Mechanism.
There are many kinds of secure protocol, of which three important categories are:
Secure protocols provide protected data transfer between communicating partners without requiring any calls to security services. Applications using secure protocols may have to specify a desired quality of protection before initiating a secure protocol exchange.
Examples of PKI-secured protocols include:
Each secure protocol typically has its own interface. IETF RFC 2025: The Simple Public-Key GSS-API Mechanism (SPKM) gives an API for connection-oriented peer-to-peer services.
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.
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 manage information about users' (and other principals') privileges and resource access control policies, and make access control decisions based on that information.
An access request is mediated by the Access Control Enforcement Function (AEF). The AEF invokes the Access Decision Function (ADF) which makes a decision on the basis of the Access Decision Information (ADI) supplied to it by the AEF, or retrieved by the ADF from the processing context. The access decision is returned to the AEF which is responsible for enforcing the decision.
The ADI associated with a user principal is a subset of the privilege attributes assigned to the principal as part of user information management or associated with the principal through a process of delegation during operational use.
The privilege attribute service provides the functionality for the retrieval of ADI associated with a principal. Within a PKI Architecture, the ADI will be supplied in the form of privilege attribute security tokens.
There are two models of interaction with the privilege attribute service:
The target service is responsible for verifying the authenticity of the
supplied token. See
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.
It is not anticipated that the Internet PKI will define interfaces to privilege attribute services or access control services.
Work is currently underway within The Open Group on authorization services, and these may be the subject of future revisions to this document or associated architecture documents.
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.
These components provide functions required by the security services or required for secure operation of a networked system; however, they do not enforce security policies.
The security auditing services support accountability within the PKI Architecture and may also support notarization services.
The time service is fundamental to the synchronization of time within a distributed PKI Architecture and the basis of time stamps that may be incorporated into security certificates and also be used by a notarization service.
Directory services are necessary to support the location of PKI Architecture users and components and the retrieval of attributes applicable to them.
Effective security auditing within a PKI Architecture requires the collection and analysis of security audit records from all components of the PKI Architecture. A standard protocol is needed to support a distributed security audit service between components of the PKI Architecture.
Recommendation: The Distributed Audit Service (XDAS) specification defines an API as well as a common audit record format that is applicable.
A distributed time service needs a standard protocol to be defined to support the distribution and synchronization of time between the components of PKI.
Recommendation: 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.
Protocols are needed to support the enquiry and retrieval of principal identities and attributes within the PKI Architecture. There are a number of candidate protocols:
Recommendation: 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.
An interface standard is required to enable components of the PKI Architecture to submit security audit records for security events they detect within their own operations. An interface standard is also required to support the development of applications for the collation and analysis of security audit records from all the components of the PKI Architecture.
Recommendation: It is recommended that the Distributed Audit Service (XDAS) specification 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.
Recommendation: It is recommended that the C LDAP Application Program Interface is used as the interface to directory services.
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 LDAP. See http://www.opengroup.org/ldap.
| Contents | Next section | Index |