Certification path validation algorithm: Difference between revisions

Revision as of 07:11, 16 May 2014

Latest revision as of 09:26, 14 July 2023

(21 intermediate revisions by 17 users not shown)

Line 1:

{{Short description|Test for a valid public key certificate}}

The '''certification path validation algorithm''' is the [[algorithm]] which verifies that a given '''certificate path''' is valid under a given [[public key infrastructure]] (PKI). A path starts with the Subject certificate and proceeds through a number of intermediate certificates up to a trusted [[root certificate]], typically issued by a trusted [[Certificationcertificate Authorityauthority]] (CA).

Path validation is necessary for a [[relying party]] to make an informed trust decision when presented with any certificate that is not already explicitly trusted. For example, in a hierarchical PKI, a certificate chain starting with a web server certificate might lead to a small CA, then to an intermediate CA, then to a large CA whose [[trust anchor]] is present in the relying party's web browser. In a bridged PKI, a certificate chain starting with a user at Company A might lead to Company A's CA certificate, then to a bridge CA, then to company B's CA certificate, then to company B's trust anchor, which a relying party at company B could trust.

{{IETF RFC |5280 }}<ref>{{IETF RFC |5280}} (May 2008), chapter 6., a standardized path validation algorithm for [[X.509]] certificates.</ref> defines a standardized path validation algorithm for [[X.509]] certificates, given a certificate path. (Path discovery, the actual construction of a path, is not covered.) The algorithm takes the following inputs:

* The certificate path to be evaluated;

* The current date/time;

* The list of [[Certificatecertificate Policypolicy]] [[Objectobject identifier]]sidentifiers (OIDs) acceptable to the relying party (or any);

* The trust anchor of the certificate path; and

* Indicators whether policy mapping is allowed and how/when/whether the "any" policy [[Object identifier|OID]] is to be tolerated.

Line 13 ⟶ 14:

* The public key algorithm and parameters are checked;

* The current date/time is checked against the validity period of the certificate;

* The [[revocation status]] is checked, whether by [[Certificate revocation list|CRL]], [[Online Certificate Status Protocol|OCSP]], or some other mechanism, to ensure the certificate is not revoked;

* The issuer name is checked to ensure that it equals the subject name of the previous certificate in the path;

* Name constraints are checked, to make sure the subject name is within the permitted subtrees list of all previous CA certificates and not within the excluded subtrees list of any previous CA certificate;

* The asserted [[Certificatecertificate Policypolicy]] [[Objectobject identifier|OIDs]] are checked against the permissible OIDs as of the previous certificate, including any policy mapping equivalencies asserted by the previous certificate;

* Policy constraints and basic constraints are checked, to ensure that any explicit policy requirements are not violated and that the certificate is a CA certificate, respectively. This step is crucial in preventing some [[man in the middle attacksattack]]s;<ref>[[Moxie Marlinspike]], [httphttps://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf New Tricks For Defeating SSL In Practice], [[Black Hat Briefings|Black Hat]] DC Briefings 2009 conference.</ref>

* The path length is checked to ensure that it does not exceed any maximum path length asserted in this or a previous certificate;

* The key usage extension is checked to ensure that is allowed to sign certificates; and

Line 24 ⟶ 25:

If this procedure reaches the last certificate in the chain, with no name constraint or policy violations or any other error condition, then the certificate path validation algorithm terminates successfully.

== External referenceslinks ==

{{reflist}}

== Implementations ==

* [http://www.carillon.ca/tools/pathfinder.php Pathfinder] is an open-source implementation of the algorithm in RFC 5280.

== See also ==