Certificate Policies, Path Validation and CRL: Three Layers RFC 5280 Doesn't Require You to Link

Two implementations that both claim "we comply with RFC 5280" can reach different conclusions about the same certification path, and neither one is violating the standard. This happens because the RFC defines three separate mechanisms — the certificate profile, the path validation algorithm, and CRL checking — and only one of them has a strict mandatory floor. The other two leave explicit room for MAY.

This piece separates those three layers using the RFC's own text, without assuming how any particular library or real-world verifier implements them.

Layer 1: Certificate Policies is data in the certificate, not a process

Section 4.2.1.4 of RFC 5280 defines the Certificate Policies extension within the X.509v3 certificate profile, in the same block as Policy Mappings (4.2.1.5) and Policy Constraints (4.2.1.11). It's information that travels inside the certificate: a set of OIDs declaring under which policy it was issued.

That extension, by itself, doesn't validate anything. It's data available for some other process to use or ignore. The document's own table of contents shows the structural separation:

The certificate profile (Section 4) and path validation (Section 6) are different sections of the RFC. The fact that a certificate carries Certificate Policies doesn't imply the verifier will read them, let alone require them.

Layer 2: the path validation algorithm defines a minimum, not a maximum

Section 6.1 describes the basic certification path validation algorithm. The RFC is explicit about its scope:

"Thus, the path validation algorithm presented in Section 6.1 defines the minimum conditions for a path to be considered valid."

It's a floor. Any implementation can extend that floor, and the RFC says so using the same word it uses to mark anything optional: MAY.

"An implementation MAY augment the algorithm presented in Section 6.1 to further limit the set of valid certification paths that begin with a particular trust anchor."

The examples the text itself gives: applying a path length restriction to a specific trust anchor, requiring a particular form of alternative name in the target certificate, or imposing requirements on application-specific extensions. And there's one specific case that connects directly to layer 1: a trust anchor can be limited to trusting only paths associated with a particular certificate policy.

"...a trusted CA may only be trusted for a particular certificate policy. This restriction can be expressed through the inputs to the path validation procedure."

In other words: the Certificate Policies from layer 1 only matter if the algorithm from layer 2 receives them as input and decides to use them. An implementation can run the basic algorithm from Section 6.1, completely ignore those additional inputs, and still be RFC-compliant. The text is equally clear about self-signed trust anchors: they can carry a policy constraints extension stating that paths starting there should only be trusted for specific policies, but the basic algorithm "does not assume that this information is present" and "does not specify processing rules" for it. Whether to process it or ignore it is left to each implementation's discretion.

Layer 3: CRL checking is, literally, optional to implement as an algorithm

Section 6.3 describes how to determine whether a certificate is revoked when the revocation mechanism is a CRL. Here the RFC doesn't say MAY — it says something even stronger:

"Conforming implementations that support CRLs are not required to implement this algorithm, but they MUST be functionally equivalent to the external behavior resulting from this procedure when processing CRLs that are issued in conformance with this profile."

There's no need to implement the detailed step-by-step algorithm. It's enough to produce the same external result. This is a wide implementation freedom: two verifiers can reach the same revoked/not-revoked conclusion through completely different internal paths, and both are conformant.

There's also an operational detail the RFC flags that a basic implementation might overlook: when the CA signs certificates and CRLs with different private keys, verifying revocation requires building and validating a second, separate, full certification path for the certificate that signs the CRL.

"CRL checking in turn requires a separate certification path to be constructed and validated for the CA's CRL signature validation certificate."

The RFC even adjusts the level of obligation depending on the scenario:

"Applications that perform CRL checking MUST support certification path validation when certificates and CRLs are digitally signed with the same CA private key. These applications SHOULD support certification path validation when certificates and CRLs are digitally signed with different CA private keys."

With the same key, it's a MUST. With separate keys, it drops to SHOULD. An implementation that only covers the shared-key case isn't violating the RFC: it's covering the MUST and leaving out the SHOULD.

The three layers together

The diagram shows where the leeway is: the dotted arrow between Certificate Policies and the Section 6.1 algorithm is an optional input, not an automatic link. A certificate can declare a policy, and that declaration might never end up influencing the validation result, because it depends on whether the verifier requests it as input.

Why this matters for interoperability

Two verifiers can both accept exactly the same certification path as valid, even though one of them ignores the certificate's Certificate Policies and skips revocation checking entirely, while the other applies additional policy restrictions and full CRL checking with path validation for the CRL signing key. Neither one violates RFC 5280: the first covered the minimum from Section 6.1; the second covered additional MAYs that the RFC permits but doesn't require.

This is an editorial reading, not a textual finding from the RFC itself: the document doesn't address legal interoperability or legally valid digital signatures. But the normative structure — a narrow mandatory floor, wide optional extensions — explains why "RFC 5280 compliant" is a necessary condition, not a sufficient one, for two verification systems to reach the same verdict on a signature.

Limits of this reading

The excerpt of RFC 5280 available for this piece is truncated and doesn't cover the full detail of the initialization steps in Section 6.1, nor the step-by-step policy mapping algorithm. There's also no data here about what browsers, TLS libraries, or actual electronic signature engines do in practice: the RFC describes the standard, not the behavior of real software, and there's no evidence in this document about how many implementations do or don't activate each optional layer.

The text also doesn't mention OCSP or other modern revocation mechanisms — everything said here about "the algorithm not being mandatory" applies specifically to CRL, Section 6.3, and can't be extended without additional evidence to other revocation protocols.

Original source: https://www.rfc-editor.org/rfc/rfc5280