Free tools Windows power users keep installed
One-click scans. No signup required.
No. RFC 5280 does not require certificate-policy processing, certification-path validation and CRL handling to be built as one linked component or use one data source. They are distinct concerns, but not three wholly independent validation steps: RFC 5280 includes policy processing in its path-validation procedure. CRLs are one way to determine revocation status, not a synonym for path validation.
What each concern answers
“Three layers” is a useful way to separate the questions a PKI implementation must address. It is an architectural description, not a requirement in RFC 5280 to create three separate services—or to combine them into one.
As an Amazon Associate I earn from qualifying purchases.
| Concern | Main inputs | Question answered | Standards location and limit |
|---|---|---|---|
| Certificate policies | Policy identifiers (OIDs), optional qualifiers, mappings and constraints | Which certificate-policy set is valid for this path, and does it meet the application’s policy requirements? | RFC 5280 Sections 4.2.1.4–4.2.1.5, 4.2.1.11, 4.2.1.14 and 6.1; processing updated by RFC 9618. An OID in a certificate does not mean every application accepts it. RFC 5280; RFC 9618. |
| Certification-path validation | Target certificate, prospective path, trust-anchor information, time and other validation inputs | Does this path satisfy the validation conditions for this application? | RFC 5280 Section 6.1 requires functionally equivalent external behavior, not a specific software architecture or path-building strategy. RFC 5280. |
| CRL-based revocation determination | A certificate, relevant CRL information and certificate/CRL fields | Does the applicable CRL-based status check indicate that the certificate has been revoked? | RFC 5280 Section 6.3 covers CRL processing; RFC 9608 defines a case where revocation checking is skipped. CRLs are not the only possible source or method for status information. RFC 5280; RFC 9608. |
Where certificate policy fits in validation
A certificate’s certificatePolicies extension contains one or more policy-information terms. Each term has a policy OID and may include qualifiers. In an end-entity certificate, those terms indicate the policies under which it was issued and its purposes; in a CA certificate, they constrain the policy set for paths that include that certificate. The special anyPolicy OID is 2.5.29.32.0. These rules are defined in RFC 5280 Section 4.2.1.4.
Policy is therefore not outside path validation. RFC 5280 Section 6.1 makes policy processing part of the procedure and has validation determine which certificate policies are valid for the path. That result depends on the certificates’ policy information and on mechanisms including policy mappings, policy constraints and the inhibitAnyPolicy control. anyPolicy should not be read as “skip all policy checks”: its effect depends on the validation inputs and those controls. The relying application’s accepted policies also matter; a certificate’s OID alone does not establish that the application will accept it.
#1 Best Overall
Path validation is not the same as path building
Path validation evaluates a prospective chain from a trust anchor to a target certificate against the applicable conditions. Those include checks such as signatures, names, validity at the relevant time and extension constraints. The trust anchor and application context matter, so a path is not simply “valid” in the abstract for every use.
Finding or assembling a sequence of certificates that could form a path is path building. RFC 5280 treats obtaining a supporting certificate sequence as outside the scope of its validation algorithm. It requires a conforming implementation to provide behavior functionally equivalent to the specified path-processing algorithm, but does not prescribe a literal internal procedure or a particular component topology. See RFC 5280 Sections 6.1 and 6.1.1.
What CRL handling does—and what it does not guarantee
A certificate revocation list (CRL) is a mechanism for communicating revocation information. When CRLs are used, RFC 5280 Section 6.3 specifies how to determine revocation status. Its certificate-processing text also recognizes status information and out-of-band mechanisms, so it is inaccurate to treat a CRL as the only possible status source. See RFC 5280 Sections 3.3, 6.1.3 and 6.3.
Recommended Free Tools
Building or validating a path does not, by itself, guarantee that timely revocation information has been obtained or checked. Nor does the standard support the blanket statement that every certificate must have a CRL. A particular application or deployment may set its own revocation requirements; those requirements should not be confused with a universal RFC 5280 mandate.
The noRevAvail exception
RFC 9608 defines the noRevAvail certificate extension for end-entity certificates where the CA publishes no revocation information. When the extension is present, the updated path-validation procedure skips the revocation-status step: “When the noRevAvail certificate extension is included in a certificate, all revocation checking is bypassed.” This is a defined no-revocation-information case, not a general-purpose shortcut. RFC 9608 warns that without revocation information, a relying party loses the ability to detect compromise through revocation; appropriate CA policy and practice are important. See RFC 9608 Sections 2, 4 and 6.
What later RFCs changed
RFC 9618: a different way to compute policy results
RFC 5280’s policy-tree processing can grow exponentially with path depth under policy mappings. RFC 9618 updates the computation to use a graph whose size is linear relative to the policies and mappings, addressing asymmetric resource costs. It states that the new algorithm does not change which certification paths are valid or which certificate policies are valid for them. This is a change to the computation structure, not to policy-acceptance semantics. See RFC 9618 Sections 1 and 3–5.
RFC 9608: an explicit case with no revocation information
RFC 9608 adds the noRevAvail case described above and updates path validation so the revocation step is skipped when that extension is present. It does not turn the extension into a general waiver for certificates whose status information is otherwise expected. See RFC 9608.
What this means for system design
RFC 5280 sets requirements for processing behavior, not a blueprint for software components. An implementation can organize policy evaluation, path processing and status retrieval according to its own architecture, provided it delivers the required behavior for its use case. The important distinction is that policy evaluation contributes to the path-validation result, while CRL processing is a separate revocation determination when that mechanism is used.
Quick Recap
Best Value
- Keep the application’s accepted-policy requirements explicit; certificate OIDs are inputs to evaluation, not a universal acceptance decision.
- Do not equate finding a certificate chain with validating it, or validating a path with having checked current revocation status.
- When defining a revocation policy, distinguish CRLs from other status mechanisms and account for any applicable exception such as
noRevAvail.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
