Expand description
Certification paths: which sequences of certificates lead from a certificate to an anchor the caller trusts, and what that costs.
One signature can have several valid paths, and a report shows them, because a cross-certified provider is recognized under one scheme by one path and under another by another. That is not the same as enumerating every path: a certificate set somebody else controls can hold a combinatorial number of them, and a browser asked for all of them stops answering. So the search is bounded in every direction it can grow, and when a bound is reached the answer says so. Silence about truncation would be a worse answer than the truncation.
Where the bound is on how many paths are returned, which paths are kept is not the order they were found in. A second path to the same anchor naming the same policies tells a reader nothing the first did not; a path to another anchor, or one naming other policies, is the whole reason several paths are shown at all. So a path that differs in either is kept ahead of a repeat of one already held.
An anchor is an input, never a discovery (RFC 5280 6.1): a self-signed certificate that happens to sit in the same pool is a certificate like any other, and a path that ends at one the caller did not name ends nowhere.
Structs§
- Anchor
- What the caller trusts, as the trust context named it.
- Bounds
- How far the search may go before it stops and says so.
- Context
- Everything the search asks of the caller: what is trusted, when, how far to look, what is being asked about, and who answers the questions this crate does not.
- Interval
- The UTC-label interval the path is built for, retaining leap/fractional labels.
- Outcome
- What the search found, and what it did not get to.
- Path
- One certification path: the certificates from the target up, the anchor they lead to, and what the authorities along it agreed the target was issued under.
- Policy
- What the caller was asking about, before any certificate was read.
- Rejection
- A semantic failure at its source;
Nonedenotes the whole supplied input. - Validation
Bounds - Local limits for checking a supplied path, with no alternative-path search.
- Validation
Context - Explicit execution inputs for static checking of a borrowed supplied path. Callers supply trusted anchors, cryptographic capability and application policy separately; no clock, network or trust discovery is performed here.
- Validation
Facts - Accepted static path facts, not a complete application trust verdict. The policy container owns and accounts its allocation; its OID values and the effective key still borrow the original certificate/anchor input.
- Working
Key - The key a certificate’s signature is checked with, and the parameters that are in force for it.
Enums§
- Build
Error - A path operation that could not finish, preserving the originating cause.
- Constraint
Source - The source of a path fact; certificate positions are leaf-first.
- Name
Constraint Failure - How a presented name fails an accumulated name constraint.
- Rejection
Reason - A completed semantic rejection, distinct from inability to execute a check.
- Truncation
- Which bound stopped the search, where one did.
- Validation
- The completed outcome of checking exactly one supplied path.
- Verified
- What a verifier says about one signature.
Traits§
Functions§
- build
- Builds the paths from one certificate to the anchors the caller trusts.
- validate
- Checks exactly the supplied leaf-first path to one explicit anchor.
Type Aliases§
- Build
Result - Result of path processing with the injected callbacks’ original error types.