X.509 +and PKIX

A certificate consists of a public key together with some identifying information, +all of which is signed with a Certificate Authority's private key. Different +certificate specifications elaborate on this in different ways with varying +syntax, encoding rules and processing requirements.

X.509 is currently the dominant specification and is used by TLS, S/MIME +and IPSEC. In addition to this certificate type the Symbian platform also +provides support for and implements WTLS certificates: this page deals with +X.509, for information on WTLS see WTLS +Certificates.

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.