|
1 <?xml version="1.0" encoding="utf-8"?> |
|
2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. --> |
|
3 <!-- This component and the accompanying materials are made available under the terms of the License |
|
4 "Eclipse Public License v1.0" which accompanies this distribution, |
|
5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". --> |
|
6 <!-- Initial Contributors: |
|
7 Nokia Corporation - initial contribution. |
|
8 Contributors: |
|
9 --> |
|
10 <!DOCTYPE concept |
|
11 PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> |
|
12 <concept id="GUID-C676C4E6-93AF-59E9-886D-74D59F154490" xml:lang="en"><title>X.509 |
|
13 and PKIX</title><prolog><metadata><keywords/></metadata></prolog><conbody> |
|
14 <p>A certificate consists of a public key together with some identifying information, |
|
15 all of which is signed with a Certificate Authority's private key. Different |
|
16 certificate specifications elaborate on this in different ways with varying |
|
17 syntax, encoding rules and processing requirements. </p> |
|
18 <p>X.509 is currently the dominant specification and is used by TLS, S/MIME |
|
19 and IPSEC. In addition to this certificate type the Symbian platform also |
|
20 provides support for and implements WTLS certificates: this page deals with |
|
21 X.509, for information on WTLS see <xref href="GUID-A636C1B3-8AB2-52D7-BB19-4CC93F4BDD97.dita">WTLS |
|
22 Certificates</xref>. </p> |
|
23 <section><title>The need for profiles in X.509</title> <p>The X.509 specification |
|
24 alone is not restrictive or specific enough to form the basis of an implementation |
|
25 of a certificate management component. Realisation of this fact has led to |
|
26 the creation of a set of mostly incompatible profiles. </p> <p>While X.509 |
|
27 defines an extensible syntax for all the data structures required to perform |
|
28 certificate management, a profile adds three things: </p> <ul> |
|
29 <li id="GUID-5399F944-9BDA-5325-9E0D-93F189287A13"><p>a restriction on the |
|
30 sorts of data structures that an implementation is required to understand </p> </li> |
|
31 <li id="GUID-9276E4DF-0B64-5D16-A9A0-CD7D58E67F09"><p>a requirement that certain |
|
32 specific sorts of data structure be present, so an implementation may rely |
|
33 on their presence </p> </li> |
|
34 <li id="GUID-A16903C7-911F-531C-8583-D8B8EF7C387D"><p>a clear definition of |
|
35 the behaviour of a certificate management component, that is, a specification |
|
36 of what it is supposed to do with the data structures involved </p> </li> |
|
37 </ul> <p>The best example of this is seen in certificate extensions. X.509 |
|
38 defines the syntax of a series of extension types, and permits new extensions |
|
39 to be defined using object identifiers. It does not require the presence of |
|
40 any extensions and does not clearly indicate what it means to support a particular |
|
41 extension. Thus an implementation cannot know which extensions will be present, |
|
42 or exactly what to do with them. A profile like PKIX defines a set of extensions |
|
43 that a PKIX-compliant certificate management component must be able to deal |
|
44 with, which extensions can be assumed to be present, and a definition of what |
|
45 it means to deal with them. </p> <p>The distinction between X.509 and its |
|
46 profiles is largely one of syntax versus behaviour: X.509 defines the syntax |
|
47 of the objects, and the profile defines how the presence and values of objects |
|
48 affects the behaviour of certificate management. In addition, a profile may |
|
49 define extra pieces of syntax, specific to the application for which it is |
|
50 designed. </p> </section> |
|
51 <section><title>Profile support in Certman</title> <p>Certificate Management |
|
52 implements X.509 along with one profile, the PKIX profile, defined in RFC |
|
53 3280. Its design attempts to incorporate the distinction between X.509 and |
|
54 its profiles, enabling further additions to be made to the X.509 part without |
|
55 affecting any profiles, and enabling further profiles to be defined without |
|
56 affecting the X.509 specific part. </p> <p>The decision to use a particular |
|
57 profile rests with the application. </p> <p>All general classes defined in |
|
58 X.509 are prefixed with 'X509', all profile specific classes are prefixed |
|
59 with the name of the profile. </p> <p><b>X.509 specific part</b> </p> <p>The |
|
60 X.509 certificate itself and the generic extension object are both clearly |
|
61 part of X.509 itself. </p> <p>The generic extension object is simply an ASN1 |
|
62 'any defined by' structure, with accessors for its OID and its encapsulated |
|
63 data. </p> <p>The X.509 certificate provides a function that, given a particular |
|
64 OID, returns a pointer to a particular extension object or NULL if the extension |
|
65 is not present. It also provides functions to verify its signature, given |
|
66 a key, and return the various data members that X.509 requires, such as its |
|
67 subject and issuer DNs. However, it does not provide accessors for any particular |
|
68 extensions (for example there is no <codeph>KeyUsage()</codeph> function, |
|
69 since it cannot be assumed that key usage is present). </p> <p>A generic certificate |
|
70 chain object is also provided; this simply has a set of X.509 certificates, |
|
71 provides accessors to them and implements a function to decode a set of certificates |
|
72 from DER encoded ASN.1. </p> <p>Specific extension classes are in a bit of |
|
73 a no-man's land. This is because many of them are defined by X.509, but more |
|
74 can be added by any profile, and a profile will require the use of a particular |
|
75 set of extensions. So, all the extensions used by PKIX in X.509 have been |
|
76 implemented on the assumption that they are likely to be useful for other |
|
77 profiles, however, profiles are free to define extra extensions. Since these |
|
78 extension classes are implemented in X.509, they only define the syntax of |
|
79 the extension, not the way it should be used. Because they are radically different |
|
80 they do not share a common base class. </p> <p><b>Profile specific part</b> </p> <p>The |
|
81 profile specific part defines two significant public classes: </p> <ul> |
|
82 <li id="GUID-E1F336F8-CEE3-52CC-931A-F71D6911871D"><p>PKIX certificate chain |
|
83 object </p> <p>This is main class which encapsulates path processing in the |
|
84 PKIX profile. Thus it defines which extensions are required, which extensions |
|
85 are understood, and how they are understood. </p> </li> |
|
86 <li id="GUID-79ACFD2B-3E61-5612-BDD0-164CE791F9A5"><p>PKIX validation result |
|
87 object </p> <p>This is constructed by the chain object in the course of validation |
|
88 and handed to the client to examine. </p> </li> |
|
89 </ul> <p>These classes are described in more detail in <xref href="GUID-A3B58436-07E4-565B-800B-86435D205461.dita">Certificate |
|
90 validation in PKIX</xref>; the validation process discussed there is PKIX |
|
91 specific. </p> </section> |
|
92 </conbody></concept> |