<?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>
</conbody></concept>