Certification path validation algorithm: Difference between revisions

Revision as of 14:37, 10 March 2016

Revision as of 14:40, 10 March 2016

Line 6:

* The certificate path to be evaluated;

* The current date/time;

* The list of [[Certificatecertificate Policypolicy]] [[object identifier]]s (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 16:

* 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]] [[object 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 attacks;<ref>Moxie Marlinspike, [http://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;