--- a/Symbian3/SDK/Source/GUID-A3B58436-07E4-565B-800B-86435D205461.dita Wed Mar 31 11:11:55 2010 +0100
+++ b/Symbian3/SDK/Source/GUID-A3B58436-07E4-565B-800B-86435D205461.dita Fri Jun 11 12:39:03 2010 +0100
@@ -1,181 +1,181 @@
-<?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-A3B58436-07E4-565B-800B-86435D205461" xml:lang="en"><title>Certificate
-Validation in PKIX</title><prolog><metadata><keywords/></metadata></prolog><conbody>
-<p>Certificates of different types are trusted by different applications.
-Therefore certificates need to be signed by certification authority (CA) and
-the signature must be verified and validated. This section describes about
-certificate chain and certificate validation processes. </p>
-<section><title>Certificate Chain</title> <p>Certificate validation is a recursive
-process. It begins with the need to verify the signature on some data presented
-by an End Entity (EE). This involves checking that the key pair is actually
-owned by that EE. To do this the public signing key of that EE is acquired
-by getting its certificate. That certificate would have been signed by the
-EE's certification authority (CA), so the signature on the certificate can
-be verified by getting the CA's public signing key. In turn the CA's certificate
-might require verifying in which case the process is repeated until the process
-bottoms out when an entity which is already trusted is reached; that entity
-is usually self signed. This process is illustrated in the figure below: </p> <fig id="GUID-A0956B2A-B12F-58E1-9172-C1EDBBE593CE">
-<title> Certificate chain </title>
-<image href="GUID-EA5E9A07-587C-5E64-A157-1077AD9E56ED_d0e390371_href.png" placement="inline"/>
-</fig> <p>The set of certificates from an EE up to a trusted root CA certificate
-is called a <keyword>certificate chain</keyword>. Once a certificate chain
-has been constructed ,the EE's key pair at the start can be validated. </p> </section>
-<section><title> Input to Certificate Validation</title> <p id="GUID-21CE5C18-856E-57B6-A5B6-3C1104EB8151"><b> End
-Entity & Intermediate Certificates</b> </p> <p>A set of certificates,
-from the entity requesting authentication up to, but not including, one already
-trusted by the relying party. </p> <p>Where these certificates come from is
-potentially a difficult problem if certificate management is expected to search
-for intermediate certificates in remote repositories; however for TLS at least
-servers are required to supply a complete, ordered set of certificates in
-the form of DER-encoded ASN.1; so client code can just pass this into the
-certificate chain object. </p> <p id="GUID-2533ACD8-29FC-5297-A462-7D93BF029A59"><b> Trusted
-Root Certificates</b> </p> <p>Authentication cannot be done entirely by software:
-there must be a point at which the user confirms that they trust a particular
-entity. The validation algorithm can only ascertain that if the user trusts
-certificate X then they may also trust certificate Y. Certificates which the
-user trusts directly are called root certificates because they are the root
-of the validation chain. They are usually self-signed. </p> <p>It is likely
-that different applications will have different requirements about which certificates
-may be considered trust roots and for the level of protection they require
-for trust roots. To this end, applications will pass in a unique ID (<codeph>TUid</codeph>)
-which Certificate and Key Management will use to identify the application,
-and so work out which certificates can be considered trusted for that application. </p> <p>For
-additional flexibility, an overload is provided enabling clients to pass a
-set of root certificates directly into the validation function. </p> <p>For
-more detailed discussion of the storage and management of root certificates
-see <xref href="GUID-2800C486-2FB4-5C5C-990F-CC1A290F7E0C.dita">Root Certificate
-Management, Storage, and Client registration</xref>. </p> <p id="GUID-0E4B09EF-74B8-5272-98F4-60C423614F50"><b> Validation
-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
-set of OIDs, each of which represents a certification policy acceptable to
-the application. This enables client code to restrict the certificates that
-may occur in a valid certificate chain. Client code does not have to specify
-any preferred policies here. An empty set is interpreted as any policy. </p> </section>
-<section id="GUID-AE46492C-5F13-5B73-B1F5-81DD6C15AFAF"><title>Configuring
-for Certificate Validation</title> <p>The following settings can be configured
-for the validation process: </p> <table id="GUID-D88105DD-347A-5E33-8B79-1A75CCC28ED0">
-<tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/>
-<tbody>
-<row>
-<entry><p>Supported critical extensions </p> </entry>
-<entry><p>You can list supported X.509 v3 critical extensions. Once you have
-set a list, you have full control over the processing of X.509 v3 critical
-extensions. If a critical extension is found whose OID matches an element
-in this list, certificate validation treats this as a warning instead of an
-error. </p> <p>You can set, add, remove and reset the list of supported critical
-extensions. </p> <p>If critical extensions are not configured, the validation
-process uses a default set. This includes standard X.509 critical extensions
-and Symbian specific critical extensions. </p> </entry>
-</row>
-<row>
-<entry><p>Date validity checks </p> </entry>
-<entry><p>You can specify whether a failed check on the certificate validity
-date is treated as an error or a warning. You can use this to verify the certificate
-validity period post-installation. By default the certificate validity period
-only needs to be checked at installation. </p> </entry>
-</row>
-</tbody>
-</tgroup>
-</table> </section>
-<section><title> Chain Validation</title> <p><b> Chain Construction</b> </p> <p>The
-chain object parses the encoded set of certificates. The first certificate
-is considered to be the EE certificate, and subsequent certificates must each
-certify the preceding one. The chain object then searches the set of trusted
-root certificates for a certificate trusted by the client and whose subject
-name matches the issuer name in the last certificate in the decoded set. If
-two or more match, it will attempt to resolve this be comparing the authority
-key ID in the last certificate with the subject key ID in each candidate root.
-If this extension is not present, it will attempt to find a single root by
-signature verification. If no root is found validation will fail immediately
-with an error. </p> <p><b> Initialisation of Chain Validation Algorithm</b> </p> <p>The
-certificate chain initialises the following state variables: </p> <ul>
-<li id="GUID-00BFA3CA-ECE2-5D69-B90F-B1B01D40006D"><p>Validation Time: time
-for which validation is calculated. Initialised to the time supplied by client
-code. </p> </li>
-<li id="GUID-266D360B-2793-5963-B2B2-D79E9745AF4D"><p>Initial Policies: set
-of policy OIDs, initialised to the policies supplied by client code </p> </li>
-<li id="GUID-4DEBA756-99FA-54CB-9E93-85F8F54301B7"><p>Acceptable Policies:
-set of X.509 policy information objects, initially any policy </p> </li>
-<li id="GUID-B7FD8FF3-61E1-5CAB-8B6E-25092186727E"><p>Mapped Policies: set
-of policy OIDs, initially empty </p> </li>
-<li id="GUID-280A775A-4F34-5A1B-9A9A-BAFFE7A4E77B"><p>Excluded Subtrees: set
-of X.500 General Name objects, initially empty </p> </li>
-<li id="GUID-C4059DDE-16AC-5B3F-8001-09DC1FF789A8"><p>Permitted Subtrees:
-set of X.500 General Name objects, initially any subtree </p> </li>
-<li id="GUID-A27F8096-0F6B-5942-9019-3D7685AE3E10"><p>Max Path Length: integer
-representing the maximum path length. Initially the actual path length </p> </li>
-<li id="GUID-89B057B9-E26E-594C-B23F-E73FA97E07C8"><p>Inhibit Policy Mapping:
-integer whose value is the number of certificates that may appear after the
-current one before policy mapping is no longer permitted. Initially the chain
-length </p> </li>
-<li id="GUID-3D92E10D-2BF5-5DD3-B061-9CB332631880"><p>Require Explicit Policy:
-integer whose value is the number of certificates that may appear after the
-current one before an acceptable policy OID must appear in the certificate.
-Initially the chain length </p> </li>
-<li id="GUID-1CEA8529-2141-5083-9279-F464B217BDE1"><p>Current Cert: integer
-whose value is the position of the current certificate in the chain. Initially
-the chain length -1 </p> </li>
-</ul> <p><b> Validation Algorithm</b> </p> <p>Validation of a certificate
-chain starts at the root and ends at the End Entity. </p> <p><i>Validation
-warnings </i></p> <p>Validation returns warnings. Warnings enable client code
-to evaluate whether irregularities are errors. </p> <p>From Version 9.3, validation
-returns a warning object for every certificate in the chain. Each warning
-object has the following characteristics: </p> <ul>
-<li id="GUID-4C016BA3-99EF-5D7C-9EDC-AC958C9AA937"><p>It includes the object's
-index. Clients use the index to get the certificate from the certificate chain
-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>
-<li id="GUID-81C9B8B1-F8B4-50E8-B7DC-53C131B646B9"><p>It encapsulates the
-warnings and the critical extensions' OID values for that certificate. </p> <p> </p> </li>
-</ul> <p>Clients can query the object for two sets of data: </p> <ul>
-<li id="GUID-A7E6D671-1966-5DA7-821C-C7AD3880D7F1"><p>the critical extensions
-for the certificate </p> </li>
-<li id="GUID-5FCA36E5-CEDB-567C-8E95-759C13A64362"><p>a set of warning values,
-each consisting of a reason for the warning and an integer identifying the
-certificate that the warning is associated with. </p> </li>
-</ul> <p>After querying the warning object for the critical extension, the
-client must process any custom critical extensions it supplied that are not
-in the supported list. This meets the X.509 certificate specification. </p><note> Prior
-to version 9.3, the set of warning values returned included any warnings about
-critical extensions. Warning values no longer include this information. But
-backward compatibility has been maintained for warning objects prior to version
-9.3. </note> <p><i>Certificate validation step</i>s </p> <p>Certificate
-validation takes place through the following steps: </p> <ul>
-<li id="GUID-70351BB4-CE56-559E-81A2-1EE0DBA19AFD"><p>Signature Verification
-& Name Chaining </p> <p>Each certificate must be signed by, and its subject
-name should match the issuer name in, the certificate above it in the chain.
-The only exception is the root certificate, which, if it claims to be self
-signed (i.e. its subject and issuer names match) must really be self signed;
-otherwise its signature is not verified, but a warning is generated. </p> </li>
-<li id="GUID-9597F61C-7ECE-5754-85BC-12D50035D7D1"><p>Validity Period Checking </p> <p>For
-each certificate, the Validation Time must lie within the validity period
-in the certificate. The check is always carried out. The check treats a failure
-as an error or a warning depending on how the validation process is configured
-(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
-for Certificate Validation</xref>). By default the check treats the failure
-as an error. </p> </li>
-<li id="GUID-1EB6F83B-C10D-5809-B5A8-4AF45FFA9A92"><p>Extension Processing </p> <p>Extensions
-can be marked critical. All critical extensions must be in the supported list
-to be recognized and processed. When a critical extension that is not in the
-supported list is encountered, an error results and validation fails. The
-client must process critical extensions that are not in the supported list. </p> </li>
-<li id="GUID-463F6C6E-7C3B-514E-A7E8-91D07CFFD102"><p>Revocation Checking </p> </li>
-</ul> <p>Additionally, for each certificate: </p> <ul>
-<li id="GUID-91579F6C-2C98-50DF-9637-E08EBDEC4CDE"><p>the <i>Max Path Length</i>, <i>Inhibit
-Policy Mapping</i> and <i>Require Explicit Policy</i> variables are decremented, </p> </li>
-<li id="GUID-05687909-8111-53D0-9760-88FF557C26AA"><p>and Current Cert must
-be less than or equal to <i>Max Path Length</i>. </p> </li>
-</ul> <p>When validation is complete the <i>Acceptable Policies</i> variable
-will be copied into the set of policies in the result object. </p> </section>
-<section><title>See also</title> <ul>
-<li id="GUID-A6095947-6CFF-50CC-BBAC-181B91CD9132"><p><xref href="GUID-E326C00B-6E07-5902-AB19-F00D1761795C.dita">PKIXCert</xref> </p> </li>
-</ul> </section>
+<?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-A3B58436-07E4-565B-800B-86435D205461" xml:lang="en"><title>Certificate
+Validation in PKIX</title><prolog><metadata><keywords/></metadata></prolog><conbody>
+<p>Certificates of different types are trusted by different applications.
+Therefore certificates need to be signed by certification authority (CA) and
+the signature must be verified and validated. This section describes about
+certificate chain and certificate validation processes. </p>
+<section><title>Certificate Chain</title> <p>Certificate validation is a recursive
+process. It begins with the need to verify the signature on some data presented
+by an End Entity (EE). This involves checking that the key pair is actually
+owned by that EE. To do this the public signing key of that EE is acquired
+by getting its certificate. That certificate would have been signed by the
+EE's certification authority (CA), so the signature on the certificate can
+be verified by getting the CA's public signing key. In turn the CA's certificate
+might require verifying in which case the process is repeated until the process
+bottoms out when an entity which is already trusted is reached; that entity
+is usually self signed. This process is illustrated in the figure below: </p> <fig id="GUID-A0956B2A-B12F-58E1-9172-C1EDBBE593CE">
+<title> Certificate chain </title>
+<image href="GUID-EA5E9A07-587C-5E64-A157-1077AD9E56ED_d0e390209_href.png" placement="inline"/>
+</fig> <p>The set of certificates from an EE up to a trusted root CA certificate
+is called a <keyword>certificate chain</keyword>. Once a certificate chain
+has been constructed ,the EE's key pair at the start can be validated. </p> </section>
+<section><title> Input to Certificate Validation</title> <p id="GUID-21CE5C18-856E-57B6-A5B6-3C1104EB8151"><b> End
+Entity & Intermediate Certificates</b> </p> <p>A set of certificates,
+from the entity requesting authentication up to, but not including, one already
+trusted by the relying party. </p> <p>Where these certificates come from is
+potentially a difficult problem if certificate management is expected to search
+for intermediate certificates in remote repositories; however for TLS at least
+servers are required to supply a complete, ordered set of certificates in
+the form of DER-encoded ASN.1; so client code can just pass this into the
+certificate chain object. </p> <p id="GUID-2533ACD8-29FC-5297-A462-7D93BF029A59"><b> Trusted
+Root Certificates</b> </p> <p>Authentication cannot be done entirely by software:
+there must be a point at which the user confirms that they trust a particular
+entity. The validation algorithm can only ascertain that if the user trusts
+certificate X then they may also trust certificate Y. Certificates which the
+user trusts directly are called root certificates because they are the root
+of the validation chain. They are usually self-signed. </p> <p>It is likely
+that different applications will have different requirements about which certificates
+may be considered trust roots and for the level of protection they require
+for trust roots. To this end, applications will pass in a unique ID (<codeph>TUid</codeph>)
+which Certificate and Key Management will use to identify the application,
+and so work out which certificates can be considered trusted for that application. </p> <p>For
+additional flexibility, an overload is provided enabling clients to pass a
+set of root certificates directly into the validation function. </p> <p>For
+more detailed discussion of the storage and management of root certificates
+see <xref href="GUID-2800C486-2FB4-5C5C-990F-CC1A290F7E0C.dita">Root Certificate
+Management, Storage, and Client registration</xref>. </p> <p id="GUID-0E4B09EF-74B8-5272-98F4-60C423614F50"><b> Validation
+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
+set of OIDs, each of which represents a certification policy acceptable to
+the application. This enables client code to restrict the certificates that
+may occur in a valid certificate chain. Client code does not have to specify
+any preferred policies here. An empty set is interpreted as any policy. </p> </section>
+<section id="GUID-AE46492C-5F13-5B73-B1F5-81DD6C15AFAF"><title>Configuring
+for Certificate Validation</title> <p>The following settings can be configured
+for the validation process: </p> <table id="GUID-D88105DD-347A-5E33-8B79-1A75CCC28ED0">
+<tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/>
+<tbody>
+<row>
+<entry><p>Supported critical extensions </p> </entry>
+<entry><p>You can list supported X.509 v3 critical extensions. Once you have
+set a list, you have full control over the processing of X.509 v3 critical
+extensions. If a critical extension is found whose OID matches an element
+in this list, certificate validation treats this as a warning instead of an
+error. </p> <p>You can set, add, remove and reset the list of supported critical
+extensions. </p> <p>If critical extensions are not configured, the validation
+process uses a default set. This includes standard X.509 critical extensions
+and Symbian specific critical extensions. </p> </entry>
+</row>
+<row>
+<entry><p>Date validity checks </p> </entry>
+<entry><p>You can specify whether a failed check on the certificate validity
+date is treated as an error or a warning. You can use this to verify the certificate
+validity period post-installation. By default the certificate validity period
+only needs to be checked at installation. </p> </entry>
+</row>
+</tbody>
+</tgroup>
+</table> </section>
+<section><title> Chain Validation</title> <p><b> Chain Construction</b> </p> <p>The
+chain object parses the encoded set of certificates. The first certificate
+is considered to be the EE certificate, and subsequent certificates must each
+certify the preceding one. The chain object then searches the set of trusted
+root certificates for a certificate trusted by the client and whose subject
+name matches the issuer name in the last certificate in the decoded set. If
+two or more match, it will attempt to resolve this be comparing the authority
+key ID in the last certificate with the subject key ID in each candidate root.
+If this extension is not present, it will attempt to find a single root by
+signature verification. If no root is found validation will fail immediately
+with an error. </p> <p><b> Initialisation of Chain Validation Algorithm</b> </p> <p>The
+certificate chain initialises the following state variables: </p> <ul>
+<li id="GUID-00BFA3CA-ECE2-5D69-B90F-B1B01D40006D"><p>Validation Time: time
+for which validation is calculated. Initialised to the time supplied by client
+code. </p> </li>
+<li id="GUID-266D360B-2793-5963-B2B2-D79E9745AF4D"><p>Initial Policies: set
+of policy OIDs, initialised to the policies supplied by client code </p> </li>
+<li id="GUID-4DEBA756-99FA-54CB-9E93-85F8F54301B7"><p>Acceptable Policies:
+set of X.509 policy information objects, initially any policy </p> </li>
+<li id="GUID-B7FD8FF3-61E1-5CAB-8B6E-25092186727E"><p>Mapped Policies: set
+of policy OIDs, initially empty </p> </li>
+<li id="GUID-280A775A-4F34-5A1B-9A9A-BAFFE7A4E77B"><p>Excluded Subtrees: set
+of X.500 General Name objects, initially empty </p> </li>
+<li id="GUID-C4059DDE-16AC-5B3F-8001-09DC1FF789A8"><p>Permitted Subtrees:
+set of X.500 General Name objects, initially any subtree </p> </li>
+<li id="GUID-A27F8096-0F6B-5942-9019-3D7685AE3E10"><p>Max Path Length: integer
+representing the maximum path length. Initially the actual path length </p> </li>
+<li id="GUID-89B057B9-E26E-594C-B23F-E73FA97E07C8"><p>Inhibit Policy Mapping:
+integer whose value is the number of certificates that may appear after the
+current one before policy mapping is no longer permitted. Initially the chain
+length </p> </li>
+<li id="GUID-3D92E10D-2BF5-5DD3-B061-9CB332631880"><p>Require Explicit Policy:
+integer whose value is the number of certificates that may appear after the
+current one before an acceptable policy OID must appear in the certificate.
+Initially the chain length </p> </li>
+<li id="GUID-1CEA8529-2141-5083-9279-F464B217BDE1"><p>Current Cert: integer
+whose value is the position of the current certificate in the chain. Initially
+the chain length -1 </p> </li>
+</ul> <p><b> Validation Algorithm</b> </p> <p>Validation of a certificate
+chain starts at the root and ends at the End Entity. </p> <p><i>Validation
+warnings </i></p> <p>Validation returns warnings. Warnings enable client code
+to evaluate whether irregularities are errors. </p> <p>From Version 9.3, validation
+returns a warning object for every certificate in the chain. Each warning
+object has the following characteristics: </p> <ul>
+<li id="GUID-4C016BA3-99EF-5D7C-9EDC-AC958C9AA937"><p>It includes the object's
+index. Clients use the index to get the certificate from the certificate chain
+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>
+<li id="GUID-81C9B8B1-F8B4-50E8-B7DC-53C131B646B9"><p>It encapsulates the
+warnings and the critical extensions' OID values for that certificate. </p> <p> </p> </li>
+</ul> <p>Clients can query the object for two sets of data: </p> <ul>
+<li id="GUID-A7E6D671-1966-5DA7-821C-C7AD3880D7F1"><p>the critical extensions
+for the certificate </p> </li>
+<li id="GUID-5FCA36E5-CEDB-567C-8E95-759C13A64362"><p>a set of warning values,
+each consisting of a reason for the warning and an integer identifying the
+certificate that the warning is associated with. </p> </li>
+</ul> <p>After querying the warning object for the critical extension, the
+client must process any custom critical extensions it supplied that are not
+in the supported list. This meets the X.509 certificate specification. </p><note> Prior
+to version 9.3, the set of warning values returned included any warnings about
+critical extensions. Warning values no longer include this information. But
+backward compatibility has been maintained for warning objects prior to version
+9.3. </note> <p><i>Certificate validation step</i>s </p> <p>Certificate
+validation takes place through the following steps: </p> <ul>
+<li id="GUID-70351BB4-CE56-559E-81A2-1EE0DBA19AFD"><p>Signature Verification
+& Name Chaining </p> <p>Each certificate must be signed by, and its subject
+name should match the issuer name in, the certificate above it in the chain.
+The only exception is the root certificate, which, if it claims to be self
+signed (i.e. its subject and issuer names match) must really be self signed;
+otherwise its signature is not verified, but a warning is generated. </p> </li>
+<li id="GUID-9597F61C-7ECE-5754-85BC-12D50035D7D1"><p>Validity Period Checking </p> <p>For
+each certificate, the Validation Time must lie within the validity period
+in the certificate. The check is always carried out. The check treats a failure
+as an error or a warning depending on how the validation process is configured
+(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
+for Certificate Validation</xref>). By default the check treats the failure
+as an error. </p> </li>
+<li id="GUID-1EB6F83B-C10D-5809-B5A8-4AF45FFA9A92"><p>Extension Processing </p> <p>Extensions
+can be marked critical. All critical extensions must be in the supported list
+to be recognized and processed. When a critical extension that is not in the
+supported list is encountered, an error results and validation fails. The
+client must process critical extensions that are not in the supported list. </p> </li>
+<li id="GUID-463F6C6E-7C3B-514E-A7E8-91D07CFFD102"><p>Revocation Checking </p> </li>
+</ul> <p>Additionally, for each certificate: </p> <ul>
+<li id="GUID-91579F6C-2C98-50DF-9637-E08EBDEC4CDE"><p>the <i>Max Path Length</i>, <i>Inhibit
+Policy Mapping</i> and <i>Require Explicit Policy</i> variables are decremented, </p> </li>
+<li id="GUID-05687909-8111-53D0-9760-88FF557C26AA"><p>and Current Cert must
+be less than or equal to <i>Max Path Length</i>. </p> </li>
+</ul> <p>When validation is complete the <i>Acceptable Policies</i> variable
+will be copied into the set of policies in the result object. </p> </section>
+<section><title>See also</title> <ul>
+<li id="GUID-A6095947-6CFF-50CC-BBAC-181B91CD9132"><p><xref href="GUID-E326C00B-6E07-5902-AB19-F00D1761795C.dita">PKIXCert</xref> </p> </li>
+</ul> </section>
</conbody></concept>
\ No newline at end of file