pkix-path

RFC 5280 X.509 certification path validation — pure Rust, no_std.

The core validation engine. Implements the RFC 5280 §6.1 path validation algorithm with a pluggable cryptography interface so you can swap in any signature backend without changing validation logic.

When to use this crate directly

Use pkix-path directly when you need:

• no_std (firmware, embedded, Caliptra/DPE)
• A custom signature backend (FIPS, hardware HSM, wolfCrypt)
• Fine-grained control over validation without revocation

For most applications, use pkix-chain instead, which wraps this crate together with revocation checking in a single ergonomic API.

Usage

use pkix_path::{validate_path, DefaultVerifier, TrustAnchor, ValidationPolicy};
use der::Decode as _;
use x509_cert::Certificate;

let chain = vec![
    Certificate::from_der(leaf_der)?,
    Certificate::from_der(intermediate_der)?,
];

let root_cert = Certificate::from_der(root_der)?;
let anchors = vec![TrustAnchor::from_cert(root_cert)];

let policy = ValidationPolicy::new(1_780_272_000);

let validated = validate_path(&chain, &anchors, &policy, &DefaultVerifier)?;
println!("anchor index: {}", validated.anchor_index);

Pluggable crypto

The SignatureVerifier trait is the seam between path validation logic and cryptographic operations. Implement it to use any backend:

use pkix_path::SignatureVerifier;
use spki::{AlgorithmIdentifierRef, SubjectPublicKeyInfoRef};

struct MyFipsVerifier;

impl SignatureVerifier for MyFipsVerifier {
    fn verify_signature(
        &self,
        algorithm: AlgorithmIdentifierRef<'_>,
        issuer_spki: SubjectPublicKeyInfoRef<'_>,
        message: &[u8],
        signature: &[u8],
    ) -> Result<(), signature::Error> {
        // dispatch to your FIPS-validated backend
        todo!()
    }
}

The DefaultVerifier provides RSA-PKCS1v15-SHA-256 and ECDSA-P-256-SHA-256 via RustCrypto. Enable the rsa and p256 features (both on by default).

no_std

pkix-path is no_std by default. The std feature enables std::error::Error impls on error types. Algorithm backends (rsa, p256) are no_std-compatible via default-features = false.

What is validated

Per RFC 5280 §6.1, for each certificate in the chain:

• Signatures — each cert's signature is verified against the issuer's SPKI
• Validity period — notBefore ≤ now ≤ notAfter
• Name linkage — cert.issuer == issuer.subject for each adjacent pair
• Trust anchor — final issuer matches a provided trust anchor
• BasicConstraints — intermediates must have cA = TRUE
• pathLenConstraint — enforced if present on intermediate CA certs
• KeyUsage — keyCertSign bit enforced on CAs (configurable via policy)
• Critical extensions — any unrecognised critical extension causes failure
• Certificate policies — §6.1 policy state machine including anyPolicy, requireExplicitPolicy, and policy inhibit counters
• Policy mappings — §6.1.3–6.1.5 mapping and constraint enforcement
• Name constraints — §4.2.1.10 subtree checking for DNS names, RFC 822 addresses, URIs, distinguished names, and IP addresses (IPv4/IPv6)
• Duplicate detection — issuer+serial uniqueness across the chain

Not validated

• Path building — chain must be caller-ordered, leaf first; use pkix-path-builder for unordered bags of certificates
• CRL/OCSP revocation — use pkix-revocation
• RFC 4518 full Unicode NFKC DN normalization (BMPString/TeletexString transcoding tracked as PKIX-l63j)

Standards

• [RFC 5280] §4.2 — Certificate Extensions
• [RFC 5280] §6 — Path Validation Algorithm
• [RFC 5280] §4.2.1.10 — Name Constraints
• [RFC 5280] §4.2.1.9, §6.1.5 — Certificate Policies and Policy Constraints
• [FIPS 186-5] — Digital Signature Standard (ECDSA)

License

Apache-2.0 OR MIT