Overview of the PKIX approach

PKIX, in order to describe public–key infrastructures, uses the terms PKI and PMI. One can find similarities between the two. The main difference is that the PKI handles the Public Key Certificates while the PMI handles the Attribute Certificates. A good metaphor to distinguish between the two is to associate the former with the passport of a person and the latter with the visa. The one provides identity and the other permission.

PKIX standardisation areas

PKIX is working on the following five areas.

  1. Profiles of X.509 v3 Public Key Certificates and X.509 v2 Certificate Revocation Lists (CRLs).

    It describes the basic certificate fields and the extensions to be supported for the Certificates and the Certificate Revocation Lists. Then, it talks about the basic and extended Certificate Path Validation. Finally, it covers the supported cryptographic algorithms.

  2. Management protocols.

    First, it discusses the assumptions and restrictions of the protocols. Then, it provides the data structures used for the PKI management messages and defines the functions that conforming implementations must carry out. Finally, it describes a simple protocol for transporting PKI messages.

  3. Operational protocols.

    Currently they describe how LDAPv2, FTP and HTTP can be used as operational protocols.

  4. Certificate policies and Certificate Practice Statements.

    The purpose of this document is to establish a clear relationship between certificate policies and CPSs, and to present a framework to assist the writers of certificate policies or CPSs with their tasks. In particular, the framework identifies the elements that may need to be considered in formulating a certificate policy or a CPS. The purpose is not to define particular certificate policies or CPSs, per se.

  5. Time–stamping and data–certification/validation services.

    There are no RFCs on these services yet, as the documents are still classified as Internet Drafts.

    The time–stamping services define a trusted third–party that creates time stamp tokens in order to indicate that a datum existed at a particular point in time. The data certification and validation services provide certification of possesion of data and claim of possesion of data, and validation of digitally signed documents and certificates.

The relevant Request For Comments (RFC) documents are depicted in the following table

Table 5-2. Table of RFCs for PKIX documents

Profiles of X.509 v3 Public Key Certificates and X.509 v2 Certificate Revocation Lists (CRLs)RFC 2459
PKIX Certificate Management ProtocolsRFC 2510
Operational protocolsRFC 2559, RFC 2585, RFC 2560
Certificate Policy and Certification Practices Framework RFC 2527
Time–stamping and data–certification services No RFCs yet, only internet drafts available

The specification of the X.509 Certificates is very general and extensible. To ensure interoperability between different Internet-centric implementations, the PKIX Working Group defined a profile, which is a description of the format and semantics of certificates and certificate revocation lists for the Internet PKI.

The operational protocols are the protocols that are required to deliver certificates and CRLs (or status information) to certificate–using client systems. There is an emphasis to have a variety of distribution mechanisms for the certificates and the CRLs, using for example, LDAP, HTTP and FTP. For example, the retrieval of the CRL by a merchant to check whether a certificate is valid, constitutes an operational protocol.

Management protocols are the protocols that are required to support on–line interactions between PKI user and management entities. The possible set of functions that can be supported by management protocols is

The Certificate Policies and the Certificate Practice Statements are recommendations of documents that will describe the obligations and other rules with regard the usage of the Certificate.

Public–key infrastructure functionality

This is a functionality or operations of a Public Key Infrastructure.

Table 5-3. PKI functionality

Key–pair recovery
Key generation
Key update
Key expiry
Key compromise
Cross certification
Certificate and Revocation Notice Distribution and Publication

Public–Key Infrastructure (PKI)

A PKI is a set of hardware, software, people, policies and procedures needed to create, manage, store, distribute and revoke PKCs based on public–key cryptography.

A PKI consists of five types of componets.

Table 5-4. PKI components

Type of componentDescription
Certification Authorities (CAs)to issue and revoke PKCs
Organisational Registration Authorities (ORAs)to vouch for the binding between public keys and certificate holder identities and other attributes
Certificate holdersto sign and encrypt digital documents
Clientsto validate digital signatures and their certification path from a known public key of a trusted CA
Repositoriesto store and make available certificates and Certificate Revocation Lists (CRLs)

In Figure 5-1 there is a simplified view of the architectural model assumed by the PKIX Working Group.

Figure 5-1. PKI Entities

The End–entity, using management transactions, sends its certificate request to the Registration Authority for approval. If it is actually approved, it is forwarded to the Certification Authority for signing. The Certification Authority verifies the certificate request and if it passes the verification, it is signed and the Certificate is produced. To public the Certificate, the CA sends it to Certificate Repository for collection from the End–entity.

The diagram shows that the End–entity can communicate directly with the CA. According to the PKIX recommendations, it is possible to implement the functionality within the CA. Although it is a bit confusing, the diagram shows all possible communications, regardless of the implementation decisions.

Additionally, both the CA and RA are shown to deliver Certificates to the repository. Depending on the implementation, one of the two is chosen.

For the issue of the revocation of the certificates, a similar course with the generation of the Certificates is taken. The End–entity asks the RA to have its Certificate revoked, the RA decides and possibly forwards it to the CA, the CA updates the revocation list and publishes it on the CRL repository.

Finally, the End–entities can check the validity of a specific Certificate using an operational protocol.

Privilege Management Infrastructure (PMI)

PMI is the set of hardware, software, people, policies and procedures needed to create, manage, store, distribute and revoke Attribute Certificates.

A PMI consists of five types of componets.

Table 5-5. PMI components

Type of componentDescription
Attribute Authorities (AAs)to issue and revoke ACs (also called Attribute Certificate Issuer)
Attribute Certificate Usersto parse or process an AC
Attribute Certificate Verifierto check the validity of an AC and then make use of the result
Clientsto request an action for which authorisation checks are to be made
Repositoriesto store and make available certificates and Certificate Revocation Lists (CRLs)

In Figure 5-2 there is a view of the exchanges that may involve Attribute Certificates

Figure 5-2. Attribute Certificate Exchanges

There are two types of attribute certificate distribution as show in the diagram, push and pull.

In some environments it is suitable for a client to push an AC to a server. This means that no new connections between the client and server are required. It also means that no search burden is imposed on servers, which improves performance.

In other cases, it is more suitable for a client simply to authenticate to the server and for the server to request or pull the client's AC from an AC issuer or a repository. A major benefit of the pull model is that it can be implemented without changes to the client or to the client–server protocol. It is also more suitable for some inter–domain cases where the client's rights should be assigned within the server's domain, rather than within the client's domain.