X.509 and PKIX

The need for profiles in X.509

The X.509 specification alone is not restrictive or specific enough to form the basis of an implementation of a certificate management component. Realisation of this fact has led to the creation of a set of mostly incompatible profiles.

While X.509 defines an extensible syntax for all the data structures required to perform certificate management, a profile adds three things:

• a restriction on the sorts of data structures that an implementation is required to understand

• a requirement that certain specific sorts of data structure be present, so an implementation may rely on their presence

• a clear definition of the behaviour of a certificate management component, that is, a specification of what it is supposed to do with the data structures involved

The best example of this is seen in certificate extensions. X.509 defines the syntax of a series of extension types, and permits new extensions to be defined using object identifiers. It does not require the presence of any extensions and does not clearly indicate what it means to support a particular extension. Thus an implementation cannot know which extensions will be present, or exactly what to do with them. A profile like PKIX defines a set of extensions that a PKIX-compliant certificate management component must be able to deal with, which extensions can be assumed to be present, and a definition of what it means to deal with them.

The distinction between X.509 and its profiles is largely one of syntax versus behaviour: X.509 defines the syntax of the objects, and the profile defines how the presence and values of objects affects the behaviour of certificate management. In addition, a profile may define extra pieces of syntax, specific to the application for which it is designed.

Profile support in Certman

Certificate Management implements X.509 along with one profile, the PKIX profile, defined in RFC 3280. Its design attempts to incorporate the distinction between X.509 and its profiles, enabling further additions to be made to the X.509 part without affecting any profiles, and enabling further profiles to be defined without affecting the X.509 specific part.

The decision to use a particular profile rests with the application.

All general classes defined in X.509 are prefixed with 'X509', all profile specific classes are prefixed with the name of the profile.

X.509 specific part

The X.509 certificate itself and the generic extension object are both clearly part of X.509 itself.

The generic extension object is simply an ASN1 'any defined by' structure, with accessors for its OID and its encapsulated data.

The X.509 certificate provides a function that, given a particular OID, returns a pointer to a particular extension object or NULL if the extension is not present. It also provides functions to verify its signature, given a key, and return the various data members that X.509 requires, such as its subject and issuer DNs. However, it does not provide accessors for any particular extensions (for example there is no KeyUsage() function, since it cannot be assumed that key usage is present).

A generic certificate chain object is also provided; this simply has a set of X.509 certificates, provides accessors to them and implements a function to decode a set of certificates from DER encoded ASN.1.

Specific extension classes are in a bit of a no-man's land. This is because many of them are defined by X.509, but more can be added by any profile, and a profile will require the use of a particular set of extensions. So, all the extensions used by PKIX in X.509 have been implemented on the assumption that they are likely to be useful for other profiles, however, profiles are free to define extra extensions. Since these extension classes are implemented in X.509, they only define the syntax of the extension, not the way it should be used. Because they are radically different they do not share a common base class.

Profile specific part

The profile specific part defines two significant public classes:

• PKIX certificate chain object

  This is main class which encapsulates path processing in the PKIX profile. Thus it defines which extensions are required, which extensions are understood, and how they are understood.

• PKIX validation result object

  This is constructed by the chain object in the course of validation and handed to the client to examine.

These classes are described in more detail in Certificate validation in PKIX ; the validation process discussed there is PKIX specific.