Overview of the PKIX approach

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

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

• registration of entity, that takes place prior to issuing the certificate

• initialisation, for example generation of key–pair

• certification, the issuance of the certificate

• key–pair recovery, the ability to recover lost keys

• key–pair update, when the certificate expires and a new key–pair and certificate have to be generated

• revocation request, when an authorised person advices the CA to include a specific certificate into the revocation list

• cross-certification, when two CAs exchange information in order to generate a cross–certificate

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.

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.

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

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.

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

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.