--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Symbian3/SDK/Source/GUID-C676C4E6-93AF-59E9-886D-74D59F154490.dita	Thu Jan 21 18:18:20 2010 +0000
@@ -0,0 +1,92 @@
+<?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>
\ No newline at end of file