|
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-A3B58436-07E4-565B-800B-86435D205461" xml:lang="en"><title>Certificate |
|
13 Validation in PKIX</title><prolog><metadata><keywords/></metadata></prolog><conbody> |
|
14 <p>Certificates of different types are trusted by different applications. |
|
15 Therefore certificates need to be signed by certification authority (CA) and |
|
16 the signature must be verified and validated. This section describes about |
|
17 certificate chain and certificate validation processes. </p> |
|
18 <section><title>Certificate Chain</title> <p>Certificate validation is a recursive |
|
19 process. It begins with the need to verify the signature on some data presented |
|
20 by an End Entity (EE). This involves checking that the key pair is actually |
|
21 owned by that EE. To do this the public signing key of that EE is acquired |
|
22 by getting its certificate. That certificate would have been signed by the |
|
23 EE's certification authority (CA), so the signature on the certificate can |
|
24 be verified by getting the CA's public signing key. In turn the CA's certificate |
|
25 might require verifying in which case the process is repeated until the process |
|
26 bottoms out when an entity which is already trusted is reached; that entity |
|
27 is usually self signed. This process is illustrated in the figure below: </p> <fig id="GUID-A0956B2A-B12F-58E1-9172-C1EDBBE593CE"> |
|
28 <title> Certificate chain </title> |
|
29 <image href="GUID-EA5E9A07-587C-5E64-A157-1077AD9E56ED_d0e390371_href.png" placement="inline"/> |
|
30 </fig> <p>The set of certificates from an EE up to a trusted root CA certificate |
|
31 is called a <keyword>certificate chain</keyword>. Once a certificate chain |
|
32 has been constructed ,the EE's key pair at the start can be validated. </p> </section> |
|
33 <section><title> Input to Certificate Validation</title> <p id="GUID-21CE5C18-856E-57B6-A5B6-3C1104EB8151"><b> End |
|
34 Entity & Intermediate Certificates</b> </p> <p>A set of certificates, |
|
35 from the entity requesting authentication up to, but not including, one already |
|
36 trusted by the relying party. </p> <p>Where these certificates come from is |
|
37 potentially a difficult problem if certificate management is expected to search |
|
38 for intermediate certificates in remote repositories; however for TLS at least |
|
39 servers are required to supply a complete, ordered set of certificates in |
|
40 the form of DER-encoded ASN.1; so client code can just pass this into the |
|
41 certificate chain object. </p> <p id="GUID-2533ACD8-29FC-5297-A462-7D93BF029A59"><b> Trusted |
|
42 Root Certificates</b> </p> <p>Authentication cannot be done entirely by software: |
|
43 there must be a point at which the user confirms that they trust a particular |
|
44 entity. The validation algorithm can only ascertain that if the user trusts |
|
45 certificate X then they may also trust certificate Y. Certificates which the |
|
46 user trusts directly are called root certificates because they are the root |
|
47 of the validation chain. They are usually self-signed. </p> <p>It is likely |
|
48 that different applications will have different requirements about which certificates |
|
49 may be considered trust roots and for the level of protection they require |
|
50 for trust roots. To this end, applications will pass in a unique ID (<codeph>TUid</codeph>) |
|
51 which Certificate and Key Management will use to identify the application, |
|
52 and so work out which certificates can be considered trusted for that application. </p> <p>For |
|
53 additional flexibility, an overload is provided enabling clients to pass a |
|
54 set of root certificates directly into the validation function. </p> <p>For |
|
55 more detailed discussion of the storage and management of root certificates |
|
56 see <xref href="GUID-2800C486-2FB4-5C5C-990F-CC1A290F7E0C.dita">Root Certificate |
|
57 Management, Storage, and Client registration</xref>. </p> <p id="GUID-0E4B09EF-74B8-5272-98F4-60C423614F50"><b> Validation |
|
58 Time</b> </p> <p>The time for which validation will be performed. </p> <p id="GUID-288B55BA-E0B0-5F67-BD62-A08832A09889"><b> Acceptable Policies</b> </p> <p>A |
|
59 set of OIDs, each of which represents a certification policy acceptable to |
|
60 the application. This enables client code to restrict the certificates that |
|
61 may occur in a valid certificate chain. Client code does not have to specify |
|
62 any preferred policies here. An empty set is interpreted as any policy. </p> </section> |
|
63 <section id="GUID-AE46492C-5F13-5B73-B1F5-81DD6C15AFAF"><title>Configuring |
|
64 for Certificate Validation</title> <p>The following settings can be configured |
|
65 for the validation process: </p> <table id="GUID-D88105DD-347A-5E33-8B79-1A75CCC28ED0"> |
|
66 <tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/> |
|
67 <tbody> |
|
68 <row> |
|
69 <entry><p>Supported critical extensions </p> </entry> |
|
70 <entry><p>You can list supported X.509 v3 critical extensions. Once you have |
|
71 set a list, you have full control over the processing of X.509 v3 critical |
|
72 extensions. If a critical extension is found whose OID matches an element |
|
73 in this list, certificate validation treats this as a warning instead of an |
|
74 error. </p> <p>You can set, add, remove and reset the list of supported critical |
|
75 extensions. </p> <p>If critical extensions are not configured, the validation |
|
76 process uses a default set. This includes standard X.509 critical extensions |
|
77 and Symbian specific critical extensions. </p> </entry> |
|
78 </row> |
|
79 <row> |
|
80 <entry><p>Date validity checks </p> </entry> |
|
81 <entry><p>You can specify whether a failed check on the certificate validity |
|
82 date is treated as an error or a warning. You can use this to verify the certificate |
|
83 validity period post-installation. By default the certificate validity period |
|
84 only needs to be checked at installation. </p> </entry> |
|
85 </row> |
|
86 </tbody> |
|
87 </tgroup> |
|
88 </table> </section> |
|
89 <section><title> Chain Validation</title> <p><b> Chain Construction</b> </p> <p>The |
|
90 chain object parses the encoded set of certificates. The first certificate |
|
91 is considered to be the EE certificate, and subsequent certificates must each |
|
92 certify the preceding one. The chain object then searches the set of trusted |
|
93 root certificates for a certificate trusted by the client and whose subject |
|
94 name matches the issuer name in the last certificate in the decoded set. If |
|
95 two or more match, it will attempt to resolve this be comparing the authority |
|
96 key ID in the last certificate with the subject key ID in each candidate root. |
|
97 If this extension is not present, it will attempt to find a single root by |
|
98 signature verification. If no root is found validation will fail immediately |
|
99 with an error. </p> <p><b> Initialisation of Chain Validation Algorithm</b> </p> <p>The |
|
100 certificate chain initialises the following state variables: </p> <ul> |
|
101 <li id="GUID-00BFA3CA-ECE2-5D69-B90F-B1B01D40006D"><p>Validation Time: time |
|
102 for which validation is calculated. Initialised to the time supplied by client |
|
103 code. </p> </li> |
|
104 <li id="GUID-266D360B-2793-5963-B2B2-D79E9745AF4D"><p>Initial Policies: set |
|
105 of policy OIDs, initialised to the policies supplied by client code </p> </li> |
|
106 <li id="GUID-4DEBA756-99FA-54CB-9E93-85F8F54301B7"><p>Acceptable Policies: |
|
107 set of X.509 policy information objects, initially any policy </p> </li> |
|
108 <li id="GUID-B7FD8FF3-61E1-5CAB-8B6E-25092186727E"><p>Mapped Policies: set |
|
109 of policy OIDs, initially empty </p> </li> |
|
110 <li id="GUID-280A775A-4F34-5A1B-9A9A-BAFFE7A4E77B"><p>Excluded Subtrees: set |
|
111 of X.500 General Name objects, initially empty </p> </li> |
|
112 <li id="GUID-C4059DDE-16AC-5B3F-8001-09DC1FF789A8"><p>Permitted Subtrees: |
|
113 set of X.500 General Name objects, initially any subtree </p> </li> |
|
114 <li id="GUID-A27F8096-0F6B-5942-9019-3D7685AE3E10"><p>Max Path Length: integer |
|
115 representing the maximum path length. Initially the actual path length </p> </li> |
|
116 <li id="GUID-89B057B9-E26E-594C-B23F-E73FA97E07C8"><p>Inhibit Policy Mapping: |
|
117 integer whose value is the number of certificates that may appear after the |
|
118 current one before policy mapping is no longer permitted. Initially the chain |
|
119 length </p> </li> |
|
120 <li id="GUID-3D92E10D-2BF5-5DD3-B061-9CB332631880"><p>Require Explicit Policy: |
|
121 integer whose value is the number of certificates that may appear after the |
|
122 current one before an acceptable policy OID must appear in the certificate. |
|
123 Initially the chain length </p> </li> |
|
124 <li id="GUID-1CEA8529-2141-5083-9279-F464B217BDE1"><p>Current Cert: integer |
|
125 whose value is the position of the current certificate in the chain. Initially |
|
126 the chain length -1 </p> </li> |
|
127 </ul> <p><b> Validation Algorithm</b> </p> <p>Validation of a certificate |
|
128 chain starts at the root and ends at the End Entity. </p> <p><i>Validation |
|
129 warnings </i></p> <p>Validation returns warnings. Warnings enable client code |
|
130 to evaluate whether irregularities are errors. </p> <p>From Version 9.3, validation |
|
131 returns a warning object for every certificate in the chain. Each warning |
|
132 object has the following characteristics: </p> <ul> |
|
133 <li id="GUID-4C016BA3-99EF-5D7C-9EDC-AC958C9AA937"><p>It includes the object's |
|
134 index. Clients use the index to get the certificate from the certificate chain |
|
135 object (<xref href="GUID-A919BE84-8257-3911-9AD1-B1DB736346CE.dita#GUID-A919BE84-8257-3911-9AD1-B1DB736346CE/GUID-9A843DCB-54C7-3BF4-BF30-2515969079A9"><apiname>CX509CertChain::Cert()</apiname></xref>). </p> </li> |
|
136 <li id="GUID-81C9B8B1-F8B4-50E8-B7DC-53C131B646B9"><p>It encapsulates the |
|
137 warnings and the critical extensions' OID values for that certificate. </p> <p> </p> </li> |
|
138 </ul> <p>Clients can query the object for two sets of data: </p> <ul> |
|
139 <li id="GUID-A7E6D671-1966-5DA7-821C-C7AD3880D7F1"><p>the critical extensions |
|
140 for the certificate </p> </li> |
|
141 <li id="GUID-5FCA36E5-CEDB-567C-8E95-759C13A64362"><p>a set of warning values, |
|
142 each consisting of a reason for the warning and an integer identifying the |
|
143 certificate that the warning is associated with. </p> </li> |
|
144 </ul> <p>After querying the warning object for the critical extension, the |
|
145 client must process any custom critical extensions it supplied that are not |
|
146 in the supported list. This meets the X.509 certificate specification. </p><note> Prior |
|
147 to version 9.3, the set of warning values returned included any warnings about |
|
148 critical extensions. Warning values no longer include this information. But |
|
149 backward compatibility has been maintained for warning objects prior to version |
|
150 9.3. </note> <p><i>Certificate validation step</i>s </p> <p>Certificate |
|
151 validation takes place through the following steps: </p> <ul> |
|
152 <li id="GUID-70351BB4-CE56-559E-81A2-1EE0DBA19AFD"><p>Signature Verification |
|
153 & Name Chaining </p> <p>Each certificate must be signed by, and its subject |
|
154 name should match the issuer name in, the certificate above it in the chain. |
|
155 The only exception is the root certificate, which, if it claims to be self |
|
156 signed (i.e. its subject and issuer names match) must really be self signed; |
|
157 otherwise its signature is not verified, but a warning is generated. </p> </li> |
|
158 <li id="GUID-9597F61C-7ECE-5754-85BC-12D50035D7D1"><p>Validity Period Checking </p> <p>For |
|
159 each certificate, the Validation Time must lie within the validity period |
|
160 in the certificate. The check is always carried out. The check treats a failure |
|
161 as an error or a warning depending on how the validation process is configured |
|
162 (See Date validity checks in <xref href="GUID-A3B58436-07E4-565B-800B-86435D205461.dita#GUID-A3B58436-07E4-565B-800B-86435D205461/GUID-AE46492C-5F13-5B73-B1F5-81DD6C15AFAF">Configuring |
|
163 for Certificate Validation</xref>). By default the check treats the failure |
|
164 as an error. </p> </li> |
|
165 <li id="GUID-1EB6F83B-C10D-5809-B5A8-4AF45FFA9A92"><p>Extension Processing </p> <p>Extensions |
|
166 can be marked critical. All critical extensions must be in the supported list |
|
167 to be recognized and processed. When a critical extension that is not in the |
|
168 supported list is encountered, an error results and validation fails. The |
|
169 client must process critical extensions that are not in the supported list. </p> </li> |
|
170 <li id="GUID-463F6C6E-7C3B-514E-A7E8-91D07CFFD102"><p>Revocation Checking </p> </li> |
|
171 </ul> <p>Additionally, for each certificate: </p> <ul> |
|
172 <li id="GUID-91579F6C-2C98-50DF-9637-E08EBDEC4CDE"><p>the <i>Max Path Length</i>, <i>Inhibit |
|
173 Policy Mapping</i> and <i>Require Explicit Policy</i> variables are decremented, </p> </li> |
|
174 <li id="GUID-05687909-8111-53D0-9760-88FF557C26AA"><p>and Current Cert must |
|
175 be less than or equal to <i>Max Path Length</i>. </p> </li> |
|
176 </ul> <p>When validation is complete the <i>Acceptable Policies</i> variable |
|
177 will be copied into the set of policies in the result object. </p> </section> |
|
178 <section><title>See also</title> <ul> |
|
179 <li id="GUID-A6095947-6CFF-50CC-BBAC-181B91CD9132"><p><xref href="GUID-E326C00B-6E07-5902-AB19-F00D1761795C.dita">PKIXCert</xref> </p> </li> |
|
180 </ul> </section> |
|
181 </conbody></concept> |