<?xml version="1.0" encoding="utf-8"?>

<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

<!-- This component and the accompanying materials are made available under the terms of the License 

"Eclipse Public License v1.0" which accompanies this distribution, 

and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

<!-- Initial Contributors:

    Nokia Corporation - initial contribution.

Contributors: 

-->

<!DOCTYPE concept

  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

<concept id="GUID-C676C4E6-93AF-59E9-886D-74D59F154490" xml:lang="en"><title>X.509

and PKIX</title><prolog><metadata><keywords/></metadata></prolog><conbody>

<p>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. </p>

<p>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 <xref href="GUID-A636C1B3-8AB2-52D7-BB19-4CC93F4BDD97.dita">WTLS

Certificates</xref>. </p>

<section><title>The need for profiles in X.509</title> <p>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. </p> <p>While X.509

defines an extensible syntax for all the data structures required to perform

certificate management, a profile adds three things: </p> <ul>

<li id="GUID-5399F944-9BDA-5325-9E0D-93F189287A13"><p>a restriction on the

sorts of data structures that an implementation is required to understand </p> </li>

<li id="GUID-9276E4DF-0B64-5D16-A9A0-CD7D58E67F09"><p>a requirement that certain

specific sorts of data structure be present, so an implementation may rely

on their presence </p> </li>

<li id="GUID-A16903C7-911F-531C-8583-D8B8EF7C387D"><p>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 </p> </li>

</ul> <p>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. </p> <p>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. </p> </section>

<section><title>Profile support in Certman</title> <p>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. </p> <p>The decision to use a particular

profile rests with the application. </p> <p>All general classes defined in

X.509 are prefixed with 'X509', all profile specific classes are prefixed

with the name of the profile. </p> <p><b>X.509 specific part</b> </p> <p>The

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

part of X.509 itself. </p> <p>The generic extension object is simply an ASN1

'any defined by' structure, with accessors for its OID and its encapsulated

data. </p> <p>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 <codeph>KeyUsage()</codeph> function,

since it cannot be assumed that key usage is present). </p> <p>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. </p> <p>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. </p> <p><b>Profile specific part</b> </p> <p>The

profile specific part defines two significant public classes: </p> <ul>

<li id="GUID-E1F336F8-CEE3-52CC-931A-F71D6911871D"><p>PKIX certificate chain

object </p> <p>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. </p> </li>

<li id="GUID-79ACFD2B-3E61-5612-BDD0-164CE791F9A5"><p>PKIX validation result

object </p> <p>This is constructed by the chain object in the course of validation

and handed to the client to examine. </p> </li>

</ul> <p>These classes are described in more detail in <xref href="GUID-A3B58436-07E4-565B-800B-86435D205461.dita">Certificate

validation in PKIX</xref>; the validation process discussed there is PKIX

specific. </p> </section>