1. Introduction, Scope & Design Goals

This chapter establishes what pverify is, the precise boundaries of what it verifies and what it deliberately refuses to do, the audiences it serves, the input formats and Advanced-Electronic-Signature (AdES) levels it actually supports as of release v1.3.0, and the architectural stance — a pure-Rust, WASM-buildable verification kernel — that conditions every later design decision. It closes with a reader's guide to the remaining chapters.

The claims in this chapter are grounded in the source tree at the repository root; concrete evidence is cited as crates/<crate>/src/<file>.rs (with a function or line where it sharpens the point). Where the tool's behaviour is subtle — most notably its discipline of degrading to INDETERMINATE rather than fabricating a pass or a failure — the chapter describes what the code actually does, not an idealised summary.

1.1 What pverify Is

pverify is a Rust toolkit that verifies advanced electronic signatures (AdES) and emits a structured record of observed facts — never a business-level "valid / invalid / qualified" adjudication. This is the project's first and non-negotiable principle, ratified in the Constitution as Principle I, Fact-Reporting (.specify/memory/constitution.md, "Core Principles / I. Fact-Reporting (NON-NEGOTIABLE)"):

pverify outputs structured reports of observed facts, never business-level adjudications such as "qualified electronic signature" or "legally valid".

• The output JSON MUST enumerate every artefact consulted: certificate chain members, the CRLs/OCSP responses/TSA tokens fetched, their sources, and the evaluation performed against each.
• The ETSI EN 319 102-1 indication (TOTAL_PASSED / INDETERMINATE / TOTAL_FAILED) MAY be emitted as a machine-readable indicator, but pverify MUST NOT translate it into a domain verdict.
• pverify MUST NOT emit any text or field claiming legal validity, regulatory qualification, or admissibility.

The rationale is explicit in the Constitution: qualification of a signature depends on the retention period, the relationship between signing time and verification time, archive-timestamp requirements, and counterparty agreements that vary per relying party. A tool that pre-judges those concerns forces misuse. pverify therefore reports what it observed — which certificates it built into which chain, which CRLs and OCSP responses it consulted from which source, which timestamps it recomputed and against which imprint — and leaves the legal/business decision to the consumer.

The output of every verification run is a closed-schema JSON document. The top-level machine-readable verdict per signature is an ETSI EN 319 102-1 indication: one of TOTAL_PASSED, INDETERMINATE, or TOTAL_FAILED, represented by the closed enum Indication in crates/pverify-core/src/report/etsi.rs (declared at line 24). It is qualified by a precise machine-readable sub-indication drawn from the single closed enum SubIndication (same file, line 39), which is mirrored 1:1 into the root report-schema.json. Free-form verdict strings are forbidden by construction: adding a sub-indication value is an additive MINOR schema change, and removing or repurposing one is a MAJOR change.

The relationship between the JNSA デジタル署名検証ガイドライン (第 1.1 版) verdict vocabulary and pverify's ETSI indications is documented in docs/jnsa-conformance-statement.md; the high-level mapping is VALID → TOTAL_PASSED (within pverify's implemented check set), INVALID → TOTAL_FAILED, and INDETERMINATE → INDETERMINATE. The conformance statement is the authoritative cross-walk; this document does not restate it.

1.1.1 The "Cannot Affirm" Discipline

A defining behaviour of pverify — and one that professional auditors should internalise before reading any report — is that the tool will never fabricate a verdict it cannot substantiate. Where pverify cannot establish a fact, it degrades to INDETERMINATE with a precise sub-indication rather than inventing a TOTAL_FAILED (which would falsely allege tampering or revocation) or a TOTAL_PASSED (which would falsely affirm trust). Concrete manifestations of this discipline:

• An unsupported signature algorithm OID (e.g. Ed448, brainpool, P-521, GOST, SM2) yields INDETERMINATE / signature_algorithm_unsupported, not a failure — so a consumer can grep for "not yet handled" without confusing it with cryptographic compromise.
• A revoked timestamp-authority (TSA) certificate yields the revoked_no_poe sub-indication at INDETERMINATE (introduced in branch 033), reflecting that a revoked TSA cert does not by itself prove the protected signature is a forgery — there may be a proof-of-existence established before the revocation.
• A multi-signer CMS is deliberately refused with INDETERMINATE / cms_multi_signer_unsupported (crates/pverify-core/src/verify.rs, verify_cades, line ~497 calling cades_multi_signer_entry at line 1890) rather than silently reporting only the first signer — a silent single-signer report would be a misleading affirmation.
• An unreachable revocation responder or an offline run with no cached revocation material yields IndeterminateRevocationOffline / revocation_not_checked_offline, not a fabricated responder contact (the offline-honesty principle, Constitution §VII / §I).
• The opt-in algorithm policy (CRYPTREC/NIST) produces, at worst, crypto_constraints_failure_no_poe at INDETERMINATE, mirroring ETSI's CRYPTO_CONSTRAINTS_FAILURE_NO_POE; it never escalates to TOTAL_FAILED.

This discipline is why a pverify report is auditable: every INDETERMINATE carries a closed-enum reason naming exactly which fact could not be established. See Chapter 14 (Result Model: indications, diagnostic data & schema) for the full sub-indication vocabulary and Chapter 5 §5.7 together with Chapter 14 (ETSI indication aggregation) for the precedence rules.

1.2 Target Users

pverify serves three concentric audiences, as set out in the Vision Statement (docs/vision-statement.md §3):

1. Primary — integrating developers. Back-end engineers at electronic- application SaaS providers, local-government vendors, and document- management vendors who embed pverify-core to add GPKI signature verification to their own products. The library-first design (Constitution §V) exists for them: pverify-core is an I/O-free no_std + alloc crate that can be driven from a native binary, a WebAssembly module, or a Cloudflare Worker without changing the verification logic.

2. Secondary — verification operators and auditors. Local governments, audit firms, and public-document custodians who run one-off verifications or audit responses by invoking the CLI directly. The reproducibility (Constitution §II) and auditability (§III) guarantees exist for them: a --from-bundle invocation re-runs a verification weeks later from a content-addressed bundle and yields a byte-identical report.

3. Tertiary — researchers and standardisation participants. Those who use pverify as a reference implementation of ETSI EN 319 102-1 and RFC 5280 §6 for benchmarking and test-vector validation.

The overarching customer context is the Japanese Government Public Key Infrastructure (GPKI): pverify is built so that a relying party receiving a GPKI-signed CAdES/PAdES/XAdES document — including signatures that traverse the GPKI Bridge CA structure for inter-ministry or government-to-private trust — has a common, hard, reproducible verification substrate. It is simultaneously aware of the European eIDAS / ETSI corpus (EU Trusted Lists, CAdES/PAdES/XAdES/JAdES/ASiC baseline levels), so the same engine verifies both the GPKI/JNSA profile and the eIDAS profile.

1.3 Scope: What pverify Verifies

pverify verifies five AdES signature families, three of them across multiple baseline levels. The supported surface is intentionally honest: where a format variant or AdES level exceeds the current implementation, the tool refuses with a closed-enum sub-indication at INDETERMINATE rather than guessing.

1.3.1 Supported Input Formats

The verification kernel performs a content sniff over the leading bytes to route an input to the correct per-format verifier (crates/pverify-core/src/verify.rs, detect_format, line 359):

The ZIP-magic case for ASiC is handled before the byte sniff: if the host extracted ASiC container signatures, verify_with routes to the ASiC orchestrator unconditionally, because the container bytes start with the ZIP magic that would otherwise fall through to CAdES (crates/pverify-core/src/verify.rs, verify_with, line ~195: if !request.asic_signatures.is_empty()). A bare ZIP with no recognised ASiC content yields INDETERMINATE / asic_unsupported_container (line ~225). The XML-vs-JSON sniff is non-colliding by construction: an XAdES input begins with < and a JAdES input with { (line 356, "JSON and XML are mutually exclusive on the first non-whitespace byte").

1.3.2 Supported AdES Baseline Levels

The ETSI baseline-level vocabulary (B-B/BES, B-T, B-LT, B-LTA) is used exactly, and the tool is explicit about which levels it actually verifies per format.

The CAdES format-promotion ladder is implemented at crates/pverify-core/src/verify.rs lines 1034–1042: the presence of an archive-time-stamp promotes the wire format to CAdESLta; otherwise any LT/LTA payload promotes to CAdESLt; otherwise a signature-time-stamp promotes to CAdEST; otherwise the format is CAdESBes.

The B-LTA / archive mechanisms differ by format and are named precisely: CAdES uses archive-time-stamp-v3 (ETSI EN 319 122-1 §6.3.4, with imprint recomputation; a mismatch is archive_timestamp_imprint_mismatch, TOTAL_FAILED), PAdES uses /DocTimeStamp (a PDF /Type /DocTimeStamp dictionary carrying an RFC 3161 token over a revision's ByteRange, surfaced as a timestamp with the pades_doc_timestamp VRT kind), and XAdES uses xades:ArchiveTimeStamp (ETSI TS 101 903 v1.4.2 Annex A.1.5; imprint = exc-C14N of the full ds:Signature element minus the node-set covered by any later ArchiveTimeStamp in the same signature — implemented in branch 036 by XadesUnverifiedTimestamp.imprint_input: Vec<u8> with bergshamra-c14n node-set subtract API, adding SignatureFormat::XadesBLta).

1.3.3 Refusal Behaviour for Unsupported Variants

The honest refusals are first-class report outcomes, each carrying a closed- enum reason:

• XAdES that is detached/enveloping (rather than enveloped), or uses a non-exclusive canonicalization method, maps to XadesProfile::Unsupported with reason DetachedOrEnveloping or NonExclusiveC14n (crates/pverify-core/src/xades.rs, UnsupportedReason at line 151), surfacing as INDETERMINATE / xades_unsupported_profile (or the canonicalization-specific sub-indication). One exception: an ASiC-resolved detached XAdES is verified, because the ASiC container supplies the resolved data-object bytes (line ~133). The supported shape is enveloped + Exclusive C14N (W3C exc-c14n), provided by the audited bergshamra-c14n crate.
• JAdES refusals via JadesUnsupportedReason: DetachedSigD (the JWS sigD detached profile), CompactSerialization (JWS Compact), HigherLevel (only rfsTst/tstVd — branch 037 implemented B-T/B-LT/B-LTA), and NotJadesBaseline.
• Multi-signer CMS refuses with cms_multi_signer_unsupported rather than reporting only the first signer (see §1.1.1).
• An unrecognised ZIP that is not a valid ASiC container yields asic_unsupported_container.

1.3.4 Cryptographic Primitives Supported

Certificate, CRL, OCSP, TSA, and signer signatures are all verified through RustCrypto-only primitives, dispatched by OID and SPKI shape in crates/pverify-core/src/crypto.rs (verify_with_alg). The supported signature families are:

• RSA PKCS#1 v1.5 and RSA-PSS (the latter verified via verify_rsa_pss, line 151; note the CMS OID table at line ~284 deliberately rejects PSS so PSS only flows through the dedicated PSS path).
• ECDSA P-256 / P-384 (NIST curves; SHA-256/384/512 digests).
• Ed25519 (RFC 8032 "pure", RFC 8410 SPKI OID 1.3.101.112).
• ML-DSA (FIPS 204; ML-DSA-44/65/87 at OIDs 2.16.840.1.101.3.4.3.17/18/19, MlDsaParams at line 216) — a forward-looking post-quantum dispatch.

Any signature algorithm outside this set surfaces as signature_algorithm_unsupported at INDETERMINATE. There is no signing or key-generation surface in the production dependency set — the cryptography is verify-only.

1.3.5 The Standards pverify Treats as Normative

Per Constitution §IV (Specification-Compliance, NON-NEGOTIABLE), the implementation treats the following as primary normative references, and any deviation must be enumerated in the relevant feature spec with a written rationale:

• RFC 5280 — X.509 certificates, CRLs, and §6 path validation (the basic- plus algorithm: chain construction by issuer/subject DN matching, validity windows, BasicConstraints, KeyUsage, Name Constraints §4.2.1.10, and certificate-policy processing §6.1).
• RFC 5652 — CMS SignedData (the container for CAdES and the embedded payload of PAdES).
• RFC 3161 / 5816 — time-stamp tokens (TSP), including RFC 5816 ESS signing-certificate binding.
• RFC 6960 — OCSP, including §4.2.2.2 designated-responder authorisation, freshness, and nonce handling.
• ETSI EN 319 102-1 — signature-validation procedures and the indication/sub-indication value space.
• ETSI EN 319 122 (CAdES) / 319 142 (PAdES) / 319 132 (XAdES) / TS 119 182 (JAdES) / 319 162 (ASiC) — the AdES container formats.
• eIDAS and the EU Trusted List standard ETSI TS 119 612 (ingested by pverify-eutl).
• CRYPTREC 電子政府推奨暗号リスト (primary) and NIST SP 800-57 Part 1 / SP 800-131A (secondary) — the algorithm-policy authority ratified in the Constitution at v1.2.0.
• デジタル庁 デジタル社会推進標準ガイドライン and the JNSA デジタル署名検証ガイドライン (第 1.1 版) — the GPKI/Japanese profile, including the §4 recursive-outer-covering rule pverify implements for per-object Validation Reference Times.

1.4 Out of Scope (Explicit Non-Goals)

pverify is deliberately bounded. The following are out of scope for the v1.x line, drawn from the Vision Statement §6 and reinforced by the fact-reporting principle:

• Signature generation. pverify is verification-only; signing is another project's responsibility. The crypto layer has no signing or key-generation API in production dependencies.
• Legal-validity / qualification adjudication. Forbidden by Constitution §I. pverify never emits "qualified electronic signature", "legally valid", or any admissibility claim.
• JPKI (My Number Card) signature verification. JPKI is a separate PKI from GPKI; out of scope for the current line (revisit candidate for a v2.0+ exploration).
• A user-facing GUI. pverify ships as a library, a CLI, and a WASM module only; any GUI is left to third parties.
• QTSP / QES certification. pverify claims ETSI conformance for its implemented check set but does not pursue qualified-trust-service-provider certification.

Format-level carve-outs within the supported families are equally explicit and are surfaced as closed-enum refusals (not silent passes): higher JAdES baseline levels, detached/enveloping XAdES, non-exclusive C14N, multi-signer CMS, and any signature algorithm outside the supported set (§1.3.3, §1.3.4). The PAdES /DSS work of branch 034 also explicitly excludes generating DSS, promoting DSS /Certs to trust anchors, validating VRI /TU//TS internal consistency, and the otherRevInfo field — these are out of scope by design.

1.5 Design Goals — the Pure-Rust + WASM Dual-Target Stance

The single most consequential design decision in pverify is the boundary between an I/O-free, no_std + alloc, WASM-buildable verification kernel (pverify-core) and a constellation of host-side crates that perform all container/document parsing, network fetch, filesystem access, and clock reads. This is not an aesthetic preference; it is enforced by the Constitution and by empirical CI gates. The goals it serves are:

1.5.1 Library-First, I/O-Free Core (Constitution §V)

pverify-core performs all cryptography, RFC 5280 §6 path validation, revocation evaluation (CRL/OCSP), timestamp and VRT derivation, algorithm- policy evaluation, and ETSI indication aggregation. The crate declares #![no_std] and #![forbid(unsafe_code)] at the top of crates/pverify-core/src/lib.rs (lines 11–12), and pulls in only the alloc crate (line 15). The three host concerns the kernel cannot perform for itself — the verification clock, revocation material, and the trust-anchor set — are trait-mediated: Clock (line 76), RevocationFetcher (line 98), and TrustAnchorStore (line 139) in crates/pverify-core/src/traits.rs. The kernel performs zero network, filesystem, or ambient-clock access; its derive_vrt and derive_validation_objects functions are pure compute.

1.5.2 No Document Parsing in the Core (Constitution §V)

Because PDF, XML, ZIP, and JSON cannot be parsed in a no_std kernel without dragging heavyweight, often unsafe-laden, non-WASM-clean dependencies into the trusted compute base, all container/document parsing happens in host crates and feeds the kernel model-free byte structures via additive VerificationRequest fields (crates/pverify-core/src/verify.rs, line 69 onwards: pdf_signature_dicts, pdf_validation_data, xades_components, jades_components, asic_signatures). The kernel consults only the field matching the sniffed format; a non-PDF input carries an empty pdf_validation_data, and so on. This boundary is empirically enforced by scripts/cargo-tree-gate.sh, which runs cargo tree -e normal --no-default-features -p pverify-core and fails the build if lopdf, zip, flate2, bergshamra-c14n, pverify-eutl, pverify-aatl, or any host-only crate appears in the core graph.

1.5.3 WASM Compatibility (Constitution §VI, NON-NEGOTIABLE)

pverify-core must compile and run on wasm32-unknown-unknown. Cryptography is RustCrypto-only: ring, aws-lc-rs, OpenSSL FFI, and the rustls default provider are prohibited anywhere in the core or WASM graph. This is empirically gated by cargo build --target wasm32-unknown-unknown -p pverify-core plus the cargo-tree gate. The pure-Rust crypto stance is inherited from the prior project civ (Vision Statement §8.5) and is what lets the same kernel run from a CLI to a Cloudflare Worker to an in-browser WASM module.

1.5.4 CLI ↔︎ WASM Parity

The native CLI (crates/pverify-cli) and the browser WASM host (web/pverify-wasm) run byte-identical host extractors and the identical verify_with kernel, producing byte-identical reports for identical inputs. For PAdES, the native PDF parse (pverify-cli/src/pdf.rs, lopdf) and the in-browser parse (web/pverify-wasm/src/lib.rs, lopdf) extract the same PdfSignatureDescriptors and the same /DSS+/VRI validation material; this parity is an enforced invariant covered by parity tests over the extractors.

1.5.5 Reproducibility and Byte-Identity (Constitution §II)

For the same inputs (signed document, trust anchors, verification time, and revocation material), pverify produces byte-identical output regardless of when or where it runs. The verification time is injectable via --at <RFC3339> and otherwise captured once at CLI startup; the VRT engine reads only this request_at value as its time source, never Clock::now. A further invariant governs additive features: an additive feature must leave the report body byte-identical except the schema_version string when its inputs are absent or it is disabled. For example, a PDF with no /DSS produces a report identical to the pre-034 output except for schema_version (FR-008); the algorithm policy, when off (the default), leaves signatures[].algorithm_validity absent; and the embedded-revocation fall-through fires only when the live/CDP channel is indeterminate, so online successes stay byte-identical.

1.5.6 The Schema as a Closed Promise

The report shape carries a SemVer string, SCHEMA_VERSION, currently "1.10.0" (crates/pverify-core/src/report/schema.rs). The schema-versioning discipline is strict and additive: the SubIndication, RevocationOutcome, and ValidationObjectOrigin enums and the report struct are closed and mirrored 1:1 in the root report-schema.json. Adding a closed- enum value or an optional field is a MINOR bump; removing or repurposing one is MAJOR. Deprecated variants (e.g. the historical bridge_ca_required_unsupported) are retained for stored-report deserialization but are no longer emitted. Branch 034, for instance, appended two ValidationObjectOrigin variants — PdfDss and PdfVri (crates/pverify-core/src/report/validation_objects.rs) — after the existing variants, declaration-order being sort-order, and bumped the schema 1.5.0 → 1.7.0 accordingly. Subsequent additive slices continued the MINOR-per-slice discipline: branch 035 added OcspAttempt.request_der_hex and CdpEntry structured form (1.7.0 → 1.8.0 → 1.9.0); branch 037 added three new SignatureFormat values (JAdES-B-T, JAdES-B-LT, JAdES-B-LTA) and the previously-unschemed XAdES-B-LTA / LTV-JWS variants (1.9.0 → 1.10.0).

Note on the README disclosure block. The repository README.md is a historical artefact pinned at the v0.7 development line; its running text states schema_version stays "1.1.0" and the capability phase "v0.6-bridge-acceptance". The authoritative live value is the SCHEMA_VERSION constant in report/schema.rs ("1.10.0"), whose doc-comment narrates each bump from 1.0.0 through 1.10.0. Readers should treat the source constant, not the README, as normative for the current release.

1.6 Cross-Cutting Invariants at a Glance

The following invariants are referenced throughout the design document; they are listed here once so later chapters can cite them by name. Each is grounded in code and in the Constitution.

1.7 Reader's Guide to the Rest of the Document

This document is organised so that an auditor can read it top-to-bottom, or jump directly to the subsystem under review. The chapter numbering below reflects the integrated design specification; cross-references in later chapters use these numbers.

• Chapter 1 (this chapter) — Introduction, scope, target users, supported formats and AdES levels, the pure-Rust + WASM stance, and cross-cutting invariants.
• Architecture chapters — the system architecture overview, the 11-member crate topology and the host → clean → core dependency direction, and the end-to-end data flow from input acquisition through report serialization. These elaborate §1.5's boundary into the concrete crate graph and the six-stage verification pipeline (host parse → request assembly → format dispatch → per-signature verification → per-object VRT → indication aggregation → report serialization).
• Path-validation chapter — RFC 5280 §6 basic-plus: depth-first chain construction with backtracking and DER-fingerprint cycle detection, the Name-Constraints state machine, certificate-policy processing, and Bridge-CA cross-certificate traversal (the GPKI inter-domain case).
• Revocation chapter — CRL (RFC 5280) and OCSP (RFC 6960) evaluation, the embedded-material fall-through that fires only when the live/CDP channel is indeterminate, and the closed RevocationOutcome vocabulary.
• Timestamp & VRT chapter — RFC 3161/5816 token verification and the recursive-outer-covering engine that derives a per-object Validation Reference Time.
• Per-format chapters — CAdES, PAdES (including the branch-034 /DSS / /VRI / revocationInfoArchival material), XAdES, JAdES, and ASiC, each describing the supported shape, the refusal cases, and the host extractor.
• Report & schema chapter (Chapter 14) — the closed-enum vocabulary, the ETSI indication aggregation precedence (aggregate_etsi), the validation_objects inventory and its ValidationObjectOrigin provenance tags, and the schema-versioning rules.
• Conformance & reproducibility chapters — the JNSA conformance statement cross-walk, the CI gate battery (test, fmt+clippy, WASM build, cargo audit/cargo vet, perf-gate, cargo-tree gate), and the reproducibility / byte-identity guarantees.

Where this chapter has summarised a behaviour (the cannot-affirm discipline, the format ladder, the trait boundary), the corresponding subsystem chapter provides the field-level detail and the failure-mode enumeration. Readers auditing a specific verdict should begin with the report-schema chapter to locate the relevant sub-indication, then follow its cross-reference into the subsystem that produces it.

2. Design Principles & Project Constitution

This chapter is the normative anchor for the rest of the specification. Where later chapters describe what a particular crate or code path does, this chapter establishes why it is permitted to do it — and, just as important, what it is forbidden from doing. The governing instrument is the project constitution at .specify/memory/constitution.md (version 1.2.0, ratified 2026-06-10, last amended 2026-06-22). The constitution supersedes ad-hoc conventions, READMEs, and reviewer preference: "Where they conflict, the constitution wins" (Governance clause). Every principle quoted below is reproduced verbatim from that file, with the article number it carries there.

The constitution defines seven Core Principles (I–VII), a Technology Stack Constraints section, a Phased Path Validation Roadmap, an explicit Out-of-Scope list, and a Governance / versioning policy. Sections 2.1–2.10 of this chapter walk those articles in the order an auditor most needs them, ground each in the code that enforces it, and then 2.11 summarises the cross-cutting invariants (with 2.12 recording the Out-of-Scope bounds) that the architecture survey (Chapter 3) and the implementation chapters (Chapters 5–13) repeatedly rely upon.

A note on terminology: throughout this document "the kernel" or "the core" refers to the pverify-core crate, and "host" refers to any crate that performs I/O on its behalf (pverify-cli, web/pverify-wasm, pverify-eutl, pverify-aatl, the extraction crates). The crate topology that realises this host/kernel split is detailed in Chapter 3; this chapter explains the constitutional rationale for the split.

2.1 The Constitution as a Versioned, Testable Contract

The constitution is not a vision statement; it is a versioned contract under its own Semantic Versioning regime (Governance → Versioning policy):

• MAJOR: a principle is removed, redefined incompatibly, or a NON-NEGOTIABLE marker is dropped; an Out-of-Scope item is brought in.
• MINOR: a new principle or section is added, or existing guidance is materially expanded.
• PATCH: clarifications, wording, typography, or non-semantic edits.

Each amendment carries a "Sync Impact Report" comment at the head of the file recording the version delta, the principles touched, and the rationale for the SemVer classification. The most recent amendment (1.1.0 → 1.2.0) ratified the algorithm-policy default table; the report is explicit that no NON-NEGOTIABLE marker was dropped and no Out-of-Scope item was brought in, which is precisely why the bump is MINOR rather than MAJOR.

Three of the seven principles are marked NON-NEGOTIABLE: I (Fact-Reporting), IV (Specification-Compliance), and VI (WASM Compatibility). The marker is load-bearing: dropping it is a MAJOR amendment by definition. The constitution also pins a number of values that are themselves constitutional surfaces — the algorithm-policy default table (§2.8) is the salient example, where the code constant pverify_core::algorithm_policy::AlgorithmPolicy::default_policy() "MUST byte-match specs/032-algorithm-validity/contracts/default-policy.md (test C-3)". That is the model the whole project follows: a principle is only real if a test fails when it is violated. The remainder of this chapter identifies, for each principle, the code and the test that hold the line.

2.2 §I Fact-Reporting / "Cannot Affirm" (NON-NEGOTIABLE)

Principle I is the philosophical spine of the entire tool. Quoted verbatim:

I. Fact-Reporting (NON-NEGOTIABLE)

pverify outputs structured reports of observed facts, never business-level adjudications such as "qualified electronic signature" or "legally valid".

• The output JSON MUST enumerate every artefact consulted: certificate chain members, the CRLs/OCSP responses/TSA tokens fetched, their sources, and the evaluation performed against each.
• The ETSI EN 319 102-1 indication (TOTAL_PASSED / INDETERMINATE / TOTAL_FAILED) MAY be emitted as a machine-readable indicator, but pverify MUST NOT translate it into a domain verdict.
• pverify MUST NOT emit any text or field claiming legal validity, regulatory qualification, or admissibility.

Rationale: qualification depends on retention period, signing-vs-verification time, archive-TS requirements, and counterparty agreements that vary per user. A tool that pre-judges these forces misuse.

This principle has two operational consequences that pervade the codebase.

2.2.1 Enumeration over verdict

The report is an inventory, not a yes/no. The kernel derives a consolidated material inventory — every certificate, CRL, OCSP response and timestamp token consulted, each tagged with its provenance — in derive_validation_objects (crates/pverify-core/src/report/validation_objects.rs). That function is a pure read over the completed &Report tree (no recomputation), and it records, for every object, where it came from. The provenance vocabulary is the closed enum ValidationObjectOrigin (report/validation_objects.rs, lines 98–118): signature_embedded, bundle, fetched_online, trust_anchor, supplied_input, and — appended for the PAdES /DSS+/VRI work — pdf_dss and pdf_vri. The point of these tags is auditability (§2.4): a reader can see not only that a CRL was used but whence it was obtained, which is exactly the "their sources" requirement of Principle I.

2.2.2 "Cannot affirm": INDETERMINATE is a first-class result

The second, subtler consequence is the "cannot affirm" discipline. Where pverify cannot establish a fact, it MUST NOT fabricate either a failure or a pass; it degrades to ETSI EN 319 102-1 INDETERMINATE with a precise, closed-enum sub-indication. This is the difference between not knowing and knowing the answer is negative, and the tool refuses to collapse the two. The top-level indication is the closed enum Indication (crates/pverify-core/src/report/etsi.rs); the qualifying reason is the closed enum SubIndication in the same file. The canonical instances of the discipline:

The multi-signer case is the clearest illustration of the principle's active enforcement. A naive verifier would silently report only the first SignerInfo; pverify deliberately refuses. The code comment at verify.rs:487 records the reasoning, and cades_multi_signer_entry returns the INDETERMINATE / cms_multi_signer_unsupported entry rather than a partial pass. This is "cannot affirm" made executable: pverify will not affirm a signature it has not fully evaluated.

Equally, a revoked TSA certificate does not become a TOTAL_FAILED forgery claim. The 033 work introduced revoked_no_poe: a revoked timestamping authority means the timestamp's proof-of-existence is no longer trustworthy, so the time anchor is unavailable — an indeterminacy, not a proven forgery of the signature. Encoding that as INDETERMINATE rather than TOTAL_FAILED is a direct application of §I. The aggregation that enforces "never mask a proven failure" is described in §2.11.

2.2.3 No legal verdict

The third bullet — no claim of legal validity, qualification, or admissibility — is honoured by omission: the report schema (report-schema.json, mirrored from crates/pverify-core/src/report/) carries no qualified, legally_valid or admissible field, and the indication enum stops at the three ETSI values. The rationale clause is unusually explicit for a constitution: qualification "depends on retention period, signing-vs-verification time, archive-TS requirements, and counterparty agreements that vary per user." pverify reports the facts those determinations rest on; it does not make the determination.

2.3 §II Reproducibility & Verdict Byte-Identity

II. Reproducibility

For the same inputs (signed document, trust anchors, verification time, and revocation material), pverify MUST produce byte-identical outputs irrespective of when or where it runs.

• Verification time MUST be injectable (--at <RFC3339>) to support signing-time and historical evaluations.
• All network I/O MUST be mediated by traits so a --from-bundle invocation reproduces a previous run with no external calls.
• Non-deterministic data sources (system clock, ambient TLS roots, randomised ordering) MUST NOT influence the report.

Reproducibility is the property that makes a verification report evidence. The constitution defines the reproducibility tuple precisely: (signed document, trust anchors, verification time, revocation material). Given that tuple, the output is byte-identical regardless of wall-clock time, host, or network reachability.

2.3.1 Injectable time, captured once

The CLI captures the verification time exactly once at startup (or takes it from --at, which always wins) and threads it through as request_at. The kernel never reads a wall clock for verification logic — the per-object VRT engine in crates/pverify-core/src/vrt/ derives reference times only from request_at and from the timestamp tokens present in the structure, never from Clock::now(). The Clock trait (crates/pverify-core/src/traits.rs:76) exists for host plumbing, not for verification decisions; this separation is what makes a --at <RFC3339> historical evaluation deterministic.

2.3.2 Trait-mediated I/O ⇒ --from-bundle reproducibility

Every external dependency the kernel has — clock, revocation material, trust anchors — is a trait: Clock, RevocationFetcher, TrustAnchorStore (crates/pverify-core/src/traits.rs, lines 76, 98, 139). The kernel performs no network, filesystem, or clock access of its own. This is what allows --from-bundle to replay a previous run with zero external calls: the bundle supplies the same revocation material the original run fetched, fed back through the same RevocationFetcher trait surface. An independent auditor re-running against the bundle obtains the identical report — which is precisely the Auditability guarantee of §III (§2.4).

2.3.3 Verdict byte-identity on additive / off features

A corollary the project enforces aggressively is byte-identity under additive features. When a feature is disabled or its inputs are absent, the report body MUST be byte-identical to the prior release except for the schema_version string. Concrete instances:

• A PDF with no /DSS produces a report that differs from the pre-034 baseline only in schema_version (the 034 FR-008 requirement). The PAdES validation- data fields are additive Vec/Default on VerificationRequest, empty for non-PDF and no-DSS inputs.
• Algorithm policy off (the default) yields a body byte-identical to the pre-032 report except schema_version (the 032 SC-001 requirement; §2.8).
• The embedded-revocation fall-through fires only when the live/CDP channel is indeterminate (the 019 precedent), so an online live-fetch success stays byte-identical regardless of whether embedded material was present.

This discipline is why each additive slice bumps schema_version by a MINOR increment and nothing else changes in the common path. The current report-shape version is SCHEMA_VERSION = "1.10.0" (crates/pverify-core/src/report/schema.rs:line).

2.3.4 No ambient non-determinism

The constitution explicitly bans the system clock, ambient TLS roots, and randomised ordering from influencing the report. Trust anchors are supplied explicitly (--trust-anchors <DIR>, or ingested by pverify-eutl/pverify-aatl into ordinary anchors), never read from an OS trust store. The kernel is no_std (§2.6) and therefore has no access to ambient OS state at all.

2.4 §III Auditability — The Verification Bundle

III. Auditability

A verification run MUST be capable of emitting a self-contained "verification bundle" that embeds every certificate, CRL, OCSP response, and TSA token used, such that an independent third party can re-run pverify against the bundle and obtain the same report.

Auditability is the operational pay-off of Reproducibility (§II) and Fact-Reporting (§I) combined. Because the kernel is I/O-free and trait-mediated, the CLI can capture the full set of consulted artefacts during an online run and materialise them as a bundle directory (<bundle>/crls, <bundle>/ocsp, <bundle>/trust-anchors), then a later --from-bundle run replays them through the same RevocationFetcher/TrustAnchorStore traits. The consolidated validation_objects inventory (§2.2.1) is the in-report manifest of exactly what was used and with what provenance, so a third party can cross-check the bundle contents against the report. The bundle value of ValidationObjectOrigin marks material that came from the bundle; in from_bundle mode an object retains its original provenance where known (report/validation_objects.rs comments around L303). The audit chain is therefore closed: report → manifest → bundle → re-run → identical report.

The CLI modes that realise this are the closed Mode enum {Online, Offline, FromBundle} (pverify-cli/src), mapped to the kernel's revocation VerificationMode. See Chapter 3 for the mode plumbing.

2.5 §IV Specification-Compliance (NON-NEGOTIABLE)

IV. Specification-Compliance (NON-NEGOTIABLE)

The implementation treats the following as primary normative references:

• RFC 5280 (X.509, CRL, §6 Path Validation)
• RFC 5652 (CMS)
• RFC 3161 / 5816 (TSP)
• RFC 6960 (OCSP)
• ETSI EN 319 102-1 (signature validation procedures)
• ETSI EN 319 122 / 319 142 (CAdES / PAdES); 319 132 (XAdES, v0.4+)
• デジタル庁 デジタル社会推進標準ガイドライン (GPKI provisions)
• JIS X 5092 / 5093 (CAdES / XAdES Japanese translations)

Behavioural correctness MUST be demonstrated through public test vectors: ETSI conformance suites, デジタル庁 published samples, and project-maintained golden cases. Deviations from any reference document MUST be enumerated in the relevant feature spec with a written rationale.

This principle pins the normative corpus and — crucially — demands that correctness be demonstrated by public test vectors, not asserted. The mapping of standard → implementing module is the subject of Chapters 5–13; this section records the contract and the AdES-level vocabulary, which §IV makes binding.

2.5.1 The standards-to-module map (orientation)

2.5.2 Honest AdES-level vocabulary

§IV's "Deviations … MUST be enumerated … with a written rationale" clause is the reason pverify is precise about what level of each format it actually verifies, rather than claiming blanket support. The supported matrix, grounded in the format-promotion ladder at verify.rs:1034-1042 and the per-format verifiers:

The refusals are not bugs; they are §I/§IV in concert — the tool declines to affirm a level it has not implemented, and the deviation is enumerated in the corresponding feature spec. See Chapter 5 (CMS/CAdES), Chapter 6 (PAdES), Chapter 7 (XAdES/ASiC), and Chapter 8 (JAdES) for the detail.

2.6 §V Library-First & §VI WASM Compatibility (NON-NEGOTIABLE)

These two principles are the architectural keystone and are best read together.

V. Library-First

pverify-core MUST be implemented as an I/O-free no_std + alloc library so the CLI binary and the Cloudflare Workers reference build sit on a single core. Network access, time, and trust-anchor storage MUST be expressed as traits — RevocationFetcher, Clock, TrustAnchorStore — implemented per target rather than baked into the core.

VI. WASM Compatibility (NON-NEGOTIABLE)

Apart from optional native-only acceleration paths, pverify-core MUST compile and run on wasm32-unknown-unknown.

• ring, aws-lc-rs, and OpenSSL FFI dependencies are PROHIBITED in the core and in any crate that the core or the Workers build transitively pulls in. Only the pure-Rust RustCrypto ecosystem is permitted.
• The Workers build MAY delegate hashing and public-key verification to the Web Crypto SubtleCrypto API to reduce bundle size, provided the resulting output remains byte-identical to the native path under Principle II.
• Adding a feature flag that re-enables a banned dependency (e.g. rustls with default features, civ's vp-federation) is PROHIBITED.

2.6.1 The kernel is no_std, unsafe-free, I/O-free

The first three lines of crates/pverify-core/src/lib.rs are the enforcement of both principles:

#![no_std]
#![forbid(unsafe_code)]
#![deny(missing_debug_implementations)]
extern crate alloc;

#![no_std] makes it structurally impossible for the kernel to touch the OS (no std::fs, no std::net, no SystemTime); #![forbid(unsafe_code)] is a hard compile error on any unsafe block — there is no allow override. The kernel uses only alloc. The host concerns it genuinely needs are the three traits in traits.rs (§2.3.2), implemented once for the native target and once for WASM.

2.6.2 No container parsing in the core

A direct consequence of no_std is that the kernel cannot parse PDF, XML, ZIP, or JSON — those require heavyweight std-linked libraries (lopdf, quick-xml, zip/flate2). Therefore all container/document parsing happens host-side and feeds the kernel model-free byte structures via additive VerificationRequest fields. PAdES signature dictionaries and /DSS+/VRI material are extracted by pverify-cli/src/pdf.rs (native, lopdf) and the byte-identical web/pverify-wasm/src/lib.rs (browser, lopdf); XAdES by pverify-xades; ASiC by pverify-asic; JAdES by pverify-jades. The kernel only consults the field matching the format it sniffed.

2.6.3 The empirical guards

Principle VI says "in any crate that the core … transitively pulls in" — a statement about the dependency graph, which the project enforces empirically, not by faith:

1. Compile-to-WASM gate. cargo build --target wasm32-unknown-unknown -p pverify-core must succeed. If any transitive dependency is not wasm32-buildable (because it pulls ring/getrandom/native FFI), this fails.
2. scripts/cargo-tree-gate.sh. This script runs cargo tree -e normal --no-default-features -p pverify-core and fails the build (exit 1, line 117) if any host-only crate appears in the core's production graph: pverify-eutl (L50), pverify-aatl/lopdf (L76), pverify-asic/zip/flate2/miniz_oxide, pverify-jades, pverify-anchor-inventory, pverify-test-helpers, xtask. The PASS message (L120) enumerates exactly what it has confirmed absent.

The cryptography constraint is realised by dependency selection: the kernel's crypto deps are RustCrypto-only (der, x509-cert, rsa, p256, p384, ed25519-dalek, ml-dsa, sha1/sha2, spki, pkcs1, x509-ocsp), all verify-only — there is no signing or keygen surface in the production graph. The web/pverify-wasm crate is intentionally detached from the root workspace (an empty [workspace] table in its Cargo.toml, with the rationale recorded at lines 3–9): this keeps wasm-bindgen's generated unsafe out of the root unsafe_code = "forbid" lint surface and keeps the wasm graph out of the released cargo test --workspace / cargo audit surface. See Chapter 3 for the full topology and the WASM host.

2.6.4 CLI↔︎WASM parity

The pay-off of "a single core" (§V) is CLI↔︎WASM parity: the native CLI and the browser host run the identical verify_with kernel (crates/pverify-core/src/verify.rs:178) and byte-identical extractors, producing byte-identical reports for identical inputs. The Web Crypto delegation permitted by §VI's second bullet is constrained by the same byte-identity rule: any SubtleCrypto acceleration "MUST remain byte-identical to the native path under Principle II." Parity is pinned by tests over the extractor output shapes; this is treated as an enforced invariant (see Chapter 3).

2.7 §VII Offline-First & Offline Honesty

VII. Offline-First

The CLI MUST support an --offline mode in which verification proceeds using only material embedded in the signature (DSS / VRI dictionaries, archive timestamps) and the configured trust anchors. Network access MUST be an explicit opt-in; the default posture for verify --from-bundle is fully offline.

Offline-first has a subtle ethical corner that the project elevates to a named invariant: offline honesty. In --offline mode the tool must not fabricate a responder contact it never made. An earlier implementation, when offline and unable to reach an OCSP responder, emitted ocsp_responder_unreachable — which falsely implies a contact was attempted and failed. That was a §I/§VII violation: the honest fact is "revocation was not checked because we are offline", not "the responder is down". The correction is the IndeterminateRevocationOffline outcome → revocation_not_checked_offline sub-indication (crates/pverify-core/src/revocation/mod.rs, ~L657–667, with the ocsp_attempt: None field making the absence of a contact explicit). Offline mode opens no socket.

This dovetails with §2.3.3's embedded-material fall-through: the embedded DSS/VRI/revocationInfoArchival channels (consumed for PAdES as of branch 034) fire only when the live/CDP channel is indeterminate, which in --offline mode is always — so a fully-evidenced offline PAdES-LT/LTA can reach a definitive result from its own embedded material, while a PDF lacking that material honestly degrades to revocation_not_checked_offline. The default posture for --from-bundle is fully offline by construction (the bundle is the only material source).

2.8 Algorithm-Policy Enforcement Scope (Constitutional Surface)

The Phased Path Validation Roadmap section of the constitution contains a clause that is unusually prescriptive — the Algorithm-policy enforcement scope — because the policy table is declared a constitutional surface: changing it is an amendment, not a code edit. The general clause states:

Should a release introduce algorithm-policy enforcement (a mode in which weak-algorithm presence degrades the ETSI indication), it MUST be opt-in; the default behaviour MUST remain the v0.1 fact-reporting posture (Principle I). The exact policy table … is a constitutional surface — additions or re-classifications require a constitutional amendment.

The 1.2.0 amendment then ratified the concrete table. Three constraints bind the implementation:

1. Opt-in, default-off. The mode is enabled only by --algorithm-policy [FILE]; a default-off report is byte-identical to the pre-032 body except schema_version (§2.3.3). This preserves §I as the default posture.
2. VRT-scoped. Each object the per-object VRT engine (031) derives a reference time for — signer chain, signer signature, and each signature / archive / document timestamp — is judged against the policy effective as of that object's VRT value, not against wall-clock time. "Unacceptable on/after D" means the object passes iff its VRT date is strictly before D.
3. Degrades to INDETERMINATE, never TOTAL_FAILED. A failing or unaffirmable algorithm result yields INDETERMINATE with crypto_constraints_failure_no_poe (mirroring ETSI EN 319 102-1 CRYPTO_CONSTRAINTS_FAILURE_NO_POE) — a textbook "cannot affirm" (§2.2.2). A weak algorithm means we cannot affirm the proof; it does not prove a forgery.

The ratified default table (constitution §"Algorithm-policy enforcement scope") takes CRYPTREC 電子政府推奨暗号リスト as primary authority and NIST SP 800-57 Part 1 / SP 800-131A as secondary, version 2026-06-default, and treats an unrecognised OID or undeterminable key length as INDETERMINATE (never a silent pass):

The code constant AlgorithmPolicy::default_policy() (in crates/pverify-core/src/algorithm_policy/) "MUST byte-match specs/032-algorithm-validity/contracts/default-policy.md (test C-3)". This is the strongest form of the project's "a principle is only real if a test enforces it" stance (§2.1): the constitution and the code are bound by a byte-comparison test. See Chapter 13 (Algorithm Validity Policy) for the evaluation engine.

2.9 The Phased Path Validation Roadmap & Mandatory Disclosure

§IV's roadmap section delivers RFC 5280 §6 in stages, with a non-negotiable disclosure rule:

Every release MUST emit, in machine-readable form, the phase it implements so consumers cannot mistake an earlier phase for a complete validation.

The original v0.1 MVP shipped basic chain construction and was required to set a structural flag indicating Bridge-CA chains were not supported:

Phase 1 mandatory disclosure. v0.1 MVP outputs MUST set a structural flag indicating that Bridge-CA chains are NOT supported. Suppressing this flag is a constitutional violation, not a presentation choice. … the flag may flip to true only when v0.3 ships Bridge-CA traversal under Name Constraints and policy processing.

This is §I (Fact-Reporting) applied to the tool's own capability: pverify must not let a consumer mistake a partial validation for a complete one. The current release has reached the v0.3/v0.4+ band — Name Constraints (path/name_constraints.rs, RFC 5280 §4.2.1.10), policy processing (path/policy.rs, §6.1 valid_policy_tree), Bridge-CA traversal (path/bridge.rs), archive-time-stamp-v3 imprint recomputation (EN 319 122-1 §6.3.4), XAdES, OCSP, and the per-object VRT engine are all implemented. The historical bridge_ca_required_unsupported sub-indication is retained in the SubIndication enum (report/etsi.rs:63) purely for deserialization of stored reports — a deprecated-but-not-removed variant, consistent with the additive schema-versioning rule (§2.10).

2.10 Additive Schema Versioning

The report shape is a published contract (report-schema.json at the repository root, mirrored 1:1 from crates/pverify-core/src/report/). The closed enums — SubIndication, RevocationOutcome, ValidationObjectOrigin — and the report struct are all part of it. The versioning rule, derived from the constitution's governance SemVer and applied to the report schema specifically, is:

• MINOR (additive): adding a closed-enum value or an optional field. The body stays byte-identical for inputs that do not exercise the new value (§2.3.3). Example: appending pdf_dss/pdf_vri to ValidationObjectOrigin (report/validation_objects.rs:113,118) and bumping SCHEMA_VERSION 1.5.0→1.7.0.
• MAJOR (breaking): removing or repurposing a value or field.

A critical detail for auditors: enum declaration order is sort order. The new pdf_dss/pdf_vri variants were appended (not interleaved) so that the inventory derivation in derive_validation_objects maps origin → position without disturbing the relative ordering of pre-existing variants — preserving byte-identity of the inventory for reports that don't use the new tags. Deprecated variants (e.g. bridge_ca_required_unsupported, §2.9) are retained for stored-report deserialization but are not emitted by current code paths. SCHEMA_VERSION lives at crates/pverify-core/src/report/schema.rs:line and is currently "1.10.0"; the lineage 1.2.0 → 1.3.0 (031) → 1.4.0 (032) → 1.5.0 (033) → 1.7.0 (034) → 1.8.0 (035 OcspAttempt.request_der_hex) → 1.9.0 (035 CdpEntry structured form + aia_ocsp_uris) is one MINOR bump per additive slice.

2.11 Cross-Cutting Invariants (Reference)

The following invariants recur throughout Chapters 5–13. They are derived from, and traceable to, the principles above; this section is the canonical reference list. Each cites the principle it serves and the code that enforces it.

2.11.1 The never-mask discipline (invariant 16, expanded)

Invariant 16 deserves a closing note because it is where "cannot affirm" and "do not under-report a failure" meet. aggregate_etsi (verify.rs:2343) establishes a severity-ordered base indication (TOTAL_FAILED > INDETERMINATE > TOTAL_PASSED, first-finding-wins). Subsequent layers — signer-binding, content-type, the opt-in algorithm-validity layer, and the TSA-revocation layer — may only degrade a non-TOTAL_FAILED base; they never mask a proven TOTAL_FAILED. This is the formal guarantee that a proven message-digest mismatch or ESS cert-substitution defence cannot be silently downgraded to INDETERMINATE by a later layer's indeterminacy. The two halves of §I are thereby simultaneously honoured: pverify never fabricates a failure (the "cannot affirm" side, invariant 1), and it never hides a real one (the never-mask side, invariant 16).

2.12 Out of Scope (until v1.0) and Governance Bounds

The constitution closes with an explicit Out-of-Scope list; bringing any item in is, by the versioning policy, a MAJOR amendment:

• Signature generation. pverify is verification-only …
• JPKI (My Number Card) signature verification. Tracked for v2.0+ …
• Legal-validity adjudication. Excluded by Principle I.
• End-user GUI. CLI, library, and HTTP API only …
• Qualified Trust Service Provider (QTSP) accreditation. ETSI alignment is claimed; accreditation is not pursued.

Two of these are structural, not merely policy: verification-only means there is no signing/keygen surface in the production dependency graph (§2.6.3), and legal-validity adjudication being excluded "by Principle I" is the same boundary described in §2.2.3.

Governance binds the development process to the constitution. Every /speckit-plan "MUST run a Constitution Check against the principles above"; documented violations must be enumerated with explicit justification in the plan's Complexity Tracking section; and "Pull requests touching pverify-core, the Workers build, or trust-anchor handling MUST cite which principles were verified." The constitution sets the bounds; per-feature operational detail lives in each specs/<feature>/plan.md, and the (non-normative) historical rationale lives in docs/vision-statement.md. The current constitution version is 1.2.0, ratified 2026-06-10, last amended 2026-06-22.

The remaining chapters operate strictly within these bounds: Chapter 3 details the crate topology, data flow, CLI modes, and WASM host that realise §II/§III/§V/§VI/§VII; and Chapters 5–9 detail the RFC 5280 / RFC 5652 / CMS / AdES verification and path validation that §IV pins.

3. System Architecture

This chapter describes the structural organisation of pverify: the crate topology and its dependency discipline, the load-bearing boundary between the I/O-free verification kernel and its hosts, the two concrete execution models (native CLI and in-browser WebAssembly), the internal module layout of the verification kernel pverify-core, and the end-to-end path a VerificationRequest follows from raw input bytes to a closed-schema JSON fact report. Every claim below is grounded in the source tree; file and function references are given so a reviewer can audit the assertion directly.

Where this chapter touches on the meaning of a verdict or sub-indication it defers to the chapters that own that subject: ETSI indication aggregation (Chapter 5 §5.7 and the Result Model chapter), per-format verification semantics (Chapters on CAdES, PAdES, XAdES, JAdES, ASiC), RFC 5280 path validation (the path-validation chapter), revocation (the revocation chapter), and the report schema and versioning (the report-schema chapter). Cross-references use the term "see the … chapter" because chapter numbering beyond this file is assembled separately.

3.1 Architectural intent and the central boundary

pverify verifies advanced electronic signatures (AdES) against the Japanese GPKI/JNSA profile and the European eIDAS/ETSI corpus, and emits a fact report rather than a business-level "valid / invalid" verdict. The single non-negotiable architectural boundary that organises the entire system is the separation between:

• a verification kernel — pverify-core — that is no_std + alloc, forbids unsafe, performs zero I/O, and must compile and run on wasm32-unknown-unknown; and
• a constellation of host crates that perform every container/document parse, every network fetch and every filesystem access, then feed the kernel pure, model-free byte structures.

pverify-core/src/lib.rs makes this concrete in its first lines:

#![no_std]
#![forbid(unsafe_code)]
#![deny(missing_debug_implementations)]
extern crate alloc;

(crates/pverify-core/src/lib.rs:11-15).

The kernel performs all cryptography, RFC 5280 §6 path validation, revocation evaluation, RFC 3161/5816 timestamp verification, per-object Validation Reference Time (VRT) derivation, opt-in algorithm-policy evaluation, and ETSI EN 319 102-1 indication aggregation. It cannot, however, do three things for itself, because they require access to the outside world: read the verification clock, fetch or look up revocation material, and enumerate the trust-anchor set. These three concerns — and only these — are abstracted behind capability traits in crates/pverify-core/src/traits.rs: Clock, RevocationFetcher, and TrustAnchorStore. The kernel holds &dyn TrustAnchorStore and &dyn RevocationFetcher references and calls through them; it never opens a socket, reads a file, or calls SystemTime::now().

This boundary is not aspirational. It is enforced empirically by scripts/cargo-tree-gate.sh (described in §3.2.2) and by a cargo build --target wasm32-unknown-unknown -p pverify-core step in the gate battery. The constitutional principles behind it are §V (Library-First: no document parsing in the core), §VI (WASM-clean core, NON-NEGOTIABLE), and §I (Fact-Reporting). See the constitution at .specify/memory/constitution.md.

3.1.1 Why the boundary exists

Three properties fall out of the boundary, each of which the government customer can independently verify:

1. Determinism / reproducibility (§II). Because the kernel reads no clock and no network, a given tuple of (input bytes, trust anchors, verification time, revocation material) produces a byte-identical report regardless of when or where it runs. The verification time is captured once by the host (the CLI reads SystemTime::now() once at startup unless --at is supplied) and threaded in through VerificationRequest.

2. Auditable cryptography surface (§VI). All cryptography is RustCrypto; there is no ring, aws-lc-rs, OpenSSL FFI, or default-rustls anywhere in the kernel or WASM graph. The cryptographic primitives used for verification are RSA PKCS#1 v1.5, RSA-PSS, ECDSA P-256/P-384, Ed25519, and ML-DSA, dispatched by OID and SubjectPublicKeyInfo in crate::crypto::verify_with_alg (crates/pverify-core/src/crypto.rs). The production crypto surface is verify-only — there is no signing or key-generation path in production dependencies.

3. Identical native and browser behaviour. Because the kernel is the single source of verification truth and is WASM-buildable, the native CLI and the in-browser demo run the same verify_with function over the same extracted structures, yielding byte-identical reports for identical inputs (the "CLI↔︎WASM parity" invariant, §3.5).

3.1.2 "Cannot affirm" discipline

The whole system is governed by a "cannot affirm" rule from Constitution §I: where pverify cannot establish a fact, it degrades to INDETERMINATE with a precise closed-enum sub-indication rather than fabricating a TOTAL_FAILED or a TOTAL_PASSED. Concrete examples that the architecture surfaces honestly rather than guessing at:

• offline run with no cached revocation → IndeterminateRevocationOffline / revocation_not_checked_offline (never a fabricated responder contact — Constitution §VII offline honesty);
• unsupported signature algorithm OID → INDETERMINATE rather than a failure;
• multi-signer CMS → INDETERMINATE / cms_multi_signer_unsupported (crates/pverify-core/src/verify.rs:496), never a verdict on a silently truncated signer set;
• revoked TSA certificate → revoked_no_poe (INDETERMINATE), not a forgery claim.

The sub-indication value space is a single closed Rust enum (crates/pverify-core/src/report/etsi.rs, SubIndication) mirrored 1:1 into the root report-schema.json. The report shape version is SCHEMA_VERSION = "1.10.0" (crates/pverify-core/src/report/schema.rs:line).

3.2 Crate topology

The root workspace (Cargo.toml) declares eleven members:

A twelfth crate, web/pverify-wasm, is intentionally detached from the root workspace: its Cargo.toml carries an empty [workspace] table so that wasm-bindgen's generated unsafe code and the wasm dependency graph stay out of the root unsafe_code = "forbid" lint surface and out of the released cargo test --workspace / cargo audit surface. It is the browser host.

3.2.1 The two graph classes

The crates split into two graph classes with a strict, gate-asserted dependency direction of host → WASM-clean → core.

WASM-clean graph (must compile to wasm32-unknown-unknown, RustCrypto only, no ring/getrandom/openssl):

• pverify-core — the kernel. Its dependencies are RustCrypto format and primitive crates (der, x509-cert, rsa, p256, p384, ed25519-dalek, ml-dsa, sha1, sha2, spki, pkcs1, x509-ocsp) plus time, serde, serde_json, and hex. It depends on nothing inside the workspace.
• pverify-xades, pverify-asic, pverify-jades — host extraction crates that depend on pverify-core (for the boundary types the core owns, e.g. XadesComponents, AsicSignature, JadesComponents) but are themselves required to remain wasm32-buildable. They contain no cryptography — only parse, canonicalize, and byte extraction. They are forbidden from the pverify-core runtime graph by the tree gate.

Host-only graph (native std, must NOT appear in the core/WASM runtime graph):

• pverify-eutl, pverify-aatl, pverify-anchor-inventory — anchor ingestion. Each emits ordinary TrustAnchor values re-feedable through the existing --trust-anchors path; ingestion adds nothing to the kernel.
• pverify-cli — the native verifier. It is the only crate permitted native I/O: ureq for online fetch under cfg(not(wasm32)), lopdf for PDF parse, and std::fs.
• web/pverify-wasm — the browser host: depends on core + xades + asic + jades + lopdf (in-browser PDF parse) + wasm-bindgen.

The dashed arrow CLI -. dev-dep .-> TESTH is a dev-dependency only; it is asserted absent from the production cargo tree -e normal graph.

3.2.2 The tree gate

scripts/cargo-tree-gate.sh is the load-bearing empirical guard for the boundary. It runs cargo tree -e normal --no-default-features -p pverify-core and fails the build if any host-only crate or its tell-tale transitive dependencies appear in the core's normal-dependency graph — specifically pverify-eutl, pverify-asic/zip/flate2/miniz_oxide, pverify-aatl/lopdf, pverify-jades, pverify-test-helpers, or xtask. This converts the architectural rule "the kernel never links a PDF/XML/ZIP parser" into a mechanically checked invariant rather than a code-review convention. The complementary cargo build --target wasm32-unknown-unknown -p pverify-core step proves the kernel actually builds for the browser target.

3.3 The host vs. WASM-clean-core boundary in detail

The kernel cannot parse PDF, XML, ZIP, or JSON containers — those parsers pull std and large dependency graphs incompatible with a no_std WASM kernel. Instead, the host pre-parses each container format and threads the extracted, model-free byte structures into additive fields of VerificationRequest (crates/pverify-core/src/verify.rs:69). The kernel only consults the field matching the sniffed format. The relevant request fields and their producers:

The additivity is a deliberate reproducibility contract (Constitution §II): a non-PDF input carries an empty pdf_validation_data (its Default), an out-of-scope JSON carries an empty jades_components, and so on. Every pre-existing caller fills the newer fields with Default::default() / Vec::new(), so adding a channel leaves prior reports byte-identical except the schema_version string (FR-008 byte-identity). For example, a PDF with no /DSS differs from a pre-034 report only in schema_version.

This is the structural expression of Constitution §V "Library-First": the container parse lives entirely in host crates (pverify-cli/src/pdf.rs, pverify-xades, pverify-asic, pverify-jades, pverify-aatl), and the kernel never links lopdf, zip, flate2, or the bergshamra-c14n canonicaliser.

3.3.1 The trait-mediated capability boundary

crates/pverify-core/src/traits.rs defines the three host capabilities and a pair of minimal value types:

• Clock — fn now(&self) -> OffsetDateTime. The kernel does not in practice call this on the hot path (the verification time is captured into VerificationRequest.verification_time by the host); the trait exists so a host can supply time deterministically. Tests use a fixed-time fake.
• RevocationFetcher — fn fetch_crl(&self, url: &str) and fn fetch_ocsp(&self, uri: &str, request_bytes: &[u8]). Implementations honour the caller's mode: online (ureq GET/POST), offline (always Err(Error::NotAvailableOffline)), or from-bundle (read from <bundle>/crls/ or <bundle>/ocsp/). fetch_ocsp carries a default impl returning NotAvailableOffline so pre-OCSP implementors degrade honestly. Crucially, the kernel builds the DER OCSPRequest itself (crate::revocation::ocsp::build_ocsp_request_bytes) and the trait returns raw BasicOCSPResponse bytes — parsing stays in the kernel; the trait is stable across x509-ocsp versions.
• TrustAnchorStore — fn anchors(&self) -> &[TrustAnchor]. Returns the anchors in host-supplied order; the store is "intentionally inert" and does not dedup, sort, or filter. The host computes each TrustAnchor's SHA-256 fingerprint, raw subject_dn bytes, and the validity_window_covers_request_time flag at load time (FR-025).

The crate also ships skeleton implementations OfflineRevocationFetcher (the canonical "always denies" fetcher) and InMemoryTrustAnchorStore, which the CLI and WASM hosts wrap or populate.

3.4 Native CLI execution model

The native verifier is pverify-cli. Its command surface (crates/pverify-cli/src/main.rs, enum Command) covers four sub-commands:

• verify — verify a CAdES / PAdES / XAdES / JAdES / ASiC signature;
• ingest-trust-list — ingest an EU Trusted List (ETSI TS 119 612) into re-feedable PEM anchors (verification-only, never adjudicates "qualified");
• ingest-aatl — ingest the Adobe Approved Trust List against a pinned Adobe Root CA G2;
• trust-anchors — read-only inspection of every anchor distribution channel.

The verify path (Command::Verify, main.rs:346) operates as follows:

1. Read inputs and capture time. Read the signature file and optional detached content from disk; capture the verification time once at startup from the host Clock (src/clock.rs) or from --at. --at always wins (§II reproducibility).
2. Select a mode. One of --trust-anchors <DIR> with online fetch, --offline, --from-bundle <DIR>, or LDAP-CRL — implemented in src/modes/{online,offline,from_bundle,ldap}.rs. The CLI's Mode enum {Online, Offline, FromBundle} maps to the kernel's revocation VerificationMode; --offline opens no socket (offline honesty).
3. Load trust anchors. src/trust.rs computes each anchor's SHA-256 fingerprint, raw subject-DN bytes, and validity_window_covers_request_time flag — the host's FR-025 responsibility — and builds an InMemoryTrustAnchorStore.
4. Host-parse the container. If the input is a PDF, src/pdf.rs::extract_signatures runs lopdf to emit PdfSignatureDescriptors (/ByteRange, /Contents, /SubFilter, revision_end from a %%EOF scan, and /Sig vs /DocTimeStamp tag), and extract_validation_data parses the document-level /DSS pools and /VRI (§3.8). XAdES/ASiC/JAdES inputs are parsed by their extraction crates.
5. Assemble and call. Fill a VerificationRequest and call verify_with(&request, &store, &fetcher).
6. Render. src/render.rs serialises the returned Report to JSON.

The CLI is the canonical verifier. Its bounded-I/O guards (bounded_io.rs, net_guard.rs) and host-side responsibilities (anchor loading, PDF parse) are exactly the host concerns the kernel deliberately excludes.

3.5 Browser / WebAssembly execution model

The browser host is web/pverify-wasm (web/pverify-wasm/src/lib.rs). It exposes two #[wasm_bindgen] entry points:

• classify(bytes) — runs the real pverify-core parsers in priority order (PDF → ASiC ZIP → JAdES JSON → X.509 certificate → CRL → CMS SignedData → otherwise "content") so the drag-and-drop UI can auto-route a dropped file by what it is, not by its extension (classify_bytes, lib.rs:158).
• verify(req) — runs the full pverify_core::verify::verify_with pipeline entirely client-side and returns the pretty-printed JSON report (lib.rs:288).

verify deserialises a VerifyInput (signature bytes, optional detached content, trust-anchor DERs, extra certificates, crls/ocsp keyed by source_uri, verification_time_unix, and an optional algorithm_policy selector). It then performs byte-identical host work to the native CLI:

• extract_pdf_signatures (a port of pverify-cli/src/pdf.rs::extract_signatures),
• extract_pdf_validation_data (a port of pverify-cli/src/pdf.rs::extract_validation_data — same /DSS+/VRI union, dedup, MAX_DSS_ENTRIES_PER_POOL/MAX_DSS_STREAM_BYTES bounds, and uppercase-hex SHA-1 VRI keying, lib.rs:519),
• pverify_xades::extract, pverify_asic::extract, pverify_jades::extract,

constructs the same VerificationRequest, and calls the same verify_with. Anchors are built by anchor_from_der, which "computes the fingerprint and validity window the same way pverify-cli/src/trust.rs does" (lib.rs:115). The browser-side DemoFetcher is an in-memory source_uri → bytes lookup mirroring the CLI's bundle fetcher; a miss returns NotAvailableOffline, which the pipeline maps to IndeterminateNoCrl / IndeterminateOcspUnreachable.

CLI↔︎WASM parity is therefore an enforced invariant, not a coincidence: both hosts extract identical structures and run the identical kernel, so they produce byte-identical reports for identical inputs. Parity is pinned by tests over the extractors (e.g. crates/pverify-cli/tests/extractor_parity.rs, and the WASM-side parity tests at web/pverify-wasm/src/lib.rs:729 ff.).

The page layout (web/site/index.html) puts the result section first, directly under the header, with the drop/verify tool below it — so a completed verdict appears at the top of the viewport rather than below the tall format/algorithm reference section, where it could land off-screen and be missed. renderReport (app.js) un-hides #result and calls scrollIntoView so that even a re-verification triggered after the reader has scrolled down (e.g. changing the verification time) brings the fresh verdict back into view. Verification is automatic on drop; the "再検証する" button and the status line beneath it are the manual re-run path.

A third, diagnostic, harness web/verify-cli.mjs drives the same built site/pkg/ WASM module from Node, so a fixture can be verified through the WASM pipeline without a browser. It is explicitly not the product (it has no CRL proxy, so CDP-only chains report INDETERMINATE where the browser, which fetches CRLs through a proxy, reaches TOTAL_PASSED); it exists purely for parity diagnostics, and its header says so (web/verify-cli.mjs:9-13). Its process exit code mirrors the ETSI indication of signatures[0] (0=TOTAL_PASSED, 1=TOTAL_FAILED, 2=INDETERMINATE/no signature).

3.6 Module layout of pverify-core

crates/pverify-core/src/lib.rs declares the kernel's public modules. Their responsibilities:

Note the deliberate division within report: schema.rs pins the SCHEMA_VERSION ("1.10.0") and the disclosure constants surfaced on every report header — PATH_VALIDATION_PHASE = "v0.6-bridge-acceptance", BRIDGE_CA_SUPPORTED = true, DN_MATCH_METHOD = "rfc4518-minimal-v0.1" (crates/pverify-core/src/report/schema.rs, crates/pverify-core/src/report/mod.rs:95-107).

3.7 From VerificationRequest to Report: end-to-end flow

The single orchestrator is verify_with (crates/pverify-core/src/verify.rs:178). It takes (&VerificationRequest, &dyn TrustAnchorStore, &dyn RevocationFetcher) and returns a Report. The flow has six stages.

3.7.1 Stage 0/1 — host parse and request assembly

Covered in §3.4/§3.5: the host parses the container, captures the time, loads anchors, and fills a VerificationRequest. Every format channel is an additive Vec / Default.

3.7.2 Stage 2 — format dispatch

verify_with first initialises a header via Report::new_header. It then dispatches in this precedence order (verify.rs:189-327):

1. ASiC takes precedence. If asic_signatures is non-empty, the input is an ASiC container regardless of the raw-byte sniff (the container bytes start with the ZIP magic PK\x03\x04, which would otherwise fall through to CAdES). One SignatureEntry is emitted per inner signature via crate::asic::verify_asic_signature.
2. Bare ZIP, no ASiC content. If signature_bytes starts with PK\x03\x04 but the host produced no ASiC signatures, the input is a ZIP that is not a recognisable ASiC container; the kernel emits asic_unsupported_container (INDETERMINATE) rather than letting it misclassify as CAdES (verify.rs:227).
3. Content sniff. Otherwise detect_format (verify.rs:359) inspects the leading bytes: %PDF- → PAdES; a UTF-8-BOM-tolerant <?xml or bare <+NameStartChar → XAdES; a BOM-tolerant leading { → JAdES; otherwise CAdES. JSON and XML are mutually exclusive on the first non-whitespace byte ({ vs <), so the sniffs cannot collide.

Each arm emits one SignatureEntry per signature. PAdES routes to crate::pades::verify_pdf; XAdES maps each xades_components entry through crate::xades::verify_xades (or xades_unsupported if the host extracted nothing); JAdES maps each jades_components entry through crate::jades::verify_jades (or the JAdES refusal entry); CAdES routes to verify_cades.

3.7.3 Stage 3 — per-signature verification (CAdES reference)

verify_cades (verify.rs:475) is the reference pipeline; the other formats reuse its phases through shared helpers. In order:

1. Parse the CMS SignedData with the lenient walker (SignedDataParser::parse).
2. Refuse multi-signer CMS honestly: if signer_info_count > 1, return INDETERMINATE / cms_multi_signer_unsupported (verify.rs:496) rather than reporting only the first SignerInfo — a fact-reporting requirement (§I), since the pre-029 parser used to silently truncate the signer set.
3. Reconstitute the embedded certificate DER blobs and append any host-supplied extra_certificates (consumed for chain construction but never selected as the signer).
4. Select the signer by SignerInfo.sid (issuer+serial or SKI) via select_signer_by_sid (verify.rs:1096); a malformed/not-found sid falls back to a heuristic index only as a report scaffold — the verdict is gated on the SignerIdentifierCheck outcome before any signature/digest gate.
5. Validate the path (RFC 5280 §6 structural checks + chain construction, path/mod.rs), then verify each chain step's certificate signature with RustCrypto via wire_chain_step_signatures (verify.rs:1944).
6. Project the unsigned attributes (T/LT/LTA: signature-time-stamps, archive-time-stamp-v3, certificate-values, revocation-values CRL/OCSP) and compute the format-promotion ladder (verify.rs:1034-1042): archive timestamps present → CAdESLta; any LT payload → CAdESLt; signature time-stamps present → CAdEST; otherwise CAdESBes.
7. Apply revocation to the signer chain (apply_revocations).
8. Verify the signedAttrs digest and signature and the content digest; check the ESS signing-certificate binding (RFC 5035) and the content-type binding.

3.7.4 Stage 4 — per-object VRT

crate::vrt::derive_vrt (verify.rs:757) builds the recursive-outer-covering graph from the timestamp tokens and returns a Vrt block assigning each object — the signer chain, the signer signature, each signature_timestamp[i], and each archive_timestamp[i] — its own Validation Reference Time. The signer chain and each TSA chain are then re-validated at their own VRT, and TSA chains are revocation-checked at each object's VRT via apply_tsa_chain_revocation_for_token (verify.rs:1552). The covering graph reads only request_at as its time source (never Clock::now) and is never re-derived or mutated by downstream revocation/algorithm layers (FR-005a). See the VRT chapter.

3.7.5 Stage 5 — indication aggregation

aggregate_etsi (verify.rs:2343) folds the structural / signature / digest / revocation findings into a base EtsiIndication with severity ordering TOTAL_FAILED > INDETERMINATE > TOTAL_PASSED and a first-finding-wins rule within a severity. Layered passes then run, each able only to degrade a non-TOTAL_FAILED base and never to mask a proven TOTAL_FAILED: signer-binding, content-type, opt-in algorithm-validity, and TSA-revocation. The precedence ladder is explicit in the source — e.g. archive_timestamp_imprint_mismatch ranks immediately after chain_constraints_failure (verify.rs:2357-2391). See the ETSI-aggregation chapter.

3.7.6 Stage 6 — report serialisation and the validation-object inventory

After populating report.signatures, verify_with aggregates per-step weak-algorithm flags into the header (aggregate_for_header) and then derives the consolidated material inventory: report.validation_objects = crate::report::derive_validation_objects(&report) (verify.rs:341). derive_validation_objects (crates/pverify-core/src/report/validation_objects.rs:191) is a pure &Report read — no network, no new cryptography (every digest is already a field). It enumerates the certificates, CRLs, OCSP responses, and content objects actually consulted and tags each with a ValidationObjectOrigin provenance value. The host then serialises the Report to JSON (CLI src/render.rs; WASM serde_json::to_string_pretty). Because both hosts run the identical kernel, the outputs are byte-identical for identical inputs.

3.8 The PAdES /DSS+/VRI specialisation (branch 034)

PAdES is the one format whose Stage 3 differs materially because of document-level validation material, so it is worth describing here as the clearest illustration of how an additive feature threads through the architecture without touching verdict logic.

Before branch 034, pades::verify_pdf fed the revocation pipeline empty embedded slices, so a fully-evidenced offline PAdES-LT/LTA stalled at INDETERMINATE / revocation_not_checked_offline. Branch 034 added a host-side extraction of the catalog-level /DSS dictionary (/Certs, /CRLs, /OCSPs), unioned across all incremental-update revisions and deduped by DER, plus the /VRI sub-dictionary keyed by the uppercase-hex SHA-1 of each signature's /Contents. This is delivered to the kernel as a new additive VerificationRequest.pdf_validation_data of type PdfValidationData (crates/pverify-core/src/pades/mod.rs:80), populated identically by the native CLI (pverify-cli/src/pdf.rs::extract_validation_data) and the browser host (web/pverify-wasm/src/lib.rs::extract_pdf_validation_data).

Inside pades::verify_pdf the kernel resolves, per signature object, the preferred validation material via resolve_material (crates/pverify-core/src/pades/mod.rs:148): a /VRI entry keyed by the object's /Contents SHA-1 is preferred (provenance PdfVri); otherwise the document-level /DSS pools are the fallback (provenance PdfDss). The resolved CRL/OCSP DER is fed into the existing apply_revocations (signer chain) and apply_tsa_chain_revocation_for_token (each timestamp) calls that previously received &[],&[], at each object's own VRT. Adobe revocationInfoArchival (OID 1.2.840.113583.1.1.8) is projected from the CMS and merged as signature_embedded material.

Several architectural properties are preserved by design:

• No new verdict logic. DSS material yields the existing RevocationOutcome vocabulary — a revoked signer is the existing TOTAL_FAILED, a revoked TSA is 033's existing revoked_no_poe (INDETERMINATE). No new outcome and no new sub-indication were added.
• /Certs are never anchors. DSS /Certs are intermediate/leaf path-building candidates only, never promoted to trust anchors (PdfValidationData.dss_certs doc-comment, pades/mod.rs:81-83).
• Additive-only fall-through. The DSS-sourced CRL/OCSP rides the existing embedded-material channels that fire only when the live/CDP channel is indeterminate, so online live-fetch successes stay byte-identical.
• Additivity by collision-safe key. SHA-1 here is only a /VRI dictionary key, never a security primitive; because the material is additive evidence (CRLs matched by issuer+serial, OCSP by certID), a collision could only mis-route additive evidence and can never fabricate a "good" outcome (sha1_uppercase_hex doc-comment, pades/mod.rs:183-188).
• Provenance only. The single wire change is two new ValidationObjectOrigin variants, pdf_dss and pdf_vri, appended after supplied_input (crates/pverify-core/src/report/validation_objects.rs:113-118), with the 016 derivation mapping the per-CRL / per-OCSP source tags (PdfRevocationSource::{PdfDss,PdfVri}) onto them (validation_objects.rs:308-336). Appending closed-enum variants is an additive MINOR schema bump, which is what took the schema from 1.5.0 to 1.7.0.

3.9 AdES level vocabulary supported by the architecture

The dispatch and per-format verifiers are honest about scope. The table below states what the tool verifies versus what it flags as unsupported; the per-format chapters carry the details.

The format-promotion ladder for CAdES is in verify.rs:1034-1042; the JAdES and XAdES refusal entries are emitted by crate::jades::jades_unsupported_entry and xades_unsupported_entry respectively. Where a level or variant is out of scope, the architecture degrades to INDETERMINATE with a precise sub-indication (§3.1.2), never a fabricated failure.

3.10 Cross-cutting invariants the architecture guarantees

The following invariants are properties of the architecture itself rather than of any one module, and each is mechanically or test-enforced:

1. WASM-clean core (§VI, NON-NEGOTIABLE). pverify-core is no_std + alloc, forbids unsafe, builds for wasm32-unknown-unknown, and is RustCrypto-only — enforced by the tree gate plus a wasm build step.
2. No container parse in core (§V). All PDF/XML/ZIP/JSON parsing lives in host crates; the kernel never links lopdf/zip/flate2/bergshamra — gate-asserted.
3. I/O-free, trait-mediated boundary. Clock, revocation, and anchors are the only host concerns the kernel reaches for, and only through traits.rs. derive_vrt and derive_validation_objects are pure compute.
4. Additive schema versioning. SubIndication, RevocationOutcome, and ValidationObjectOrigin are closed enums mirrored 1:1 in report-schema.json; adding a value or optional field is MINOR, removing or repurposing is MAJOR. Deprecated variants (e.g. bridge_ca_required_unsupported) are retained for stored-report deserialization but not emitted.
5. Verdict byte-identity on additive/off features (§II). An additive feature leaves the report body byte-identical except schema_version when its inputs are absent or it is off (e.g. a no-DSS PDF, algorithm-policy off, empty embedded-revocation channels).
6. Offline honesty (§VII / §I). --offline opens no socket and never fabricates a responder contact; the honest IndeterminateRevocationOffline / revocation_not_checked_offline outcome replaced the prior dishonest ocsp_responder_unreachable emission.
7. CLI↔︎WASM parity. Both hosts run byte-identical extractors and the identical verify_with; parity tests pin the extractor output shapes.
8. Cannot affirm (§I, NON-NEGOTIABLE). Unestablished facts degrade to INDETERMINATE with a closed-enum sub-indication.
9. Indication precedence / never-mask. aggregate_etsi sets a severity-ordered base; later layers only degrade a non-TOTAL_FAILED base.
10. Per-object VRT separation. Each object is judged at its own derived VRT via a pure recursive-outer-covering engine reading only request_at; the covering graph is never re-derived or mutated downstream.
11. Host ingestion produces ordinary anchors. pverify-eutl/aatl/ anchor-inventory emit ordinary TrustAnchor values re-feedable through --trust-anchors; ingestion performs no network I/O at parse time.
12. Reproducible time capture (§II). The CLI captures the verification time once at startup unless --at is supplied, and --at always wins.

These invariants, taken together, are what make the report an auditable fact: the same inputs always produce the same report, the cryptographic and parsing surfaces are bounded and inspectable, and the tool never claims more than it can prove.

4. Input Classification & Format Dispatch

This chapter documents how pverify turns an opaque byte slice into a routed verification. It covers the two-layer classification pipeline (a host-side sniff that decides which structural parser to run, and a kernel-side sniff that decides which verifier arm to enter), the precedence rules between the two, the handling of detached versus attached content, ASiC-S/ASiC-E container detection, and the dispatch into each per-format verifier. Every behavioural claim below is grounded in the source; the load-bearing classifier is pverify_core::verify::detect_format (crates/pverify-core/src/verify.rs:359), with its host-side mirror split across crates/pverify-cli/src/main.rs and web/pverify-wasm/src/lib.rs.

The design principle throughout is honest, deterministic dispatch: every input is assigned to exactly one format, the assignment is made from a small prefix of the bytes (so it is cheap and reproducible), and an input that matches a family but cannot be verified at the tool's supported level degrades to INDETERMINATE with a precise closed-enum sub-indication rather than being silently misrouted to another arm or fabricated into a pass/fail (Constitution §I, "cannot affirm"; see Chapter 2 for the constitutional framing and Chapter 3 for the architecture boundary this chapter operates within).

4.1 Two-layer classification

pverify cannot parse PDF, XML, ZIP or JSON inside the verification kernel: the kernel is #![no_std] and is forbidden from linking container/document parsers (Constitution §V/§VI; see Chapter 3 §3.x for the crate topology and the scripts/cargo-tree-gate.sh guard that enforces it). Classification therefore happens twice, by design, and the two layers must agree:

1. Host-side sniff (structural-parse selection). The native CLI and the browser WASM host inspect the leading bytes of the input to decide which structural extractor to run — lopdf for PDF, pverify-xades for XML, pverify-asic for ZIP, pverify-jades for JSON — and to enforce the CLI content-source rules (§4.4). The host fills the format-specific channels of the VerificationRequest (pdf_signature_dicts, pdf_validation_data, xades_components, jades_components, asic_signatures) with the extracted model-free byte structures.

2. Kernel-side sniff (verifier-arm dispatch). verify_with (crates/pverify-core/src/verify.rs:178) re-classifies the same request.signature_bytes and routes to exactly one verifier arm. The kernel only ever consults the request channel that matches its own sniff result, so a non-PDF input carrying an (always-empty) pdf_validation_data is indistinguishable from one that never had the field.

Both layers read only the leading bytes — no whole-file scan is required to classify — and they use byte-identical predicates. The CLI's looks_like_xml (crates/pverify-cli/src/main.rs:399) and looks_like_json (main.rs:420) are line-for-line equivalents of the kernel's looks_like_xml/looks_like_json (verify.rs:392/375), and the WASM host's copies (web/pverify-wasm/src/lib.rs:419/439) carry explicit "mirrors pverify_core::verify" comments. This deliberate triplication is the CLI↔︎WASM parity invariant (Chapter 3): the native and browser hosts must extract identical structures and the kernel must reach the identical arm, so a given input produces a byte-identical report on either host.

The asymmetry between the host order (ZIP → PDF → XML → JSON → CAdES) and the kernel order (ASiC channel → ZIP → detect_format) is intentional and is explained in §4.5: the kernel must dispatch ASiC before detect_format because an ASiC container's bytes start with the ZIP magic, which the detect_format sniff does not recognise and would otherwise let fall through to the CAdES arm.

4.2 The kernel sniff: detect_format

The kernel's classifier is a four-way decision over the leading bytes (crates/pverify-core/src/verify.rs:359):

fn detect_format(bytes: &[u8]) -> DetectedFormat {
    if bytes.starts_with(b"%PDF-") {
        return DetectedFormat::Pdf;
    }
    if looks_like_xml(bytes) {
        return DetectedFormat::Xades;
    }
    if looks_like_json(bytes) {
        return DetectedFormat::Jades;
    }
    DetectedFormat::Cades
}

DetectedFormat is a closed enum {Pdf, Xades, Jades, Cades} (verify.rs:347). The ordering is significant and is documented in the source: PDF is tested first because %PDF- is an unambiguous binary marker; XML and JSON are mutually exclusive on the first non-whitespace byte (< versus {), so their relative order cannot cause a collision; and CAdES is the residual default — anything that is not recognised as PDF/XML/JSON is treated as a DER-encoded CMS SignedData and handed to verify_cades. Note that ZIP is not a branch of detect_format: a ZIP input is intercepted earlier in verify_with (§4.5) and never reaches this function. The sniff makes no attempt to validate the rest of the structure — a malformed CMS is still routed to CAdES, where it becomes a cades_parse_failed entry rather than a misclassification.

4.2.1 The marker predicates

Two precision points worth recording for an auditor:

• JSON sniff is object-rooted only. looks_like_json returns true only for a leading {, never [. This is correct for JAdES: JWS JSON Serialization (RFC 7515 §7.2) is always a JSON object, never a bare array, so a leading [ would be a non-JAdES JSON document and is deliberately routed to the CAdES residual rather than to the JAdES arm. The behaviour is asserted in the WASM tests (web/pverify-wasm/src/lib.rs:781, !looks_like_json(b"[]")).
• The XML NameStartChar test is an ASCII subset. looks_like_xml accepts a bare < followed by an ASCII letter, _, or :. The source comment notes this "ASCII subset is sufficient for all GPKI-shaped fixtures" (verify.rs:402): a ds:Signature or xades:…-rooted document, or any XML with an <?xml prolog, classifies correctly; a hypothetical XML whose root element name begins with a non-ASCII Unicode NameStartChar and which omits the prolog and BOM would not be sniffed as XML. No such input arises in the GPKI/eIDAS corpus, and the failure mode is benign (it would fall through to CAdES and produce a cades_parse_failed fact, not a false pass).

The UTF-8 BOM (EF BB BF) is stripped before both the XML and JSON tests (verify.rs:376, verify.rs:394), so a BOM-prefixed XAdES or JAdES document is classified on its true first content byte.

4.3 Per-format dispatch in verify_with

After the ASiC interception (§4.5), verify_with matches on the detect_format result and builds a Vec<SignatureEntry> — one entry per signature in the document (crates/pverify-core/src/verify.rs:240). The contract that every arm honours is that the consumer always receives a definite fact: even an empty host extraction yields exactly one explanatory entry, never an empty array.

4.3.1 PAdES arm (DetectedFormat::Pdf)

PDF inputs route to crate::pades::verify_pdf (verify.rs:241), threaded with the host-extracted pdf_signature_dicts and pdf_validation_data, the trust store, the fetcher, the verification time, the real VerificationMode (so --offline is honoured rather than fabricating an OCSP contact — the 015 fix to a §I gap, verify.rs:255), the canonical required_policies set (verify.rs:259, so --required-policy is enforced for PAdES), and the opt-in algorithm policy (verify.rs:261).

verify_pdf (crates/pverify-core/src/pades/mod.rs:242) iterates the descriptors and produces one SignatureEntry per /Sig dictionary, attaching each covering /DocTimeStamp token to the most-recent preceding signature (mod.rs:309). It supports PAdES B-B, B-T (signature-time-stamp), B-LT and B-LTA over the embedded CMS plus /DocTimeStamp (the PAdES archive-timestamp mechanism), and as of branch 034 consumes the document-level /DSS (/Certs//CRLs//OCSPs), /VRI, and Adobe revocationInfoArchival validation material (see Chapter on PAdES verification for the resolution detail). If the host extracted no signature dictionaries, verify_pdf returns a single explanatory entry rather than an empty vector: no_signature_entry (mod.rs:475) emits INDETERMINATE with sub-indication PdfByteRangeMalformed and the context string "pdf-no-signature-dict" (mod.rs:496).

PAdES is structurally always attached: the /ByteRange references bytes inside the PDF body, so every PAdES SignatureEntry carries content_source = Embedded invariantly (mod.rs:483). This is why the CLI forbids combining a PDF input with --detached-content (§4.4).

4.3.2 XAdES arm (DetectedFormat::Xades)

XML inputs route to a per-component loop (verify.rs:263). If request.xades_components is empty — the input sniffed as XML but the host extracted no ds:Signature, or the host hit an extraction error it could not categorise — the arm falls back to xades_unsupported_entry (verify.rs:272, defined at verify.rs:413), which is INDETERMINATE with sub-indication XadesUnsupported. Otherwise it calls crate::xades::verify_xades once per extracted component. pverify verifies enveloped XAdES B-B with B-T/B-LT timestamps and B-LTA ArchiveTimeStamp imprint (branch 036, SignatureFormat::XadesBLta; ETSI TS 101 903 v1.4.2 Annex A.1.5) using Exclusive XML Canonicalization via the audited bergshamra-c14n crate; detached/enveloping XAdES and non-exclusive C14N degrade to INDETERMINATE (see the XAdES chapter). The fall-back-to-refusal design means an XML document that is not a verifiable XAdES signature still produces a definite, machine-readable fact (FR-009), never a silent empty result.

4.3.3 JAdES arm (DetectedFormat::Jades)

JSON inputs route to the analogous per-component loop (verify.rs:296). An empty request.jades_components falls back to jades_unsupported_entry (verify.rs:304); otherwise each component is verified by crate::jades::verify_jades. pverify verifies JWS JSON Serialization B-B only. The JAdES extractor classifies and refuses the out-of-scope shapes explicitly rather than mis-verifying them (crates/pverify-jades/src/parse.rs:212): a sigD detached-payload reference maps to JadesUnsupportedReason::DetachedSigD (parse.rs:232), a higher baseline level (B-T+) maps to HigherLevel (parse.rs:250), and a plain JWS that carries no JAdES baseline properties maps to NotJadesBaseline (parse.rs:261). Compact serialization is likewise out of scope. Each refusal is an honest INDETERMINATE fact, consistent with the §I "cannot affirm" discipline. RFC 7797 b64:false unencoded payloads are handled by the extractor, but only when b64 also appears in crit (parse.rs:116); a b64:false without the required crit declaration is treated honestly rather than silently accepted.

4.3.4 CAdES arm (DetectedFormat::Cades, the residual default)

Everything not sniffed as PDF/XML/JSON (and not intercepted as ZIP) is handed to verify_cades (verify.rs:326, defined at verify.rs:475). This is the single-entry arm: it produces exactly one SignatureEntry. verify_cades parses the input as a CMS SignedData (RFC 5652) via SignedDataParser; a parse failure becomes a cades_parse_failed_entry (verify.rs:483) — note that a misclassified non-CMS input (e.g. arbitrary binary that is not PDF/XML/JSON) fails here cleanly rather than producing spurious output.

A critical honesty rule lives in this arm: multi-signer CMS is deliberately refused. If parsed.signer_info_count > 1, verify_cades returns cades_multi_signer_entry (verify.rs:496-497), an INDETERMINATE with sub-indication cms_multi_signer_unsupported. The source records the rationale: the pre-029 parser silently kept only the first SignerInfo, reporting a CMS with N>1 signers as though only one existed — a fact-reporting gap that hid signer-set evidence relying parties need for countersignature workflows and audit (verify.rs:487-495). Until signatures[] grows a one-entry-per- SignerInfo model, the honest answer is to refuse rather than verify a truncated signer set. CAdES is supported across BES/B-B, B-T (signature-time- stamp), B-LT and B-LTA (archive-time-stamp-v3 with ETSI EN 319 122-1 §6.3.4 imprint recomputation); see the CAdES chapter.

4.4 Detached versus attached content

CAdES is the only family that can be detached — i.e. where the signed payload (eContent) lives outside the CMS and must be supplied alongside the signature. PAdES, XAdES (enveloped), JAdES and ASiC all carry or reference their payload structurally, so the detached-content question only arises for CAdES, and it is resolved entirely at the host layer (it requires file I/O and CLI-flag introspection, which the kernel cannot perform). The logic implements the four-cell FR-027/FR-028 content-source matrix in crates/pverify-cli/src/main.rs:554-606.

The CLI first determines the family with cheap prefix checks: is_pdf (main.rs:535), is_asic (pverify_asic::is_zip, main.rs:540), looks_xml (main.rs:541), looks_json (main.rs:553). For any of these four, the content-source matrix is bypassed entirely (main.rs:554), with content_source_override = None — PAdES is structurally attached, XAdES is refused before content-source resolution, ASiC has no eContent and takes no --detached-content, and JAdES embeds its payload in the JWS structure. Only when the input is none of those four — i.e. a presumed CAdES — does the matrix run.

A hard pre-check guards the obviously-wrong combination: supplying --detached-content together with a PDF signature is an invocation error (exit 2) before any matrix logic (main.rs:507-512), because PAdES is never detached.

For a CAdES input, the CLI peeks at the CMS structure with SignedDataParser, extracting a non-empty eContent if present (main.rs:565-568), and then applies the matrix over (eContent present?, --detached-content supplied?):

The last cell is the central honesty rule of this section: pverify never silently verifies an empty payload. A detached CAdES signature with no content supplied is rejected at the CLI rather than being verified against zero bytes (main.rs:599). The conflict cell (present-but-differs) likewise refuses rather than guessing which of two contradictory payloads the caller meant.

The resolved tag is threaded into the request as content_source / content_source_redundant (Chapter 3 §request assembly). When the override is None (the PDF/XML/JSON/ASiC cases, or any CAdES the CLI could not peek), the verify pipeline applies its own structural default: CAdES prefers embedded eContent over detached_content_bytes, and refusal/PAdES entries are always Embedded (crates/pverify-core/src/verify.rs:121-131).

4.5 ASiC-S / ASiC-E detection and the ZIP precedence rule

ASiC (EN 319 162) packages CAdES or XAdES signatures inside a ZIP container, so an ASiC input begins with the ZIP local-file-header magic PK\x03\x04. Because that magic is not a branch of detect_format, a ZIP would otherwise fall through to the CAdES residual default and be misclassified. pverify prevents this with a two-stage precedence rule split across the host and the kernel.

4.5.1 Host: ZIP-first extraction

The CLI routes any ZIP input to the ASiC extractor ahead of the PDF/XML/CAdES sniff (crates/pverify-cli/src/main.rs:723). pverify_asic::is_zip is the prefix test (crates/pverify-asic/src/lib.rs:35, bytes.starts_with(b"PK\x03\x04")). On success, the extracted Vec<AsicSignature> is threaded into request.asic_signatures; on a NotAsic/extraction failure the channel is left empty (.unwrap_or_default()), so the kernel sees ZIP magic with no ASiC signatures and emits an honest asic_unsupported_container fact rather than misclassifying the input as CAdES (main.rs:716-727). The WASM host performs the byte-identical routing (web/pverify-wasm/src/lib.rs:362).

4.5.2 Kernel: ASiC channel precedence, then ZIP-magic interception

verify_with enforces the same precedence in the kernel (crates/pverify-core/src/verify.rs:189-235), in two ordered checks before detect_format is ever called:

1. asic_signatures non-empty (verify.rs:195): the host found ASiC signatures, so each is verified independently via crate::asic::verify_asic_signature — one SignatureEntry per inner signature — and verify_with returns immediately. The inner signatures are delegated to the existing detached CAdES / XAdES pipelines (the comment at verify.rs:194 makes this explicit).
2. ZIP magic with no ASiC signatures (verify.rs:227): if request.signature_bytes.starts_with(b"PK\x03\x04") but the ASiC channel is empty, the input is a ZIP that is not a recognisable ASiC container (or a hard extraction failure the host could not categorise). verify_with emits a single asic_unsupported_entry (INDETERMINATE, asic_unsupported_container) and returns, never letting it reach detect_format and be misrouted to CAdES (verify.rs:222-235).

Only after both checks fail does verify_with call detect_format (verify.rs:239). This is the structural reason the kernel's classification order (ASiC channel → ZIP magic → detect_format) differs from the host's (ZIP → PDF → XML → JSON → CAdES).

4.5.3 Profile and family detection inside the container

When pverify_asic::extract (crates/pverify-asic/src/lib.rs:50) runs, it parses the ZIP and then classifies the container with detect::detect (crates/pverify-asic/src/detect.rs:76). This is a best-effort recognition that records every packaging deviation rather than silently tolerating it (FR-001a). The detection has three outputs: the profile (ASiC-S vs ASiC-E), the primary signature family (CAdES vs XAdES), and a list of AsicDeviations.

Profile (ASiC-S vs ASiC-E). A conformant mimetype entry is authoritative: application/vnd.etsi.asic-s+zip → ASiC-S, application/vnd.etsi.asic-e+zip → ASiC-E (detect.rs:14-15, detect.rs:85-87). The mimetype must additionally be the first entry and STORED (uncompressed) per EN 319 162; violations are recorded as MimetypeNotFirstEntry / MimetypeCompressed deviations but do not by themselves disqualify the container (detect.rs:97-112). A missing or non-conformant mimetype records MimetypeMissing / MimetypeNonConformantValue and falls back to layout inference (detect.rs:88-96, detect.rs:136).

The layout inference infer_profile (detect.rs:147) applies when the mimetype is absent or non-conformant: the presence of any ASiCManifest implies ASiC-E (detect.rs:149); otherwise a single plainly-named signature file (META-INF/signature.p7s or META-INF/signatures.xml, no numeric suffix) implies ASiC-S, while a numeric suffix or more than one signature implies ASiC-E (detect.rs:157-168).

Family (CAdES vs XAdES). Detection scans the META-INF/ entry names with case-sensitive predicates: is_cades_signature matches META-INF/signatureNNN.p7s (detect.rs:45), is_xades_signature matches META-INF/signaturesNNN.xml (detect.rs:54), and is_asic_manifest matches META-INF/ASiCManifest*.xml while deliberately excluding the ASiCArchiveManifest (LTA, out of scope) and the OpenDocument manifest.xml (detect.rs:65-70). The family field records the primary family (CAdES is preferred when both are present, detect.rs:129), but it is not used to dispatch — it is a diagnostic field (detect.rs:35-39). Instead, extract processes every family actually present: it independently extends the output with CAdES signatures (lib.rs:65) and XAdES signatures (lib.rs:68) so a mixed container (both signature*.p7s and signatures*.xml) drops no signature (FR-014/FR-020, lib.rs:56-70).

The not-ASiC boundary. detect::detect returns None — and extract maps that to AsicError::NotAsic (lib.rs:52-54) — when the archive has neither a CAdES nor a XAdES signature file (detect.rs:122-124). The source is explicit that a conformant mimetype alone is not enough: there must be signature material to verify (detect.rs:119-121). This NotAsic outcome is exactly what causes the host to leave asic_signatures empty, which the kernel then surfaces as asic_unsupported_container (§4.5.2). For an ASiC-E CAdES container the CAdES signs the ASiCManifest bytes and each DataObjectReference digest is recomputed in the kernel; for an ASiC-S CAdES container the CAdES signs the single non-mimetype data object directly (lib.rs:110-139).

4.6 After dispatch: aggregation is uniform across arms

Regardless of which arm runs, every path produces a Vec<SignatureEntry> and re-converges on a common tail in verify_with (crates/pverify-core/src/verify.rs:329-342, and the equivalent in the ASiC early-return at verify.rs:212-218): per-step weak-algorithm flags are folded into the header via aggregate_for_header, and the consolidated material inventory is derived from the completed report tree by derive_validation_objects — a pure &Report read that adds no network access and no new cryptography (verify.rs:341). The detailed ETSI indication aggregation (aggregate_etsi, the severity ordering and the never-mask layering) is covered in Chapter 5 §5.7 and the Result Model (Chapter 14); from the classification standpoint the key invariant is that the shape of the output — one or more SignatureEntry values plus a header — is identical no matter which format was detected, so downstream consumers parse a single uniform schema.

4.7 Failure modes and the "cannot affirm" discipline

The classification and dispatch layer never fabricates a verdict for an input it cannot place or verify at its supported level. The table below collects the honest-degradation outcomes that originate in this layer.

The distinction between the two failure categories is principled. CLI invocation errors (exit 2) are reserved for cases where the request itself is contradictory or under-specified — a PDF cannot be detached, a detached CAdES needs its content, two contradictory payloads cannot both be the signed object. INDETERMINATE report entries (exit 0) are reserved for cases where the request is well-formed but pverify cannot establish a fact at its supported level — an unrecognised container, an unsupported JAdES serialization, a multi-signer set the current schema cannot represent. The latter are reported as machine-readable facts so a downstream auditor sees precisely why no verdict was reached, consistent with Constitution §I.

4.8 Summary of invariants

• Single assignment. Every input is assigned to exactly one of {ASiC, PDF, XAdES, JAdES, CAdES}; CAdES is the residual default and ASiC is intercepted before detect_format so the ZIP magic never falls through.
• Cheap and prefix-only. Classification reads only the leading bytes (marker, BOM, first non-whitespace char), so it is deterministic and does not depend on whole-file content.
• Host/kernel agreement and CLI↔︎WASM parity. The host structural-parse selection and the kernel verifier-arm dispatch use byte-identical predicates, triplicated across the CLI, the kernel and the WASM host, so the routing — and therefore the report — is byte-identical on either host.
• No silent empty results. Each format arm returns at least one explanatory SignatureEntry even when the host extracted nothing.
• No silent payload. Detached CAdES with no, or conflicting, content is refused at the CLI rather than verified against an assumed payload.
• Honest degradation. An input that matches a family but cannot be verified at the supported level degrades to INDETERMINATE with a precise closed-enum sub-indication, never a fabricated TOTAL_FAILED/TOTAL_PASSED (Constitution §I).

5. CMS / CAdES Verification

This chapter specifies how pverify parses RFC 5652 Cryptographic Message Syntax (CMS) SignedData and verifies CAdES (ETSI EN 319 122) advanced electronic signatures over it. CMS SignedData is the load-bearing structure for the entire tool: CAdES verification operates on it directly, PAdES (Chapter 6) embeds it inside the PDF /Contents, RFC 3161 timestamp tokens (Chapter 12) are themselves SignedData, and ASiC (Chapter 7) delegates its inner CAdES signatures to the same pipeline described here. The CAdES path is therefore the reference implementation against which the other format chapters are written; where another format defers to "the CAdES pipeline", it means the orchestration documented in §5.7.

All code referenced in this chapter lives in the no_std + alloc, I/O-free verification kernel pverify-core (see Chapter 3 for the kernel/host boundary). The structural CMS parser is crates/pverify-core/src/cms/; the per-signature orchestration is crates/pverify-core/src/verify.rs, function verify_cades. Two JNSA-mandatory binding checks — signer identification + ESS signing-certificate binding (slice 025) and content-type binding (slice 026) — are integrated into that orchestration and are documented in §5.5 and §5.6.

5.1 Scope and AdES Level Vocabulary

pverify recognises four CAdES baseline levels, projected into the report's SignatureFormat enum by verify_cades (crates/pverify-core/src/verify.rs:1034-1042):

The promotion ladder is strictly ordered (archive_timestamps non-empty wins, then has_lt_lta_payload, then timestamps non-empty, else BES); the level is a fact recognised from the structure present, not a profile the input claims. There is no separate "B-ES vs B-B" distinction in the wire enum — CAdESBes covers both the legacy CAdES-BES (RFC 5126) and the EN 319 122-1 B-B baseline, because the structural surface pverify reads (signing certificate + signed attributes, no trusted timestamp) is identical.

Single-signer CMS is the supported case. Multi-signer SignedData is deliberately refused (§5.4.4) rather than reporting only the first signer.

5.2 The CMS SignedData Structural Parser

5.2.1 Design: a permissive TLV walker, not a typed decoder

The parser is crates/pverify-core/src/cms/signed_data.rs, type SignedDataParser. It is intentionally a permissive structural walker over the BER/DER TLV tree (built by crate::ber::parse_ber_tlv), not a strict field-ordered ASN.1 decoder. The module header records its provenance: it is derived from the civ project's ICAO 9303 SOD parser, which is RFC 5652 SignedData with the same outer shape as CAdES/PAdES, with the LDS-passport-specific extraction removed (Constitution §VII forbids carrying passport-domain code into the PKI surface).

The walker extracts the minimal field set the downstream checks need:

The walker accepts either a bare RFC 5652 ContentInfo SEQUENCE or an outer application-tagged 0x77 wrapper (the latter is the ICAO SOD framing, retained so any test vector that round-trips through civ also round-trips here — SignedDataParser::parse). It locates the SignedData by finding the first SEQUENCE whose first child is an OID (find_signed_data_content), then descending through the content [0] EXPLICIT wrapper into the inner SignedData SEQUENCE.

5.2.2 Field discrimination rules and their subtleties

Within the SignedData SEQUENCE, extract_signed_data_components walks the children in declared order with a small state machine:

• The first SEQUENCE after digestAlgorithms is treated as encapContentInfo (saw_encap flag), from which the eContentType OID and optional [0] EXPLICIT eContent are extracted. CAdES uses id-data (1.2.840.113549.1.7.1); embedded RFC 3161 tokens carry id-ct-TSTInfo (1.2.840.113549.1.9.16.1.4).
• The first SET (0x31) is digestAlgorithms; any later SET is signerInfos. This relies on there being at most two SETs at this level — true for conformant single-signer CAdES/PAdES. The walker records signer_info_count from the signerInfos SET so the multi-signer gate (§5.4.4) can fire.
• certificates [0] IMPLICIT (0xA0) yields each Certificate SEQUENCE's value bytes; the full DER header is re-attached downstream (§5.4.1).

The sid capture (extract_signer_info) is the one place the parser must be tag-precise. SignerInfo.sid is the element immediately after version (INTEGER, 0x02); the walker captures the first element after version and re-encodes it to full DER (reencode_tlv). The CHOICE is either issuerAndSerialNumber (SEQUENCE, tag 0x30) or subjectKeyIdentifier, the latter being a [0] IMPLICIT OCTET STRING whose wire tag is the primitive context tag 0x80, not the constructed 0xA0. Interpretation of the captured bytes is deferred to the selection site (§5.5.1) where the embedded certificate set is available.

The signedAttrs, signature, and unsignedAttrs fields are each captured once (is_none() guards), so a malformed second SignerInfo never overwrites the first signer's data — but the count is still incremented so the gate can reject the truncation honestly.

5.2.3 Failure behaviour

An empty input surfaces Error::Parse("empty CMS SignedData input"). A truncated 0x77 wrapper surfaces Error::Ber. An input with no recognisable SignedData SEQUENCE returns a SignedDataParser with all-empty fields (rather than an error); the verify pipeline then reports the structural absences as facts. These behaviours are pinned by the unit tests in signed_data.rs (e.g. parse_empty_input_returns_err, parse_returns_empty_fields_when_no_signed_data_seq_found).

5.3 SignedAttrs Canonicalisation and the messageDigest Check

5.3.1 SignedAttrs canonicalisation (RFC 5652 §5.4)

When signedAttrs is present, the signature is computed not over the raw [0] IMPLICIT body but over its DER re-encoding as a SET OF Attribute (universal tag 0x31) with the components sorted in ascending octet order. This is the RFC 5652 §5.4 / X.690 §11.5 rule that exists precisely so the verifier can reconstruct the signed octets independently of the on-wire ordering or the implicit-tag substitution.

crates/pverify-core/src/cms/canonical.rs — canonicalise_signed_attrs — implements this: it splits the stored value bytes into the constituent Attribute TLVs, sorts them with sort_unstable() (lexicographic byte comparison), and re-emits a 0x31-tagged SET. The module header documents why lexicographic byte comparison is equivalent to the X.690 §11.5 zero-padding rule here: for distinct DER TLVs that share an outer tag, the length octets diverge before any padding consideration arises, so the simpler comparison suffices.

5.3.2 The messageDigest comparison (RFC 5652 §11.2)

verify_content_digest (crates/pverify-core/src/cms/verify.rs):

1. Reads the digest algorithm from digest_algorithm_oid (mapped via HashAlg::from_oid_bytes; SHA-1 and SHA-2 only — SHA-3 is out of scope, cms/signed_attrs.rs::oid_to_hash_name).
2. Computes digest(content) over the bytes the signature commits to — the embedded eContent for attached CAdES, the --detached-content bytes for detached CAdES (resolution rule in §5.4.2).
3. Walks signedAttrs for the messageDigest attribute (1.2.840.113549.1.9.4) via find_message_digest_attribute and reads its OCTET STRING value.
4. Compares, producing a ContentDigestCheck carrying the declared digest, computed digest, the boolean digest_match, and a separate covered_content_sha256 (the raw covered bytes hashed under SHA-256 regardless of the signature's own digest algorithm — slice 016 diagnostic data, so the signed_content validation object's digest is correct even for SHA-384/512 signatures).

The function never emits a verdict — it records the observed digest fact. The mapping to messageDigest_mismatch happens later in aggregate_etsi (§5.7.4), and only when content was actually supplied (a detached signature with no content yields digest_match = false as a fact of non-evaluation, not a failure).

5.3.3 The SignedAttrs signature check

verify_signed_attrs (crates/pverify-core/src/cms/verify.rs) canonicalises signedAttrs (§5.3.1), extracts the signer certificate's SubjectPublicKeyInfo DER (re-encoded through x509-cert so the octet stream matches what the RustCrypto verifier expects), derives the signer's signatureAlgorithm OID by pairing the SPKI algorithm family with the declared digest, and verifies via crate::crypto::verify_with_alg.

The signatureAlgorithm derivation (derive_signer_sig_alg_oid) is necessary because the structural parser does not separately surface the SignerInfo's signatureAlgorithm field; the pairing reproduces the same OID a conformant SignerInfo would carry:

An unrecognised SPKI family produces SignedAttrsSignature::Failed { cause: UnsupportedAlgorithm }. A verify-and-fail produces Failed { cause: Other } (or MalformedPublicKey for a recognised-OID/undecodable-key, slice 010). The typed cause enum (SignedAttrsFailureKind) is stamped at the failure site so aggregate_etsi routes on the enum, never on a reason string prefix (a slice-029 hardening — a refactor of the human-readable reason can no longer silently re-classify the verdict).

The result is a SignedAttrsCheck. Its signed_attrs_digest_match is not an independent digest comparison: it is set to Some(true) exactly when verify_with_alg over the whole signature (canonicalised signedAttrs hashed under the declared digest, the signer's SPKI, and the signature octets) succeeds, and Some(false) otherwise — so the field is a derived alias of the verify outcome rather than a separately-checked predicate. The RSA/ECDSA/Ed25519 verify covers the full signature primitive, not a bare digest equality, so a future PSS/ECDSA path may distinguish a hash-only failure from a full-verify failure here. When signedAttrs is absent, the RFC 5652 §5.4 sign-over-eContent path is not wired — the function surfaces a structural Failed so the pipeline can decide (CAdES B-B requires signedAttrs).

5.4 CAdES Orchestration (verify_cades)

verify_cades (crates/pverify-core/src/verify.rs:475) is the top-level per-signature CAdES verifier, invoked by verify_with after detect_format routes a non-PDF, non-XML, non-JSON, non-ASiC input to the CAdES path (detect_format falls through to DetectedFormat::Cades). It returns exactly one SignatureEntry.

5.4.1 Stage sequence

5.4.2 Certificate reconstitution and content resolution

The body-only certificate slices stored by the parser are re-wrapped into full DER SEQUENCEs (reconstitute_certificate_der) and parsed by crate::x509::parse_certificate; a single un-parseable cert is skipped rather than sinking the pipeline. The count of CMS-embedded certs (cms_cert_count) is recorded before the host's extra_certificates (e.g. a bundle's certificates/) are appended, because the host intermediates are eligible as chain material but never as the signer — the signer is always selected from the CMS-embedded prefix (§5.5.1).

Content resolution for the digest and archive-timestamp imprint: embedded eContent (attached CAdES) wins over detached_content_bytes whenever both are present and non-empty; the CLI pre-flight has already enforced byte-equality if both were supplied. The observed source is recorded as ContentSourceTag::Embedded or Detached for the SignatureEntry.

5.4.3 Unsigned-attribute projection (T/LT/LTA material)

project_unsigned_attrs (crates/pverify-core/src/cms/unsigned_attrs.rs) walks the unsignedAttrs body into an UnsignedAttrsProjection:

These feed both the report's EmbeddedValidationData audit projection and the revocation/timestamp pipelines below.

5.4.4 Multi-signer refusal

When signer_info_count > 1, verify_cades returns cades_multi_signer_entry — INDETERMINATE with sub-indication cms_multi_signer_unsupported (crates/pverify-core/src/verify.rs:496, :1890). This is a slice-029 fact-reporting correction: before it, the parser silently kept only the first SignerInfo's fields, so a multi-signer CMS was reported as if a single signer existed — hiding signer-set evidence that relying parties care about for countersignature and audit workflows. Until the report grows a one-entry-per-SignerInfo model, the honest answer is refusal, never a verdict over a truncated signer set. This is a direct application of Constitution §I "cannot affirm".

5.5 Signer Identification and ESS Binding (slice 025)

Slice 025-cades-signer-binding closes two JNSA「デジタル署名検証ガイドライン」第1.1版 Mandatory (必須) checks from 表5.5.2-1 (JNSA gaps #90/#91). The governing clarification (specs/025-cades-signer-binding/spec.md): binding-broken → TOTAL_FAILED; cannot-identify → INDETERMINATE. Because PAdES delegates its embedded-CMS evaluation to the CAdES path (pades/mod.rs), both checks automatically extend to PAdES.

5.5.1 SignerIdentifier resolution

Before slice 025, pverify selected the signer by a heuristic ("first non-CA certificate in the CMS-embedded set"). The signer the signature value must verify against is identified by SignerInfo.sid (RFC 5652 §5.3), and a disagreement between the heuristic and the true sid target is a fact-reporting gap.

SignerIdentifier::parse (crates/pverify-core/src/cms/ess.rs) parses the captured sid DER:

• Outer tag 0x30 → IssuerAndSerial { issuer_dn, serial }, with the issuer Name SEQUENCE re-encoded to full DER so it can be fed to match_dn exactly like Certificate::issuer_dn.
• Outer tag 0x80 (the primitive [0] IMPLICIT OCTET STRING) → SubjectKeyId(octets).
• Any other tag, or a structural failure → Err → the malformed path.

select_signer_by_sid (crates/pverify-core/src/verify.rs:1096) then resolves the index only within the first cms_cert_count embedded certs:

• IssuerAndSerial: match by serial-number equality and issuer-DN linkage (x509::name::match_dn).
• SubjectKeyId: match by the certificate's subjectKeyIdentifier extension.

The outcomes are projected into a SignerIdentifierCheck { sid_form, match_outcome }:

On NotFound/Malformed the function still returns the legacy heuristic index as a report scaffold so a chain can be assembled for audit — but the verdict is gated on match_outcome before any signature/digest gate, so the heuristic fallback never silently becomes the verified-against certificate.

5.5.2 ESS signing-certificate binding (RFC 5035)

The ESS signing-certificate (v1, SHA-1 fixed) / signing-certificate-v2 (declared algorithm, SHA-256 default) signed attribute cryptographically pins the signer certificate by hash, defending against certificate-substitution (same key pair, re-issued or forged certificate). parse_ess_signing_certificate (crates/pverify-core/src/cms/ess.rs) locates the attribute (id-aa-signingCertificate 1.2.840.113549.1.9.16.2.12 / id-aa-signingCertificateV2 …2.47) and parses its first ESSCertID/ESSCertIDv2:

ESSCertID   ::= SEQUENCE { certHash OCTET STRING, issuerSerial IssuerSerial OPTIONAL }
ESSCertIDv2 ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier DEFAULT {id-sha256},
                           certHash OCTET STRING, issuerSerial IssuerSerial OPTIONAL }

Only the first ESSCertID is the signer-cert binding; later entries describe chain certs and are out of scope. For v2, a leading SEQUENCE is the explicit hashAlgorithm; its absence means the SHA-256 default. The issuerSerial's issuer is GeneralNames; pverify extracts the inner Name DER of a directoryName [4] GeneralName (constructed context tag 0xA4), and treats any non-directoryName form as not-evaluable (Mandatory-if-Exists: it does not fail).

compute_ess_binding (crates/pverify-core/src/verify.rs:1195) computes the binding against the sid-selected signer certificate:

• Recompute digest(signer_cert.der_bytes) under the declared algorithm and compare to certHash → CertHashCheck { hash_match }.
• When issuerSerial is present and directoryName-formed: compare its DN linkage and serial to the signer cert → IssuerSerialCheck { matches }.
• ESS-v1 (SHA-1) is accept-and-flag: a WeakAlgorithmFlag (role EssSigningCertificateDigest) is attached to the signer chain step; it never rejects (FR-012a).

Three not-evaluable / malformed dispositions (all Constitution §I "cannot affirm"):

• Unknown/unsupported declared hash OID → hash_match: None.
• Non-directoryName issuerSerial GeneralName → matches: None.
• A structurally malformed ESS attribute (slice-029) → present: true with hash_match: None (distinguished from absence, which stays present: false with no indication impact). The existing precedence already routes a hash_match: null on an otherwise-passing signature to INDETERMINATE / signing_certificate_digest_not_evaluable, so no new sub-indication was needed.

5.6 Content-Type Binding (slice 026)

Slice 026-cades-contenttype-binding adds the RFC 5652 §5.3 content-type signed-attribute equality check (a JNSA-mandatory CAdES step). The content-type attribute (1.2.840.113549.1.9.3) MUST carry an OID equal to EncapsulatedContentInfo.eContentType; an attacker who could substitute the encapsulated content type without invalidating the signature would otherwise change the meaning of the signed bytes.

find_content_type_attribute (crates/pverify-core/src/cms/verify.rs) is a structural clone of the messageDigest walk, differing only in the attribute OID and that the value SET must hold exactly one OBJECT IDENTIFIER. It returns Present(oid), Absent, or Malformed. compute_content_type_check (crates/pverify-core/src/verify.rs:1388) compares by raw OID byte-equality and produces a ContentTypeCheck with outcome:

RFC 5652 §5.3 makes the attribute MUST-present when any signed attribute is present, hence Missing is a TOTAL_FAILED, while a malformed attribute or absent eContentType (cannot affirm) is INDETERMINATE.

5.7 Timestamps, Per-Object VRT, and Indication Aggregation

5.7.1 Signature-time-stamps (B-T)

Each signature-time-stamp token (RFC 3161, RFC 5126 §6.3) commits to the signer's signature OCTET STRING; verify_cades hands those bytes as the imprint input to verify_timestamp_token (Chapter 12) with role SignatureTimestamp. The embedded certs serve as the TSA-chain intermediates, validated against the same anchor store as the signer.

5.7.2 Archive-time-stamps-v3 (B-LTA)

For each archive-time-stamp-v3, archive_v3_imprint_input (crates/pverify-core/src/cms/canonical.rs) recomputes the ETSI EN 319 122-1 §6.3.4 canonical imprint input and passes it to verify_timestamp_token (role ArchiveTimestamp); a mismatch is archive_timestamp_imprint_mismatch (TOTAL_FAILED).

The canonical input concatenates, in order: (1) the content bytes (embedded eContent or detached); (2) every embedded certificate's full DER in on-disk SET-OF order (not canonically sorted); (3) the SignedData CRLs slot (currently always empty — the parser does not surface it, and pverify's LTA fixtures place revocation material in unsignedAttrs); (4) the signedAttrs value bytes; (5) the signer signature value bytes; (6) the unsignedAttrs with the archive-TS being recomputed and every later one removed, so a chain of sequential archive-time-stamps forms a hash chain (the checkpoint_index mechanism in unsigned_attrs_without_archive_ts_at_or_after).

The module documents this as a v0.3 simplified encoder: it is a deterministic byte recipe (with pverify-side SA/SI/UA length-prefixed framing in slots 4–6 to keep boundaries unambiguous) sufficient to detect every modification ETSI §6.3.4 cares about — tampered content, embedded cert/CRL, signedAttrs, signature, or any non-self unsigned-attribute change. It is not yet a fully general §6.3.4 encoder (multi-archive layering, certVals/revocVals update semantics, on-disk SET-OF ordering corner cases). This is an acknowledged scope limitation, not a silent approximation: where the imprint cannot be computed (no content available), the imprint is treated as informational only. Auditors validating LTA archives over complex multi-layer structures should treat the imprint result as a positive indicator rather than a complete §6.3.4 conformance assertion.

5.7.3 Per-object VRT and TSA-chain revocation

After the timestamp tokens are populated, crate::vrt::derive_vrt (Chapter 12) builds the recursive-outer-covering graph and assigns each object — signer chain, signer signature, each signature-TS, each archive-TS — its own Validation Reference Time. The signer chain is then re-validated at vrt.signer_chain.value (re-running validate_path → wire_chain_step_signatures → weak-algorithm flagging → ESS flag re-attach → apply_revocations) whenever that VRT differs from request_at; if it equals request_at the re-validation is skipped because it would be byte-identical. Each timestamp's TSA chain is likewise re-validated at its own VRT, and each is revocation-checked via apply_tsa_chain_revocation_for_token (slice 033, crates/pverify-core/src/verify.rs:1552) at that object's VRT, consuming the embedded revocation-values OCSP/CRL material plus the configured fetcher per the verification mode. This runs unconditionally for every timestamp because the first-pass verify_timestamp_token applies zero revocation. A confirmed-revoked TSA cert degrades to INDETERMINATE / revoked_no_poe — "cannot affirm the timestamp", never a forgery claim.

OCSP nonce (RFC 8954, slice 035). When the live OCSP fetcher fires (online mode), it sends a 16-byte nonce generated by a NonceSource trait implementation (backed by a CSPRNG in the platform host). The responder's reply is accepted only if it echoes back the same nonce or omits the nonce extension altogether (RFC 8954 §2.1); a mismatched nonce is treated as an unauthenticated response and the OCSP attempt is degraded to indeterminate. An in-run OCSP cache (OcspCache) deduplicates requests within a single verify_with call so the same certID is fetched at most once per run.

5.7.4 Base ETSI indication aggregation

aggregate_etsi (crates/pverify-core/src/verify.rs:2343) folds the chain/signature/digest/archive-imprint findings into a base EtsiIndication with severity ordering TOTAL_FAILED > INDETERMINATE > TOTAL_PASSED and first-finding-wins within a severity tier. The precedence ladder (abbreviated, in evaluation order):

1. Path-validation structural TOTAL_FAILED (e.g. chain_constraints_failure).
2. archive_timestamp_imprint_mismatch (TOTAL_FAILED).
3. OCSP responder signature verifies-and-fails (ocsp_responder_signature_invalid, TOTAL_FAILED).
4. SignedAttrs signature failure — routed by the typed cause: Other → TOTAL_FAILED / signed_attrs_signature_failed; UnsupportedAlgorithm → INDETERMINATE / signature_algorithm_unsupported; MalformedPublicKey → INDETERMINATE / public_key_malformed.
5. Content digest mismatch (only when content was supplied) → TOTAL_FAILED / messageDigest_mismatch.
6. Signer-cert revoked on CRL/OCSP → TOTAL_FAILED / signer_certificate_revoked[_via_ocsp].
7. Archive imprint under unsupported algorithm, malformed-public-key chain step, unsupported chain signatureAlgorithm, Name-Constraints findings, policy-rejected → various INDETERMINATE.

The terminating-anchor step's placeholder revocation record is excluded from the revocation scan, so a stale-CRL sub-indication is never falsely emitted on the anchor itself.

5.7.5 Layered indications (never masking a proven TOTAL_FAILED)

The base indication is then degraded — never masked upward — by four ordered layers, each of which only acts when the base is not already a proven TOTAL_FAILED:

1. Signer-binding (025) — apply_signer_binding_indication (:1324): the signer-identification gate is absolute first (an NotFound/Malformed sid is evaluated before any signature/digest result, since those presuppose a correctly identified signer). Then ESS certHash/issuerSerial mismatch upgrades a non-TOTAL_FAILED base to TOTAL_FAILED; an ESS not-evaluable digest degrades a would-be TOTAL_PASSED to INDETERMINATE / signing_certificate_digest_not_evaluable.
2. Content-type (026) — apply_content_type_indication (:1441): mismatch/missing → TOTAL_FAILED; malformed/unavailable → INDETERMINATE.
3. Algorithm-validity (032, opt-in) — apply_algorithm_validity_indication (:1480): only when --algorithm-policy is supplied; a failing/indeterminate object degrades to INDETERMINATE / crypto_constraints_failure_no_poe, mirroring ETSI CRYPTO_CONSTRAINTS_FAILURE_NO_POE. Off by default; off-path output is byte-identical (Chapter 13).
4. TSA-revocation (033) — apply_tsa_revocation_indication (:1622): a confirmed-revoked TSA cert on any timestamp degrades to INDETERMINATE / revoked_no_poe.

Each layer's "only degrade when not already a proven TOTAL_FAILED" guard is the never-mask discipline: a cryptographically broken signature outranks a deprecated-algorithm or revoked-TSA fact, and a proven failure is never overwritten by a softer indeterminate.

5.8 Closed Vocabulary and Cross-Format Reuse

Every disposition in this chapter resolves to the closed SubIndication enum (crates/pverify-core/src/report/etsi.rs, mirrored 1:1 into the root report-schema.json); no free-form verdict text reaches the report. The relevant CAdES-path sub-indications are: signer_certificate_not_found, signer_identifier_malformed, signing_certificate_digest_mismatch, signing_certificate_issuer_serial_mismatch, signing_certificate_digest_not_evaluable, content_type_mismatch, content_type_missing, content_type_not_evaluable, signed_attrs_signature_failed, messageDigest_mismatch, signer_certificate_revoked, signer_certificate_revoked_via_ocsp, archive_timestamp_imprint_mismatch, cms_multi_signer_unsupported, and the various algorithm/revocation indeterminates shared with the other formats.

The SignedDataParser and the verify_cades orchestration are the substrate the rest of the tool builds on: PAdES (Chapter 6) parses the PDF host-side and feeds the embedded CMS through this same SignedDataParser + the §5.5/§5.6 binding checks, layering /DSS//VRI revocation material on top; RFC 3161 timestamp tokens (Chapter 12) are parsed by SignedDataParser as id-ct-TSTInfo-typed SignedData; ASiC (Chapter 7) routes each inner CAdES signature through verify_cades. The signer-binding precedence, the typed-cause failure routing, and the never-mask aggregation discipline are therefore not CAdES-local conventions but the tool-wide contract for how observed cryptographic facts become ETSI indications.

6. PAdES Verification

This chapter specifies how pverify verifies PAdES (PDF Advanced Electronic Signatures, ETSI EN 319 142). It covers the host/core split that keeps PDF parsing out of the WASM-clean kernel, the PDF signature-dictionary projection, the /ByteRange integrity and covers-EOF discipline, incremental-update revision handling, document timestamps (/DocTimeStamp), the RFC 5280 §6.1.5 empty-policy-tree relaxation that unblocked Japanese public PDFs, and — at length — the branch-034 work that lets pverify consume a PDF's own long-term validation material: the document-level /DSS dictionary (/Certs, /CRLs, /OCSPs), its per-signature /VRI sub-dictionary, and the Adobe revocationInfoArchival CMS attribute.

The PAdES verifier reuses, by deliberate design, the same CMS/chain/revocation/timestamp machinery that drives CAdES (see Chapter 4 for format dispatch and Chapter 5 for CAdES); the format-specific surface is small and is the focus here. Per-object Validation Reference Time (VRT) derivation is covered in Chapter 12, revocation evaluation in Chapter 11, and the report/schema model in Chapter 14; this chapter cross-references them where the PAdES path threads into them.

6.1 Scope and AdES-level support

A PDF signature is a CMS SignedData (RFC 5652) embedded in a PDF signature dictionary, where the signed content is not the CMS eContent but the PDF bytes selected by a /ByteRange. pverify therefore treats PAdES as detached CAdES over a byte-range-selected message, and routes the embedded CMS through the identical pipeline used for detached CAdES (crates/pverify-core/src/pades/mod.rs, module doc and verify_one_signature).

pverify supports the following PAdES baseline levels:

The format string emitted for every PAdES SignatureEntry is SignatureFormat::PAdESB (crates/pverify-core/src/pades/mod.rs; the entry constructors all set format: SignatureFormat::PAdESB). The level distinction (B/T/LT/LTA) is expressed by the facts the entry carries — the presence and verification of timestamps[] tokens, the vrt block (Chapter 12), and the provenance of consumed revocation material — rather than by a distinct format enum value. This is consistent with the fact-reporting discipline of Constitution §I: pverify reports what it observed (a verified archive timestamp, a DSS-borne CRL) rather than asserting a marketing-grade "this is a valid PAdES-LTA".

6.1.1 Multi-signer refusal

A PAdES SignedData carrying more than one SignerInfo is refused honestly. verify_one_signature checks parsed.signer_info_count > 1 immediately after parsing and returns multi_signer_entry, an INDETERMINATE entry with sub-indication CmsMultiSignerUnsupported (crates/pverify-core/src/pades/mod.rs, verify_one_signature and multi_signer_entry). This mirrors the CAdES gate (verify.rs:496, cms_multi_signer_unsupported). The remediation note in the source records why: a pre-029 parser silently retained only the first SignerInfo, so a multi-signer PDF would have reported only the first signer's verdict — a fact-suppression bug. Refusing is the §I "cannot affirm" response.

Note the distinction between one PDF with multiple signature dictionaries (a legitimate incremental-update layout — see §6.4, fully supported, one SignatureEntry per dictionary) and one CMS with multiple SignerInfos (refused). PAdES does not co-sign within a single CMS; multiple PDF signers each add their own signature dictionary in successive incremental updates.

6.2 Host/core split: where PDF parsing happens

Constitution §V (Library-First) and §VI (WASM-clean core, NON-NEGOTIABLE) forbid PDF parsing inside pverify-core, which must compile to wasm32-unknown-unknown and link no lopdf/zip/flate2. All PDF structure parsing therefore happens in two host extractors that produce model-free byte structures and feed them additively into the kernel:

• Native CLI: crates/pverify-cli/src/pdf.rs (uses lopdf).
• Browser/WASM host: web/pverify-wasm/src/lib.rs (also uses lopdf, in the intentionally-detached web/pverify-wasm workspace).

These two extractors are required to be byte-for-byte parallel ports of one another (the CLI↔︎WASM parity invariant). The kernel consumes the parsed structures through additive VerificationRequest fields (crates/pverify-core/src/verify.rs):

• pdf_signature_dicts: Vec<PdfSignatureDescriptor> (verify.rs:86) — one descriptor per signature/DocTimeStamp dictionary.
• pdf_validation_data: PdfValidationData (verify.rs:95) — the document-level /DSS+/VRI material (branch 034, §6.5).

Format dispatch in verify_with routes a %PDF--sniffed input to crate::pades::verify_pdf, passing both fields (verify.rs:241–247). For a non-PDF input both fields are Default/empty (e.g. verify.rs:2205), so the kernel only ever consults the channel matching the sniffed format.

The host never performs cryptography or revocation logic; it performs only PDF structure traversal, stream decoding (FlateDecode), %%EOF scanning and DER extraction. The kernel performs all cryptography, path validation, revocation evaluation and indication aggregation, on pure byte slices.

6.2.1 The PdfSignatureDescriptor projection

The descriptor (crates/pverify-core/src/pades/mod.rs, PdfSignatureDescriptor) is the host→core projection of a single signature dictionary:

dict_type and revision_end are input projection fields, not serialized into the report. The host extractor accepts dictionaries whose /Type is /Sig or /DocTimeStamp and which carry both /ByteRange and /Contents; anything else is skipped (extract_signatures, the match dict.get(b"Type") arm in pdf.rs). Signature dictionaries may live anywhere in the object graph (most commonly under AcroForm.Fields[*].V), so the extractor walks every object rather than only the AcroForm (pdf.rs, for (_id, object) in doc.objects.iter() and the module doc).

The /Contents blob is a fixed-width PDF hex string with trailing zero-byte padding (PDF 32000-1 §12.8.1). Because the CMS SignedData is a single DER SEQUENCE, the host truncates to the outer TLV's declared length so the BER parser never sees the padding (pdf.rs, trim_to_outer_sequence; the WASM port is identical in web/pverify-wasm/src/lib.rs). The truncation reads the 0x30 constructed-SEQUENCE tag and short/long-form length and bounds-checks header_len + value_len <= bytes.len(), falling back to the raw blob on any malformation.

6.3 ByteRange integrity and the covers-EOF check

verify_one_signature (crates/pverify-core/src/pades/mod.rs) performs structural ByteRange validation before any cryptography. Two distinct failure modes exist, each with its own closed sub-indication:

1. Malformed ByteRange → TOTAL_FAILED with SubIndication::PdfByteRangeMalformed. The check (using checked arithmetic to avoid overflow) requires start1 + len1 <= start2 (the two windows are ordered and non-overlapping) and start2 + len2 <= pdf_bytes.len() (both windows lie inside the file). If the arithmetic overflows or the windows are out of order/out of bounds, malformed is true and no crypto is attempted.

2. ByteRange does not cover EOF → TOTAL_FAILED with SubIndication::PdfByteRangeDoesNotCoverEof. This is the integrity check that catches a signature that does not commit to the whole (relevant) file — i.e. content appended after the signed region that the signature does not protect.

The covers-EOF computation is revision-aware and is the subject of §6.4. For a single-revision PDF it reduces to the classical start2 + len2 == pdf_bytes.len().

The bytes the signature commits to are the concatenation of the two windows:

covered = pdf_bytes[start1 .. start1+len1] || pdf_bytes[start2 .. start2+len2]

This covered slice is fed to the CMS pipeline as the detached content (it replaces the --detached-content slot used by detached CAdES). The content digest is computed by verify_content_digest(&parsed, &covered) and the signed-attributes digest and signature by verify_signed_attrs(&parsed, &signer_cert) — both shared with CAdES (Chapter 5).

If the PDF carries no signature dictionaries at all, verify_pdf returns a single INDETERMINATE entry (no_signature_entry) so a consumer sees a definite fact rather than an empty array (verify_pdf, the sig_dicts.is_empty() guard).

6.4 Incremental-update revisions and /DocTimeStamp

PDF supports incremental updates: a later revision appends bytes (a new cross-reference section, new objects, a new %%EOF) without rewriting earlier bytes. A signature created in revision 1 legitimately covers only revision 1's %%EOF; a document timestamp or second signature added in revision 2 covers the file up to revision 2's %%EOF. This is precisely the layout of Japanese official-gazette (官報 / e-官報) PDFs and is the central PAdES-LTA pattern.

Branch 009-v07-pades-incremental (v0.7) fixed two coupled bugs that made such documents falsely report pdf_byte_range_does_not_cover_eof (specs/009-v07-pades-incremental/spec.md):

1. The covers-EOF test required every signature to cover the final file length. Revision 1's signature, covering only revision-1's %%EOF, failed.
2. The extractor honoured only /Type /Sig and silently dropped /Type /DocTimeStamp, so the document timestamp that defines revision 2's extent was invisible.

6.4.1 Revision-boundary discovery

Revision boundaries are discovered host-side by scanning the raw bytes for every %%EOF marker (pdf.rs, scan_revision_ends; parity port in web/pverify-wasm/src/lib.rs). The scan returns the byte offset immediately past each %%EOF and its trailing line-ending. PDF §7.2 requires exactly one end-of-line (EOL) marker after %%EOF; however, some producers emit two consecutive newlines (%%EOF\n\n). The scanner absorbs at most one EOL sequence: it advances past one \r\n, \n, or \r, and stops — the second trailing newline is left unconsumed. This "at-most-one-EOL" rule (PR #126 off-by-1 fix) is what allows PAdES-LT/LTA documents from LGPKI2 and similar producers to pass the covers_own_revision check: their revision boundary ends at the first EOL after %%EOF, so the start2 + len2 covered-end lands exactly there. The scan stays in the host (Constitution §V/§VI); the core only consumes the resulting revision_end per descriptor.

Each descriptor's revision_end is the smallest %%EOF offset at or after that dictionary's covered-end start2 + len2, falling back to the file length if none is at/after (pdf.rs, the revision_ends.iter().copied().find(|&e| e >= covered_end).unwrap_or(pdf_len) assignment).

The VerificationRequest carries a pdf_last_revision_end: u64 field (default 0, meaning pdf_bytes.len()). When set by the host, the kernel clamps pdf_bytes.len() to this value for the FR-702 trailing-content check. This allows a caller that knows the true last revision end (e.g. because it detected a /DSS-appending incremental update) to suppress a false-positive pdf_byte_range_does_not_cover_eof for the /DSS append revision.

6.4.2 The revision-aware covers-EOF rule

The kernel applies the rule in verify_one_signature (crates/pverify-core/src/pades/mod.rs). Let max_revision_end be the largest revision_end across all dictionaries (computed once in verify_pdf). For a signature with covered-end start2 + len2:

• covers_own_revision = (start2 + len2 == revision_end) — the signature covers exactly the revision it closes (FR-701).
• is_final_revision = (revision_end == max_revision_end).
• trailing_uncovered = (max_revision_end < pdf_bytes.len()).
• covers_eof = covers_own_revision && !(is_final_revision && trailing_uncovered).

In words: a signature covers EOF iff it covers its own revision, unless it closes the last signed revision yet bytes trail that revision uncovered (FR-702). The second clause is essential integrity: trailing content that no signature commits to is a real defect (a possible malicious append) and is surfaced via the existing pdf_byte_range_does_not_cover_eof — no new closed-enum tag was added (clarification Q2→A in specs/009-.../spec.md). For a single-revision PDF, revision_end == max_revision_end == pdf_len, so the rule collapses to the classical start2 + len2 == pdf_len, preserving byte-identity with the pre-v0.7 fixtures.

6.4.3 DocTimeStamp processing

A /DocTimeStamp dictionary carries an RFC 3161 timestamp token over its own ByteRange-covered bytes — the PAdES archive-timestamp mechanism. verify_pdf processes the descriptor list in document order with a small state machine (crates/pverify-core/src/pades/mod.rs, the for desc in sig_dicts loop):

• A Signature descriptor is verified by verify_one_signature → one SignatureEntry; it becomes the "most-recent preceding signature".
• A DocTimeStamp descriptor is verified by verify_doc_timestamp (which re-checks the ByteRange structurally, recomputes the covered bytes, and calls crate::timestamp::verify_timestamp_token with role ArchiveTimestamp). The resulting TimestampToken:
  • if a preceding signature exists, is appended to that entry's timestamps[] and recorded as a covering archive token for that entry's VRT graph (clarification 2026-06-17 Q1→A: a /DocTimeStamp is surfaced as a TimestampToken with archive_timestamp role on the preceding signature, not as its own entry);
  • if no preceding signature exists, becomes its own minimal doc_timestamp_only_entry;
  • if the TST failed to parse/verify, is still surfaced (as a minimal entry) rather than dropped — its absence is itself a fact.

The grouping keeps, parallel-indexed with the entries, both the covering TimestampTokens (doc_ts_per_entry) and the originating /DocTimeStamp descriptors (doc_ts_descs_per_entry). The descriptors are needed in the second pass so each archive token's own CMS can be re-parsed to recover its TSA certificates for the per-object-VRT revocation check (033, §6.5.5).

6.4.4 Per-object VRT second pass

After all /DocTimeStamps are grouped, verify_pdf runs a second pass per signature (apply_pades_vrt). The covering graph is signer ← signature-time-stamp ← /DocTimeStamp (the signature-TS tokens at the front of entry.timestamps, the archive /DocTimeStamp tokens at the tail). crate::vrt::derive_vrt (Chapter 12) computes each object's VRT by the recursive-outer-covering rule: the signer chain promotes to the signature-TS GenTime, the signature-TS chain to the /DocTimeStamp GenTime, and the outermost /DocTimeStamp falls back to request_at.

If — and only if — the signer-chain VRT differs from request.verification_time, the signer chain is re-validated at the promoted time (revalidate_pades_signer_chain): the CMS is re-parsed, validate_path + wire_chain_step_signatures + apply_revocations + the ETSI/binding/content-type layering are re-run at the VRT. This is the PAdES-LTA headline — a signer certificate that expired after signing still validates because the covering archive timestamp proves it was valid at signing time. When no timestamp promotes the chain (the common PAdES-B/-T case), the second pass is a no-op overwrite of the at_request_time placeholder, so those reports stay byte-identical except the additive vrt block.

6.5 Document-level validation material: /DSS, /VRI, revocationInfoArchival (branch 034)

This section is the principal subject of the chapter. Branch 034-pades-dss-vri (the JNSA guideline gap review) makes pverify consume the revocation material a PAdES document carries about itself. Before 034, the PAdES path invoked the revocation pipeline with empty embedded slices (&[], &[]), so a fully self-evidenced offline PAdES-LT/LTA stalled at INDETERMINATE / revocation_not_checked_offline even though every CRL and OCSP response it needed sat in its own /DSS (docs/pades-dss-vri.md). 034 reads that material host-side and threads it into the existing revocation pipeline.

6.5.1 The three material sources

All three are additive evidence: the revocation pipeline matches CRLs by issuer+serial and OCSP responses by certID, so a superset of material can only ever resolve an indeterminate to a definite good/revoked — it can never fabricate a good outcome (data-model VR-5). This property is what makes the union-across-revisions and DSS-global-fallback behaviour safe.

6.5.2 Host-side /DSS+/VRI extraction

extract_validation_data (crates/pverify-cli/src/pdf.rs; parity port extract_pdf_validation_data in web/pverify-wasm/src/lib.rs) parses the document-level material into a pure-data PdfValidationData:

pades::PdfValidationData { dss_certs, dss_crls, dss_ocsps, vri: Vec<VriEntry> }

Extraction rules, grounded in the code:

• Union across all revisions (Q6/R-8). lopdf resolves the final object graph, but to be forgiving of producers that leave a superseded /DSS in an earlier revision, the extractor collects the catalog's /DSS and every other /DSS-shaped dictionary found by walking every object, then unions all their pools (pdf.rs, the dss_dicts vector built from doc.catalog() plus the object walk). Union is safe precisely because material is additive evidence matched by issuer/serial/certID.
• Dedup by raw DER bytes. collect_pool appends a decoded stream's bytes only if !out.contains(&der) — deduplication is by exact DER, not by parsed identity. Streams are decoded with decompressed_content() (applying FlateDecode etc.), falling back to raw content on a decode error.
• /VRI indexing. Each /DSS /VRI sub-entry is keyed by its dictionary name, uppercased to form contents_sha1_hex, and its /Cert//CRL//OCSP pools collected into a VriEntry. Duplicate keys (a later revision's VRI for the same signature) are skipped; VRI entries are sorted by key for deterministic order (pdf.rs, data.vri.sort_by(...)).
• Resource bounds (FR-011/R-9). MAX_DSS_ENTRIES_PER_POOL = 4096 and MAX_DSS_STREAM_BYTES = 16 MiB cap the work; empty or oversized streams are skipped. A malformed or hostile document degrades to "no usable material" rather than performing unbounded work or panicking — a partially-malformed DSS still yields the entries that parsed cleanly.

PdfValidationData is empty (Default) for all non-PDF inputs and for PDFs with no /DSS. This is the byte-identity guarantee (FR-008): a no-DSS PDF report differs from a pre-034 report only in the schema_version string (verified by the e2e test no_dss_document_is_strictly_additive in crates/pverify-cli/tests/pades_dss_vri_e2e.rs, which asserts no pdf_dss/pdf_vri origin appears).

The two extractors are byte-for-byte parallel ports (the CLI↔︎WASM parity invariant); the WASM port carries the same MAX_DSS_* constants and the same collect_pool/resolve_dict/scan_revision_ends/trim_to_outer_sequence logic.

6.5.3 Per-object resolution: VRI-preferred, DSS-global-fallback

The kernel performs pure-compute resolution per object in resolve_material (crates/pverify-core/src/pades/mod.rs):

key      = uppercase_hex(sha1(object.contents))
material = vri.find(|e| e.contents_sha1_hex == key && !e.is_empty())   // → PdfVri
             .unwrap_or(dss_{crls, ocsps, certs})                      // → PdfDss

A non-empty /VRI entry whose key matches the object's /Contents SHA-1 wins (provenance PdfVri); otherwise the document-level /DSS pools are used (provenance PdfDss). An empty VRI entry (one referencing no material) does not win — resolution falls back to the global pools (VriEntry::is_empty, exercised by the unit test dss_vri_empty_vri_entry_falls_back_to_dss). The resolved certificate DER are parsed for path building; entries that fail to parse are skipped (resolve_material, the filter_map(|der| crate::x509::parse_certificate(der).ok())).

The SHA-1 key is computed by sha1_uppercase_hex (crates/pverify-core/src/pades/mod.rs) reusing the core's existing SHA-1 facility (already present for SHA-1 signature verification — no new dependency, FR-012). The source comment is explicit and audit-relevant: SHA-1 is used here only as a dictionary lookup key, never as a security primitive. Its cryptographic weakness is irrelevant because a collision could only mis-route additive evidence, which cannot fabricate a good outcome (VR-5). The key derivation is pinned against the known SHA-1 vectors for the empty string and "abc" (dss_vri_sha1_uppercase_hex_matches_known_vectors).

ResolvedMaterial is an internal, non-wire struct { crls, ocsps, certs, provenance } with provenance ∈ {PdfDss, PdfVri}.

6.5.4 Signer-chain consumption

In verify_one_signature, after selecting the signer certificate and building the intermediate-candidate set, the resolved material is applied (crates/pverify-core/src/pades/mod.rs):

1. DSS /Certs join the intermediate candidates only — never the anchors (Q7/FR-005/VR-2). Each resolved cert is appended to intermediates if not already present (deduped by fingerprint_hex). DSS certificates are path-building candidates; the configured trust store (anchors.anchors()) remains the sole source of trust anchors. A DSS cert that happens to match a configured anchor fingerprint is still anchored from the store (origin trust_anchor), not from the document.
2. Adobe revocationInfoArchival is projected from the CMS (project_revocation_info_archival) and its CRL/OCSP DER merged into the signer-side material. Because it lives in the CMS rather than the PDF structure, it keeps provenance signature_embedded, not pdf_dss.
3. The merged CRL/OCSP DER feed the existing apply_revocations call (crates/pverify-core/src/pades/mod.rs, the apply_revocations(..., &signer_ocsps, &signer_crls, mode) call that previously received &[], &[]).
4. Provenance tagging. After revocation runs, tag_document_revocation_provenance walks the resulting chain steps and, for any CRL/OCSP record whose consumed DER matches (by SHA-256 of the supplied bytes against the record's body_sha256/response_sha256), sets pdf_source = PdfDss or PdfVri. Matching is exact and deterministic — no re-parse. revocationInfoArchival material is not tagged (it keeps the empty-source_uri → signature_embedded default).

The revocationInfoArchival projection (extract_rev_info_archival_from_attrs) is a best-effort BER walk over the CMS signed/unsigned attribute blobs (both are scanned; the attribute is "most common" in signedAttrs). It matches the OID body 2a 86 48 86 f7 2f 01 01 08 and parses the value SET → SEQUENCE → [0] crl SEQUENCE OF CertificateList / [1] ocsp SEQUENCE OF OCSPResponse, re-encoding each inner TLV. [2] otherRevInfo is a documented deviation — ignored this slice (crates/pverify-core/src/pades/mod.rs, the _ => {} arm and the doc comment). Malformed input is skipped, never fatal (the iter_tlv walker stops at the first malformed length rather than erroring, FR-011).

6.5.5 TSA-chain consumption (each timestamp, at its own VRT)

The second pass apply_pades_vrt applies revocation to each timestamp's TSA chain at that object's own per-object VRT (033 + 034). For each token in entry.timestamps:

• The TSA-chain candidate certificates are recovered from the relevant CMS: for a front signature-TS token, the signer's own CMS certificates; for a tail /DocTimeStamp archive token, that token's own descriptor's CMS certificates (doc_ts_descs).
• The object's DSS/VRI material is resolved via resolve_material keyed by the appropriate /Contents — the signer's /Contents for an embedded signature-TS (the VRI key for embedded sig-TS material), or the /DocTimeStamp's own /Contents for an archive cover.
• The resolved certs supplement the TSA-chain candidates (again, never anchors, Q7).
• crate::verify::apply_tsa_chain_revocation_for_token (the 033 shared helper, verify.rs:1552) is called with the resolved OCSP/CRL DER (previously &[], &[]), at the token's VRT (crates/pverify-core/src/pades/mod.rs, apply_pades_vrt per-token loop).
• tag_document_revocation_provenance then tags the TSA chain's consumed records.

After the per-token loop, apply_tsa_revocation_indication layers the TSA-chain revocation verdict last. This is the consistency the 033 work delivers: a revoked TSA certificate degrades the entry to INDETERMINATE with revoked_no_poe (the "cannot affirm" response — pverify cannot prove the timestamp's time because the TSA's own certificate was revoked), rather than fabricating a forgery claim.

6.5.6 Additive-fallback channel discipline

A critical invariant (FR-004a/Q5/VR-4): the DSS/VRI/revocationInfoArchival material rides the same embedded-CRL/OCSP channels introduced in 019 that fire only when a live fetch / CDP lookup is itself indeterminate. The apply_revocations and apply_tsa_chain_revocation_for_token calls receive the material as the embedded-OCSP / embedded-CRL arguments, and the revocation engine (Chapter 11) consults those channels as a fall-through, not as an override. Consequences:

• A currently-passing online live-fetch verification stays byte-identical — the live OCSP/CRL success is reached first and the embedded material is never consulted.
• An offline verification that previously stalled at revocation_not_checked_offline now reaches a definitive result from the document's own evidence (the headline of the e2e test dss_borne_crl_reaches_definitive_offline_and_is_tagged_pdf_dss, which proves the signer chain good with no network access and tags the consumed CRL pdf_dss).

This is the standing offline-honesty discipline (Constitution §VII): --offline opens no socket, and the honest IndeterminateRevocationOffline is replaced by a definite outcome only when the document carries the evidence to establish it.

6.5.7 Zero new verdict logic

A DSS/VRI-supplied CRL or OCSP response yields an existing RevocationOutcome value — no new outcome, no new sub-indication (Q2/FR-007). Specifically (docs/pades-dss-vri.md):

• A revoked signer certificate ⇒ the existing TOTAL_FAILED (via the existing revocation aggregation).
• A revoked TSA chain ⇒ 033's existing INDETERMINATE / revoked_no_poe.
• No matching CRL/OCSP record ⇒ the outcome stays indeterminate (additive evidence never manufactures a false good, VR-5).

The only additive wire surface is provenance, described next.

6.5.8 Wire-shape changes and schema version

The 034 wire surface is purely additive provenance, mirrored 1:1 into the root report-schema.json:

• Two new ValidationObjectOrigin values, pdf_dss and pdf_vri, appended after the existing five (crates/pverify-core/src/report/validation_objects.rs, enum ValidationObjectOrigin). Declaration order is the sort order for the origin[] array, so existing arrays stay byte-stable. The derivation maps a record's PdfRevocationSource to the origin (validation_objects.rs, the Some(PdfRevocationSource::PdfDss) => ValidationObjectOrigin::PdfDss arms).
• Parallel revocation-source discriminators so a DSS/VRI-supplied embedded CRL/OCSP is distinguishable from a CMS-unsignedAttrs-embedded one: CrlSummary.pdf_source and OcspAttempt.pdf_source, both Option<PdfRevocationSource> (crates/pverify-core/src/report/mod.rs, enum PdfRevocationSource { PdfDss, PdfVri }, and the pdf_source fields). Both omit-when-absent, so a 1.5.0 reader ignores them.

SCHEMA_VERSION bumped 1.5.0 → 1.7.0 when branch 034 landed (crates/pverify-core/src/report/schema.rs). Subsequent slices (035 OCSP nonce, CdpEntry struct) advanced it further to 1.9.0 (the current value). This section documents the 034-specific wire additions; see Chapter 14 for the complete lineage. The schema bump is an additive MINOR change: adding a closed-enum value or an optional field is MINOR; removing or repurposing one is MAJOR (Chapter 14). The schema doc comment is explicit that there is no new revocation outcome, no new ETSI sub-indication, no new top-level field, and that 034 is not a constitutional surface (no policy table; it reuses the revocation vocabulary). An input with no /DSS//VRI/revocationInfoArchival is byte-identical to a 1.5.0 body except the schema_version string.

6.5.9 End-to-end flow

6.6 The RFC 5280 §6.1.5 empty-policy-tree relaxation

A separate, earlier fix (PR #48, commit 0650b2d) was required before real Japanese public PDFs could verify at all, and it lives in the shared path-validation policy processing (crates/pverify-core/src/path/policy.rs, compute_outcome) rather than in the PAdES module — but its motivating use case is PAdES, so it is documented here.

RFC 5280 §6.1.5 governs the leaf wrap-up of certificate-policy processing. The pre-#48 implementation rejected an empty valid_policy_tree unconditionally, which made real GPKI/官報 chains fail: such a leaf carries a policy OID that differs from its issuer's, with no policyMappings, so the valid_policy_tree legitimately empties at the leaf even though the chain is sound. The corrected logic (compute_outcome, the is_leaf block) follows RFC 5280 precisely:

• An empty tree is a rejection only when requireExplicitPolicy fired (modelled as explicit_policy_pending == Some(0)). When requireExplicitPolicy was never asserted, an empty tree under a {anyPolicy} user-initial-policy-set is valid — path processing succeeds when explicit_policy > 0 or the tree is non-NULL.
• When requireExplicitPolicy fired, an empty tree yields Inconclusive { EmptyTree }, and a tree containing only anyPolicy (no specific policy survived) yields Inconclusive { ExplicitPolicyViolated }.
• A non-empty user_initial_policy_set (the CLI's --required-policy) narrows further at the leaf: at least one tree node must carry a specific policy that is in the set, otherwise Inconclusive { EmptyTree }.

The corresponding ETSI surface is IndeterminatePolicyRejected (crates/pverify-core/src/report/etsi.rs) for the requireExplicitPolicy empty-tree and policy-set-intersection-empty cases; the older PolicyProcessingInconclusive tag is retained for stored-report deserialization. The PAdES path threads the same required_policies into validate_path (branch 029, verify_one_signature and revalidate_pades_signer_chain), so PAdES enforces the identical user-initial-policy-set narrowing as CAdES — an empty slice still means {anyPolicy}, preserving compatibility for runs without --required-policy.

6.7 Invariants and failure modes (summary)

Throughout, the PAdES verifier honours the cross-cutting discipline of the system: PDF parsing stays host-side (Constitution §V/§VI); the kernel is I/O-free and WASM-clean; additive material flows only as a fall-through that never overrides a live success (reproducibility / byte-identity); and where a fact cannot be established the verifier degrades to INDETERMINATE with a precise closed-enum sub-indication rather than fabricating a verdict (Constitution §I, "cannot affirm").

6.8 Cross-references

• Chapter 4 — input classification, format dispatch (detect_format), end-to-end data flow.
• Chapter 5 — CAdES, whose CMS/chain/signed-attrs/content-digest/ESS-binding/content-type machinery PAdES reuses.
• Chapter 11 — revocation (CRL/OCSP, embedded-channel fall-through) that the resolved DSS/VRI material feeds.
• Chapter 12 — per-object VRT derivation (recursive-outer-covering), used by apply_pades_vrt.
• Chapter 14 — report schema, schema_version semantics, ValidationObjectOrigin, the derive_validation_objects provenance derivation.

7. XAdES & ASiC Verification

This chapter documents how pverify verifies XML Advanced Electronic Signatures (XAdES, ETSI EN 319 132 / JIS X 14533‑2) and Associated Signature Containers (ASiC, ETSI EN 319 162). Both are delegated formats: the host crates pverify-xades and pverify-asic perform all XML/ZIP parsing and canonicalization and hand the I/O‑free, no_std kernel (pverify-core) model‑free byte structures, which the kernel then runs through the same RFC 5280 path‑validation, RFC 6960/5280 revocation, RFC 3161/5816 timestamp and ETSI EN 319 102‑1 indication machinery used for CAdES (see Chapter 5) and PAdES (see Chapter 6). The architectural boundary and crate topology are described in Chapter 3; this chapter focuses on what is format‑specific to XML signatures and ZIP containers, and is precise about which profiles are verified versus flagged unsupported.

The supported AdES levels are stated up front so they are not buried:

The single non‑negotiable principle throughout is the Constitution §I "cannot affirm" discipline: where pverify cannot establish a fact (an unsupported canonicalization, an unparseable timestamp token, a data object absent from a container) it degrades to INDETERMINATE with a precise closed‑enum sub‑indication, never a fabricated TOTAL_FAILED or TOTAL_PASSED.

7.1 The XAdES integration boundary

The kernel cannot parse XML — that would pull a DOM and canonicalization machinery into the no_std/WASM‑clean core, violating Constitution §V (Library‑First) and §VI (WASM‑clean core). Instead, the host crate pverify-xades (crates/pverify-xades/src/lib.rs) parses the XML, performs Exclusive XML Canonicalization through the audited bergshamra-c14n crate, and emits one model‑free XadesComponents value per ds:Signature element. That boundary type is owned by the kernel (crates/pverify-core/src/xades.rs, XadesComponents) and re‑exported from the host crate, so there is a single source of truth for the shape that crosses into VerificationRequest. Only Vec<u8> and small closed enums cross the boundary — no XML node, no std type. The kernel verifier verify_xades (crates/pverify-core/src/xades.rs) consumes one XadesComponents and produces one SignatureEntry, reusing the existing RFC 5280 / revocation / ETSI pipeline from the point the signer certificate is in hand — deliberately identical to verify_cades (crates/pverify-core/src/verify.rs).

The boundary fields, all already decoded and canonicalized by the host so the kernel never touches XML, are:

The B‑T/B‑LT fields are all additive and were introduced by branch 019; a plain B‑B signature carries no UnsignedSignatureProperties and so leaves them empty, which means a B‑B report is byte‑identical to the pre‑019 output (the reproducibility invariant, Constitution §II). The same byte‑identity discipline governs the kernel's behaviour: the additive embedded‑revocation channels fire only when the live/CDP channel is indeterminate.

7.2 Canonicalization

XML canonicalization is the load‑bearing — and historically the most error‑prone — part of XML signature verification, because the digested and signed bytes are not the literal bytes on disk but a canonical serialization of a node‑set. pverify uses two distinct canonicalization algorithms, each applied to a specific place, both provided by the audited bergshamra-c14n crate (crates/pverify-xades/src/c14n.rs):

1. Exclusive XML Canonicalization (xml-exc-c14n#, W3C). Applied to ds:SignedInfo (the verified message) and to each same‑document ds:Reference subtree. Exclusive C14N prunes inherited namespace declarations that are not visibly used, honouring an InclusiveNamespaces PrefixList when present. The host reads that prefix list from the CanonicalizationMethod/Transform element (inclusive_prefixes, crates/pverify-xades/src/parse.rs) and threads it into exc_c14n_subtree.

2. Plain Canonical XML 1.0 (REC-xml-c14n-20010315, with and without comments). Applied only to the RFC 3161 timestamp message‑imprint computation (§7.5). Unlike exclusive C14N, plain C14N emits every namespace in scope — inherited declarations are not pruned — so it takes no inclusive‑prefix list. This is implemented over bergshamra-c14n's existing C14nMode::Inclusive (the B‑B build already compiles it, so B‑T added no new dependency — crates/pverify-xades/src/c14n.rs::plain_c14n_subtree).

The "plain C14N for the timestamp imprint, Exclusive C14N for ds:SignedInfo" split is not an arbitrary choice; it was confirmed byte‑exact against the real EU DSS XAdES corpus (the 019 research note records that a SignatureTimeStamp declares plain C14N 1.0 for the data it imprints even when ds:SignedInfo itself uses Exclusive C14N). Both canonicalization surfaces are regression‑locked byte‑for‑byte against a libxml2 golden oracle (crates/pverify-xades/tests/exc_c14n_golden.rs and tests/plain_c14n_golden.rs), so any drift in the canonicalizer is caught deterministically rather than discovered as a verification mismatch in the field.

The enveloped‑signature transform (W3C XML‑DSIG §6.6.4) is the third canonicalization‑adjacent operation: a reference with URI="" plus the #enveloped-signature transform digests the whole document minus the ds:Signature subtree. The host computes this by taking the full‑document node‑set, subtracting the signature subtree, then applying exclusive C14N (exc_c14n_enveloped, crates/pverify-xades/src/c14n.rs). The presence of exactly this URI="" + enveloped‑transform reference is what classifies the signature as the supported enveloped profile (§7.4).

7.3 XAdES B‑B verification

verify_xades (crates/pverify-core/src/xades.rs) executes a fixed, fact‑ordered sequence; each failure maps to a specific outcome. The order is deliberate so a definitive forgery is detected before, and is never masked by, a weaker indeterminate condition.

Step 1 — profile and algorithm gating. If the host classified the profile as Unsupported, the kernel immediately returns INDETERMINATE with either xades_unsupported_profile (detached/enveloping packaging) or xades_unsupported_canonicalization (non‑Exclusive C14N). An Unsupported SignatureMethod URI returns INDETERMINATE signature_algorithm_unsupported. These are cannot‑affirm outcomes: pverify recognises the shape but declines to verify what it does not implement, rather than guessing.

Step 2 — signer certificate presence. signer_cert_der == None → INDETERMINATE xades_signer_certificate_unavailable. The same outcome covers a certificate that fails DER parse or whose SubjectPublicKeyInfo cannot be re‑encoded (extract_spki_der).

Step 3 — reference digests. For every ds:Reference, the kernel recomputes digest_alg(transformed_c14n) and compares it to the stored expected_digest. Any mismatch is TOTAL_FAILED xades_reference_digest_mismatch — positive evidence that the signed content was altered. This is checked before the signature value, because a reference mismatch is a content‑integrity failure independent of the signature‑value cryptography.

Step 4 — signature value over SignedInfo. The kernel verifies signature_value over signed_info_c14n using the SubjectPublicKeyInfo from the signer certificate. RSA‑PSS is dispatched directly with the salt length the host resolved (verify_rsa_pss); RSA PKCS#1 v1.5 and ECDSA reach the shared OID‑driven verify_with_alg (the host has already converted ECDSA r‖s to DER, so the existing verifier is unchanged). A genuine verification failure is TOTAL_FAILED signed_attrs_signature_failed (reusing the CMS class — the XML signature value is the analogue of the CMS signer signature); an unsupported algorithm surfaced at this point degrades to INDETERMINATE signature_algorithm_unsupported, preserving the fact‑reporting distinction between "wrong" and "cannot evaluate".

Step 5 — SigningCertificateV2 binding. When the signature carries an XAdES SigningCertificateV2, the kernel recomputes the digest of the signer certificate DER under the declared DigestMethod and compares it to the stored CertDigest. A mismatch is TOTAL_FAILED xades_signing_certificate_mismatch — the certificate‑substitution defence (an attacker swapping the embedded certificate for one whose key also verifies a re‑signed SignedInfo is caught here). The binding is digest‑based; the IssuerSerialV2 is recorded but not used as the discriminator.

Step 6 — path validation, revocation, ETSI. From here the flow is identical to verify_cades: validate_path (RFC 5280 §6 chain construction at the verification time), wire_chain_step_signatures (RustCrypto certificate‑signature verification), apply_revocations for the signer chain, and ETSI aggregation via aggregate_etsi. The embedded B‑LT certificates are made available as chain material, and the embedded OCSP/CRL DER is fed through the existing embedded‑material channel so an offline‑definitive signer‑revocation verdict is reachable.

On success the report records the bytes the XAdES signature commits to: the signed_content validation object's digest is set to the SHA‑256 of the exclusive‑C14N ds:SignedInfo (covered_content_sha256). The CMS‑shaped signed_attrs and content_digest blocks are recorded as not‑applicable facts (XAdES has no CMS messageDigest), so a consumer reading the report sees an honest "not applicable" rather than a fabricated match.

Weak‑algorithm handling. SHA‑1 in either the SignatureMethod or any reference's DigestMethod is recognised‑and‑flagged, never rejected — matching the CAdES/PAdES posture and Constitution §I. The kernel verifies the signature normally and records a WeakAlgorithmFlag against the signer step (via flag_if_weak), which the host's aggregate_for_header then surfaces in the report header. This is distinct from the opt‑in algorithm‑policy verdict (§7.6), which is a separate, time‑scoped evaluation.

7.3.1 Algorithm mapping

The host resolves XML algorithm URIs to model‑free descriptors in crates/pverify-xades/src/algid.rs. The supported SignatureMethod family is:

DigestMethod URIs map to SHA‑1/256/384/512; an unrecognised digest URI is unsupported. SHA‑1 is a valid recognised digest (verified then flagged weak), not an unsupported value — the fact‑reporting principle again.

7.4 Profile classification (enveloped vs detached)

Stand‑alone XAdES support is deliberately scoped to the enveloped profile with Exclusive canonicalization — the shape used by e‑Gov public‑document XML signatures (官職署名), the Ministry of Justice's electronic articles of incorporation (電子定款), and the EU LOTL/Trusted Lists. The host decides the profile in process_reference / extract_one (crates/pverify-xades/src/parse.rs) with this precedence:

1. If the CanonicalizationMethod is not Exclusive C14N → Unsupported{NonExclusiveC14n}.
2. Else if a resolver was supplied (the ASiC case, §7.7) and a non‑fragment ds:Reference URI was resolved to a ZIP entry → DetachedResolved.
3. Else if no URI="" + enveloped‑signature reference is present → Unsupported{DetachedOrEnveloping}.
4. Else → EnvelopedBB.

The DetachedResolved lift is narrow: it lifts the detached gate only when the ASiC extractor has already resolved the reference URIs to concrete bytes. Stand‑alone detached/enveloping XAdES still maps to Unsupported, so the enveloped path (011/019) is byte‑identical regardless of whether the ASiC code is present. This is how pverify reuses the XAdES reference‑digest machinery for ASiC‑E XAdES without introducing a separate detached verifier (§7.7).

7.5 XAdES B‑T and B‑LT timestamps

Branch 019 added B‑T and B‑LT support. The B‑T timestamps in scope are the SignatureTimeStamp and the SigAndRefsTimeStamp; both are RFC 3161 tokens verified through the shared crate::timestamp::verify_timestamp_token. The host canonicalizes the imprinted data (so the kernel receives only raw imprint bytes, §V) and the kernel computes and compares the imprint exactly as CAdES does for its signature‑time‑stamp.

SignatureTimeStamp. The imprint commits to the plain‑C14N canonical ds:SignatureValue (R‑1, byte‑confirmed against the DSS corpus). The host canonicalizes ds:SignatureValue with plain C14N 1.0 and stores it as the imprint_input; the kernel verifies the RFC 3161 token and the imprint.

SigAndRefsTimeStamp. This is the hardest computation in the slice. Per ETSI TS 101 903 §7.5.1 type‑1 coverage, the imprint is over the ordered concatenation, each subtree plain‑C14N‑canonicalized, of ds:SignatureValue followed by every SignatureTimeStamp, CompleteCertificateRefs, CompleteRevocationRefs and (when present) AttributeCertificateRefs / AttributeRevocationRefs, walked in document order under UnsignedSignatureProperties up to (not including) the timestamp itself (build_sig_and_refs_imprint, crates/pverify-xades/src/parse.rs). The reconstruction is the highest‑risk byte‑exact operation in the format; the design is explicitly honest‑indeterminate: if the reconstructed concatenation does not reproduce the imprint, the kernel records message_imprint_match = false and surfaces it rather than fabricating a match. Against the chosen DSS fixture the type‑1 imprint does reconstruct, yielding a genuine TOTAL_PASSED rather than a degrade.

Imprint‑mismatch verdict. When an in‑scope timestamp's imprint does not match (or could not be verified — for example because the timestamp declared an unsupported canonicalization, canonicalization_supported = false) and the rest of the signature is otherwise valid (the base aggregation returned TOTAL_PASSED), the kernel downgrades to INDETERMINATE xades_timestamp_imprint_mismatch: the signature is not forged, but its claimed time cannot be confirmed (ETSI EN 319 102‑1). A genuine TOTAL_FAILED signer/reference failure keeps precedence — the downgrade only touches a passing verdict, never masking proven failure.

B‑LT embedded material. CertificateValues/EncapsulatedX509Certificate become chain material; RevocationValues/CRLValues/EncapsulatedCRLValue and OCSPValues/EncapsulatedOCSPValue feed the existing embedded‑CRL/OCSP channels. One format‑specific subtlety: XAdES EncapsulatedOCSPValue carries a full RFC 6960 OCSPResponse (responseStatus + responseBytes wrapper), whereas the kernel (like CAdES revocation-values.ocspVals) consumes a bare BasicOCSPResponse. The host therefore unwraps the OCSPResponse to its inner BasicOCSPResponse with a minimal hand‑rolled DER walk (unwrap_ocsp_response, crates/pverify-xades/src/parse.rs) before threading it in; a structure that does not match is returned unchanged so the kernel evaluates or rejects it as a fact, never panics. The presence of any B‑LT payload promotes the reported format to XAdES-B-LT; a verified signature timestamp without LT payload is XAdES-B-T; neither is XAdES-B-B.

Per‑object VRT. As with every format, each object (signer chain, signer signature, each signature timestamp) is judged at its own Validation Reference Time derived by the recursive‑outer‑covering engine (crate::vrt::derive_vrt, see Chapter 12). When a signature timestamp's GenTime promotes the signer chain's VRT past the request time, the kernel re‑validates the chain at that promoted time (crates/pverify-core/src/xades.rs), so a signer certificate that expired after signing but was timestamped while valid still verifies — the headline B‑LT payoff. TSA‑chain revocation is applied per timestamp at each timestamp's own VRT through the shared apply_tsa_chain_revocation_for_token helper (branch 033), bringing XAdES to parity with CAdES/PAdES on TSA revocation consistency.

7.5.1 XAdES B‑LTA: ArchiveTimeStamp imprint verification (branch 036)

Branch 036-xades-blta implements ArchiveTimeStamp imprint recomputation for XAdES B‑LTA, closing the gap noted by §I for this tier (ETSI TS 101 903 v1.4.2 Annex A.1.5).

SignatureFormat::XadesBLta ("XAdES-B-LTA") is promoted when at least one ArchiveTimeStamp is present in UnsignedSignatureProperties. Like the B‑T/B‑LT levels, the promotion is a recognised structural fact, not a claimed profile.

Imprint construction. The imprint input is the Exclusive‑C14N (bergshamra-c14n) serialization of the entire ds:Signature element, with the node‑set of subsequent ArchiveTimeStamp elements (those at index k and later, where the current token is at index k-1) subtracted before C14N. This is the "circular exclusion" discipline: each ATS commits to every prior ATS plus the signature body, forming a forward hash chain, while the token being recomputed is excluded so its own imprint can be independently verified. The pre‑computed bytes are stored as XadesUnverifiedTimestamp.imprint_input: Vec<u8> by the host (pverify-xades); the kernel (verify_xades) never touches XML and simply calls verify_timestamp_token with those bytes.

Shared LTA infrastructure. LongTermArchivalIndication and ArchiveTimestampImprintRecord are shared with the CAdES B‑LTA path (Chapter 5) and require no new types. A verified XAdES archive timestamp populates embedded_validation_data.long_term_archival_indication (previously no_archive_timestamp for XAdES regardless of LT payload — that default is superseded by a real LongTermArchivalIndication when the imprint verifies).

Scope and limitations. The current implementation covers:

• A single-chain ArchiveTimeStamp or a short ordered sequence where each token's node‑set is well‑defined.
• The ArchiveTimeStamp form in ETSI TS 101 903, not ArchiveTimeStampV3.

Out of scope:

• Multiple ArchiveTimeStamp chains (loop processing for long ATS chains is a future slice).
• ArchiveTimeStamp tokens that declare an XPath transform: those cannot be recomputed without an XPath evaluator in the host. They are surfaced in unverified_timestamps with an empty imprint_input and do not downgrade the verdict (cannot‑affirm). This is why the DSS XAdES‑LTA interop fixtures, which use XPath transforms, are excluded from expectations.json.
• JAdES arcTst (a separate format, out of scope for this slice).

RefsOnlyTimeStamp remains surfaced present‑but‑unverified (no imprint recomputed) as before.

7.6 Algorithm‑policy evaluation for XAdES

When the opt‑in algorithm policy is active (--algorithm-policy, off by default), evaluate_xades_algorithm_validity (crates/pverify-core/src/xades.rs) assembles a per‑object inventory and evaluates each object's digest / signature family / key length against the policy as of that object's VRT (read verbatim from the 031 vrt block, never recomputed). The signer‑signature family and digest come from the SignatureMethod descriptor and the key length from the signer SPKI; the signer‑chain object uses the leaf certificate's own signatureAlgorithm; each signature timestamp is judged on its imprint digest. The result is layered onto the indication via apply_algorithm_validity_indication, which mirrors the ETSI CRYPTO_CONSTRAINTS_FAILURE_NO_POE posture and never produces TOTAL_FAILED and never masks one. With the policy off, the field is None and the report is byte‑identical to a non‑policy run (Constitution §II). See Chapter 13 for the algorithm‑policy engine itself.

7.7 ASiC container structure

ASiC (ETSI EN 319 162) is a ZIP archive that binds one or more data objects to one or more detached AdES signatures, plus a mimetype entry identifying the container profile. pverify supports ASiC‑S (single data object) and ASiC‑E (multiple data objects, manifest‑described) and verifies the inner signatures by delegating each to the existing detached CAdES or detached XAdES pipeline — the only genuinely new cryptographic decision being the ASiC‑E CAdES manifest digest chain (§7.9).

As with XAdES, the kernel cannot parse ZIP/DEFLATE — that would pull zip + flate2 + miniz_oxide into the core graph (gate‑forbidden by scripts/cargo-tree-gate.sh). The host crate pverify-asic (crates/pverify-asic/src/lib.rs) reads the container in memory, discovers the META-INF/ signature material and data objects, parses the ASiCManifest, resolves ZIP‑relative ds:Reference URIs for detached XAdES, and emits one model‑free AsicSignature per signature (the boundary type owned by crates/pverify-core/src/asic.rs). The host threads these into VerificationRequest.asic_signatures; the kernel verifier verify_asic_signature (crates/pverify-core/src/asic.rs) maps each through the reuse path its AsicPayload variant selects.

Dispatch precedence. A ZIP container begins with the local‑file‑header magic PK\x03\x04, which the byte sniff would otherwise route to CAdES. So verify_with (crates/pverify-core/src/verify.rs) checks request.asic_signatures before the format sniff: if the host extracted any ASiC signatures they take precedence and each is verified independently (one signatures[] entry per signature, so one failure never suppresses others). A ZIP‑magic input for which the host produced no ASiC signatures — a ZIP that is not a recognisable ASiC container — is reported as INDETERMINATE asic_unsupported_container (asic_unsupported_entry), never allowed to fall through to the CAdES sniff and be misclassified.

The ZIP reader (crates/pverify-asic/src/zip.rs) wraps the pure‑Rust zip crate and adds the security envelope ASiC needs: a cap of 4096 entries, a 256 MiB total‑decompressed budget and a 128 MiB per‑entry cap (zip‑bomb refusal, returning an explicit ResourceBoundExceeded rather than silently truncating), and path‑traversal rejection (enclosed_name() == None, plus a defence‑in‑depth check for .. components and absolute paths). Everything is read into memory — no temp files.

7.8 ASiC profile detection and conformance deviations

detect (crates/pverify-asic/src/detect.rs) determines the profile best‑effort and records every packaging deviation rather than silently tolerating it — the §I honesty principle applied to container conformance, and matched to what real DSS output emits. A conformant mimetype authoritatively fixes the profile:

ETSI EN 319 162 requires the mimetype to be the first ZIP entry and STORED (uncompressed). pverify checks both and surfaces mimetype_not_first_entry and mimetype_compressed as deviations (AsicDeviation, crates/pverify-core/src/report/mod.rs) — but still verifies the container. The deviation set is attached to every SignatureEntry from the container (asic_conformance_deviations), so an auditor sees exactly which ETSI packaging rules the container broke without the verdict being suppressed.

When the mimetype is absent or non‑conformant, infer_profile derives the profile from the META-INF/ layout: any ASiCManifest*.xml ⇒ ASiC‑E; a single META-INF/signature.p7s (no numeric suffix) ⇒ ASiC‑S, a numeric suffix or more than one signature ⇒ ASiC‑E; analogously for signatures.xml vs signaturesNNN.xml. Recognition requires some signature material — a ZIP with neither a recognisable META-INF/signature*.{p7s,xml} nor a conformant mimetype is not ASiC (detect returns None), and a conformant mimetype alone is insufficient (there must be something to verify). Signature‑file name matching is case‑sensitive per the standard (is_cades_signature, is_xades_signature, is_asic_manifest). The ASiCArchiveManifest (LTA, out of scope) and the OpenDocument informational manifest.xml are deliberately excluded from manifest recognition.

A container may carry both families (mixed signature*.p7s and signatures*.xml). extract processes both families present so no signature is silently dropped (crates/pverify-asic/src/lib.rs); the Detection.family field is diagnostic only and is not used to dispatch.

7.9 ASiC payload verification

Each AsicSignature carries an AsicPayload that selects the reuse path (crates/pverify-core/src/asic.rs::verify_asic_signature):

CadesDirect (ASiC‑S CAdES). The detached CAdES messageDigest covers the single data object's raw bytes directly (no manifest). The kernel calls verify_cades_detached with data_object.bytes as the detached content — the entire CAdES path (chain build, content‑digest, revocation, timestamps, ETSI) is reused verbatim. The single data object is the sole entry that is neither mimetype nor under META-INF/ (sole_data_object).

CadesManifest (ASiC‑E CAdES) — the two‑step digest chain. This is the only new verification logic in the ASiC slice (R‑1):

1. Step 1 — the CAdES signs the ASiCManifest XML bytes verbatim. The kernel calls verify_cades_detached with manifest_bytes as the detached content.
2. Step 2 — each <asic:DataObjectReference> declares a DigestMethod and DigestValue. The host resolves each reference URI to the actual ZIP entry bytes (resolve_entry, tolerating a leading ./ and percent‑escapes DSS emits); the kernel recomputes digest_alg(actual_bytes) and compares it to the manifest's declared digest (apply_manifest_digest_chain, crates/pverify-core/src/asic.rs). This recomputation lives in the kernel so the integrity decision is part of the reproducible report.

Each recomputation is recorded in asic_manifest_checks (the §III audit trail: URI, declared digest OID, match boolean). The verdict logic then enforces:

A digest mismatch (positive evidence of tamper) outranks a missing object (which only means the content cannot be evaluated): a mismatch is TOTAL_FAILED, a mere absence is INDETERMINATE — the cannot‑affirm distinction between proof of alteration and inability to check. Crucially, a data‑object digest mismatch is reported as a failure even when the CAdES signature over the manifest verified perfectly, because the manifest binds the signature to content whose actual bytes no longer match — the integrity chain is broken at step 2.

Xades (ASiC‑S/E XAdES). The host (extract_xades, crates/pverify-asic/src/lib.rs) parses each META-INF/signatures*.xml through pverify_xades::extract_detached, supplying a resolver that maps each ZIP‑relative ds:Reference URI to the named entry's bytes. The resulting XadesComponents carry the DetachedResolved profile (§7.4), and the kernel calls verify_xades unchanged. The reference‑digest check (§7.3 step 3) then verifies each resolved data object's bytes against its stored DigestValue; an unresolvable URI leaves the reference bytes empty so that check fails honestly, never silently passing. This is how ASiC‑E XAdES — the default DSS ASiC‑E output — is verified by reusing the exact same reference‑digest machinery as enveloped XAdES, with only the detached gate narrowly lifted.

Every entry gets its container field set (ASiC-S / ASiC-E) and the conformance deviations attached, regardless of which payload path produced it.

7.10 Outcome vocabulary and invariants

The XAdES/ASiC paths add no new top‑level Indication; they reuse TOTAL_PASSED / INDETERMINATE / TOTAL_FAILED and contribute the following closed SubIndication values (crates/pverify-core/src/report/etsi.rs, mirrored 1:1 into the root report-schema.json):

The format‑specific invariants a reviewer should hold the implementation to:

• No XML/ZIP in the kernel. pverify-xades and pverify-asic are WASM‑clean extraction crates carrying no cryptography (only parse, canonicalize, byte‑extract); they are gate‑asserted out of the pverify-core runtime graph. The kernel sees only Vec<u8> and closed enums.
• CLI↔︎WASM parity. The browser host (web/pverify-wasm/src/lib.rs) runs the byte‑identical pverify_xades::extract / pverify_asic::extract and the identical verify_with kernel, producing byte‑identical reports for identical inputs.
• Byte‑identity on absent features. A B‑B XAdES signature (no UnsignedSignatureProperties) and an algorithm‑policy‑off run leave the report byte‑identical to pre‑slice output but for the schema_version string; the embedded‑revocation channels fire only when the live/CDP channel is indeterminate.
• Cannot affirm. Unsupported canonicalization, an unparseable or unsupported‑C14N timestamp, an out‑of‑scope archive timestamp, and a missing ASiC data object all degrade to INDETERMINATE with a precise sub‑indication — never a fabricated pass or fail.
• Never‑mask. A digest mismatch (XAdES reference or ASiC data object) and a signing‑certificate mismatch are TOTAL_FAILED and are never overridden by a weaker timestamp or revocation indication; the timestamp‑imprint downgrade and the manifest‑digest enforcement explicitly only touch a non‑failed base.

The report shape version is SCHEMA_VERSION = "1.10.0" (crates/pverify-core/src/report/schema.rs); the XAdES/ASiC sub‑indications and the ContainerFormat / AsicDeviation / AsicManifestCheck types are additive closed enums/structs (adding a value is a MINOR bump). Branch 036 added SignatureFormat::XadesBLta ("XAdES-B-LTA") and the imprint_input field on XadesUnverifiedTimestamp — both additive, backward‑compatible, MINOR additions that do not affect the schema_version. For the shared path, revocation, timestamp and VRT engines these paths reuse, see Chapters 9, 11 and 12.

8. JAdES Verification

JAdES (JSON Advanced Electronic Signatures, ETSI TS 119 182-1) is the fourth member of the ETSI AdES family that pverify verifies, alongside CAdES (EN 319 122), PAdES (EN 319 142) and XAdES (EN 319 132). Where the other three families build on CMS, PDF and XML respectively, JAdES builds on the JSON Web Signature (JWS) structure of RFC 7515, with the unencoded-payload extension of RFC 7797. This chapter documents what pverify actually verifies in the JAdES path — the JAdES baseline-basic (JAdES-B-B) level over the JWS JSON Serialization — the boundary between the host-side JSON extractor and the no_std verification kernel, and the precise set of shapes pverify deliberately refuses as INDETERMINATE rather than overclaiming conformance.

The implementation lives in two places, matching the architecture-wide host/kernel split described in Chapter 3: the host extraction crate pverify-jades (crates/pverify-jades/), which performs the JSON parse and all byte extraction, and the kernel orchestrator crates/pverify-core/src/jades.rs, which owns the model-free boundary type and runs the cryptographic verification and the shared RFC 5280 path / revocation / ETSI pipeline. The slice that introduced this support is specs/027-jades-bb-verify/.

8.1 Scope: what is verified and what is refused

The discipline of this path is that pverify reports the honest outcome for the material actually supplied and never adjusts its verdict to match another implementation. Two facts are kept strictly separate (specs/027-jades-bb-verify/spec.md, Clarification Q3):

1. The cryptographic fact: does the JWS signature verify over the reconstructed JWS Signing Input, using the signer certificate's public key?
2. The AdES-level claim: is the input a JAdES-B-B signature — that is, does it carry the JAdES baseline signed properties on top of a plain JWS?

A well-formed JWS that lacks the JAdES baseline properties is still cryptographically meaningful, but pverify will not label it JAdES-B-B; it is reported as detected-but-not-baseline and yields INDETERMINATE for the AdES-level claim. This avoids overclaiming JAdES conformance for a bare JWS.

The supported and refused shapes are summarised below. "Refused" always means a precise INDETERMINATE sub-indication, never a fabricated pass or failure (Constitution §I, "cannot affirm").

The closed SubIndication enum (crates/pverify-core/src/report/etsi.rs) carries five JAdES-specific values, mirrored 1:1 into the root report schema: jades_payload_digest_mismatch, jades_signing_certificate_mismatch, jades_unsupported_profile, jades_unsupported_serialization, jades_signer_certificate_unavailable. The SignatureFormat enum (crates/pverify-core/src/report/mod.rs) adds JAdES-B-B (a positively-verified baseline signature) and JAdES-unsupported (the retained label for refused shapes). These were additive, backward-compatible growth: slice 027 only appended values to existing closed enums, with no change to the report's top-level shape. The schema_version carried by the report is independent of this chapter's content and has since advanced to 1.10.0 through later slices (033 TSA revocation, 034 PAdES DSS/VRI, 035 OCSP nonce + CdpEntry, 037 JAdES B-T/B-LT/B-LTA — which bumped 1.9.0 → 1.10.0 by appending three new SignatureFormat variants: JAdES-B-T, JAdES-B-LT, JAdES-B-LTA); this chapter does not assert any specific bump for 027.

8.2 Format dispatch and content sniff

The kernel orchestrator verify_with (crates/pverify-core/src/verify.rs) routes by content sniff in detect_format: %PDF- → PAdES, an XML-leading input → XAdES, a JSON-leading input → JAdES, otherwise CAdES (ASiC is handled earlier when asic_signatures is non-empty). The JSON sniff is looks_like_json (verify.rs:375): it skips an optional UTF-8 BOM, then skips ASCII whitespace, and accepts only if the first non-whitespace byte is {. A top-level array ([) is explicitly not a JWS JSON Serialization document and is rejected by the sniff. Because JSON ({) and XML (<) are mutually exclusive on the first non-whitespace byte, the XAdES and JAdES sniffs never collide (verify.rs:354-369, research R-8).

The host (pverify-cli/src/main.rs::looks_like_json and web/pverify-wasm/src/lib.rs) mirrors this sniff byte-for-byte so that the CLI and the in-browser WASM build only invoke the JAdES extractor on JSON-leading payloads — one instance of the CLI↔︎WASM parity invariant. On the native CLI:

let jades_components = if looks_like_json(&signature_bytes) {
    pverify_jades::extract(&signature_bytes).unwrap_or_default()
} else { Vec::new() };

A hard extraction error is swallowed to an empty Vec here, but this is not a silent pass: in verify_with an empty jades_components for a JSON-sniffed input falls back to crate::jades::jades_unsupported_entry, which emits JAdES-unsupported / jades_unsupported_profile / INDETERMINATE (verify.rs:303-306). The consumer therefore always receives a definite fact.

8.3 The extraction boundary: JadesComponents

Per the architecture-wide rule that no JSON/XML/PDF parser ever links into pverify-core (Constitution §V), all JSON parsing happens host-side in pverify-jades and only model-free bytes cross into the kernel. The boundary type JadesComponents is declared in crates/pverify-core/src/jades.rs (so the no_std side owns its shape) and re-exported by pverify-jades (crates/pverify-jades/src/lib.rs). One value is produced per JWS signature in the document — N for general serialization, 1 for flattened.

The host threads the extracted Vec<JadesComponents> into the additive VerificationRequest.jades_components field (verify.rs:110); a non-JAdES input leaves it empty, preserving the byte-identity invariant for every other format. The extractor itself performs no cryptography — only JSON parse plus byte extraction (crates/pverify-jades/src/lib.rs).

8.4 JWS Signing Input reconstruction (RFC 7515 / RFC 7797)

The signing input is the byte string the JWS signature is computed over. The host builds it in crates/pverify-jades/src/signing_input.rs::build:

signing_input = ASCII(BASE64URL(UTF8(protected_header))) || '.' || payload_segment

A load-bearing subtlety: the host uses the protected member's base64url string verbatim from the document — it does not re-encode the decoded header. Re-encoding could drift from what the producer signed when JSON is re-emitted with different whitespace, which would corrupt the signing input. The decoded header is used only to read its members (alg, b64, x5c, x5t#S256, profile keys); the byte string fed to the signature check is the raw transmitted form.

The payload_segment depends on the RFC 7797 b64 protected-header flag (signing_input.rs::build, parse.rs:123):

• b64 absent or true (the RFC 7515 default): the document's payload member is itself BASE64URL(payload_bytes), and that ASCII string is appended as-is.
• b64:false (RFC 7797 unencoded payload): the raw payload bytes are appended directly, with no second base64url step.

In the current implementation both branches append payload_str.as_bytes() (the b64:false branch interprets the document's payload member as the raw payload bytes carried as a UTF-8 string). The slice deliberately supports both because real JAdES output — including the ETSI DSS reference vectors — routinely sets b64:false (Clarification Q1). The extractor records the producer-declared b64 value honestly even when it is not also listed in crit (a producer protocol error per RFC 7797 §6); it still builds the signing input the way the producer signed it, and the kernel's signature check then reports the truth. The construction is exercised against the RFC 7515 §A.1 and RFC 7797 §4.2 canonical vectors in signing_input.rs unit tests.

8.5 Signer certificate and signing-certificate binding

The signer certificate is resolved host-side in crates/pverify-jades/src/parse.rs::resolve_x5c. The x5c header is preferred from the protected header, falling back to the unprotected header. Per RFC 7515 §4.1.6, each x5c element is standard base64 (with padding) DER — note the deliberate contrast with the base64url used everywhere else in JWS; the parser uses the STANDARD engine for x5c and URL_SAFE_NO_PAD for protected/signature/x5t#S256. x5c[0] becomes signer_cert_der; the remainder become extra_certs_der path candidates, mirroring how embedded XAdES certificates flow. If no x5c is present the result is (None, []), and the kernel surfaces jades_signer_certificate_unavailable (INDETERMINATE). The MVP does not perform a host-side x5t#S256 certificate-store lookup, so an x5t-only document with no x5c is unavailable, not resolved (parse.rs comment, R-3).

The signing-certificate binding is the certificate-substitution defence. The host extracts the JOSE x5t#S256 thumbprint (RFC 7515 §4.1.8 — a fixed SHA-256 digest of the signer cert, base64url-decoded) into JadesSigningCertBinding { cert_digest, digest_alg: Sha256 } (parse.rs:147-158). The JAdES x5t#o signed property is out of MVP scope. The kernel verifies the binding in verify_jades step 5 (jades.rs:262-271): it recomputes compute_digest(SHA-256, signer_der) and compares against the claimed digest; a mismatch is TOTAL_FAILED / jades_signing_certificate_mismatch. This mirrors the XAdES xades_signing_certificate_mismatch behaviour and is the JSON analogue of the ESS signing-certificate binding for CAdES (see Chapter 5).

8.6 Algorithm mapping (alg → verifiable family)

The host maps the JWS alg protected-header string to a JadesSigAlg in crates/pverify-jades/src/algid.rs::map_alg. The mapping introduces no new cryptographic primitive — every supported alg resolves to a family pverify-core::crypto already verifies (research R-7 / FR-004):

none is refused — never a pass (RFC 7518 §3.6; algid.rs unit test refuses_alg_none). An Unsupported alg reaches the kernel and surfaces as INDETERMINATE / signature_algorithm_unsupported, with the locus naming the alg (alg:ES512), so the failing input is auditable.

For ECDSA, the JWS signature is the fixed-width concatenation r‖s (RFC 7518 §3.4), whereas RustCrypto's verifier expects a DER Ecdsa-Sig-Value SEQUENCE { r INTEGER, s INTEGER }. The host converts it in parse.rs::ecdsa_rs_to_der (mirroring pverify-xades), correctly handling minimal-integer encoding and the leading-zero pad when the high bit is set. An odd-length (malformed) r‖s is passed through unchanged so the kernel rejects it as a fact rather than panicking.

8.7 Profile classification

The host classifies the profile in parse.rs::classify_profile, deciding between the supported EnvelopedBB and the four JadesUnsupportedReason discriminants. The order of tests is significant:

• sigD wins first: a JAdES detached payload reference is out of scope (FR-008). It is later mapped to jades_unsupported_serialization.
• ETSI B-T/B-LT/B-LTA (branch 037): the presence of sigTst (B-T), xVals/rVals (B-LT), or arcTst/atsHashIndex (B-LTA) no longer marks the input HigherLevel. Branch 037 routes these to the ETSI verification path — see §8.13 for details.
• Only rfsTst/tstVd remain unsupported: these mark the input HigherLevel → jades_unsupported_profile.
• B-B minimum: EnvelopedBB requires both a sigT signing-time header and a signing-certificate binding (Clarification Q3). The JOSE x5t#S256 thumbprint counts as the binding. A well-formed JWS that satisfies neither is NotJadesBaseline → jades_unsupported_profile — verified cryptographically if asked, but never labelled JAdES.

The kernel maps these reasons to sub-indications in verify_jades step 1 (jades.rs:164-180): NotJadesBaseline → JadesUnsupportedProfile; DetachedSigD and CompactSerialization → JadesUnsupportedSerialization. HigherLevel now fires only for rfsTst/tstVd → JadesUnsupportedProfile. CompactSerialization is a reserved variant — a JWS Compact string is never JSON-object-rooted, so it never reaches the JSON-only extractor; the host's JSON sniff would not route it here.

8.8 Kernel verification: verify_jades

crate::jades::verify_jades (crates/pverify-core/src/jades.rs:154) consumes one JadesComponents and produces one SignatureEntry. It is structurally identical to verify_xades: it performs the JAdES-specific gates, then hands the resolved signer certificate to the same RFC 5280 path / revocation / ETSI aggregation pipeline every other format uses. The ordered steps are:

Step 4 — signature verification. RSA-PSS dispatches directly to crate::crypto::verify_rsa_pss with the explicit digest and salt length; everything else resolves a signatureAlgorithm OID via jades_sig_alg_oid and calls verify_with_alg (jades.rs:228-242). The SPKI is re-extracted from the signer cert DER via extract_spki_der. If the verifier returns an UnsupportedSignatureAlgorithm error, the result is INDETERMINATE / signature_algorithm_unsupported; any other error (the genuine signature mismatch) is TOTAL_FAILED / jades_payload_digest_mismatch. This sub-indication is the JSON analogue of XAdES's xades_reference_digest_mismatch; note that for JAdES it covers both a tampered payload (which changes the signing input) and a tampered signature value, since both manifest as a signature-verification failure over the signing input (e2e tests tampered_payload_… and tampered_signature_…, both → jades_payload_digest_mismatch).

Step 6 — shared pipeline. The signer certificate and the extra_certs_der path candidates are handed to validate_path (RFC 5280 §6 basic-plus chain construction — see Chapter 9), then wire_chain_step_signatures verifies each chain step's certificate signature with RustCrypto primitives, then apply_revocations evaluates revocation for the signer chain. Crucially, apply_revocations is called with empty embedded-CRL and embedded-OCSP slices (&[], &[], jades.rs:295-305): JAdES-B-B carries no embedded validation material, so revocation is driven purely by the live/CDP channel under the active Mode. In --offline mode with no cached material this honestly degrades to IndeterminateRevocationOffline / revocation_not_checked_offline (INDETERMINATE), never a fabricated responder contact (Constitution §VII).

The SignedAttrsCheck is reported as a synthetic "verified" record (jades_signed_attrs_ok, jades.rs:575) — JWS has no CMS signedAttrs as such; the signature over the signing input is the integrity binding, and it has already been checked in step 4. The ContentDigestCheck records the SHA-256 of the signing input as covered_content_sha256 so the 016 validation_objects[] material inventory can surface the signed material (jades.rs:312-313), mirroring XAdES.

8.9 ETSI indication aggregation and per-object VRT

The base ETSI indication is folded by the shared aggregate_etsi (jades.rs:315) over the chain outcome, the (verified) signed-attrs record and the content-digest record, with severity ordering TOTAL_FAILED > INDETERMINATE > TOTAL_PASSED, first-finding-wins. A healthy chain to a supplied anchor with no revocation problem in the supplied material yields TOTAL_PASSED (e2e rs256_enveloping_total_passed, es256_enveloping_total_passed). A revoked or path-broken chain yields the corresponding INDETERMINATE/TOTAL_FAILED exactly as for CAdES — the JAdES path introduces no new chain-level verdict logic.

JAdES-B-B carries no covering timestamps (etsiU is empty in this slice), so the per-object Validation Reference Time block is the honest degenerate case. verify_jades still calls the shared crate::vrt::derive_vrt with empty timestamp slices and CoveringSource::Jades (jades.rs:332-339); the engine returns a Vrt block whose signer_chain and signer_signature both have derivation == request_at and value == verification_time (FR-005 / FR-011a). In branch 037, the sigTst (B-T) and arcTst (B-LTA) tokens thread through the shared recursive-outer-covering engine with no wire-shape change. The arcTst hash input is non-circular: BASE64URL(protected).BASE64URL(payload).BASE64URL(signature).BASE64URL(sigTst_verbatim_b64u) — the current arcTst token itself is excluded from the hash input. Per-object VRT is documented in detail in Chapter 12.

Two later cross-cutting layers are wired but degenerate for B-B today:

• Algorithm-validity (032). When the opt-in --algorithm-policy is active, evaluate_jades_algorithm_validity (jades.rs:394) assembles two ObjectUnderEvaluations — the signer chain (judged by the leaf certificate's own signatureAlgorithm OID) and the signer signature (family/digest taken from the JWS alg descriptor; e.g. RS256 → RSA + SHA-256, mapped back to OID 1.2.840.113549.1.1.11) — both at the (request-time) VRT, and runs the shared CRYPTREC/NIST policy evaluator. The result populates algorithm_validity and can only degrade a non-TOTAL_FAILED base, never produce TOTAL_FAILED (e2e jades_algorithm_validity_populates_when_enforced). Off by default, this leaves the report byte-identical.
• TSA-chain revocation (033). apply_tsa_revocation_indication is called with an empty token slice (jades.rs:363) — a no-op for B-B since there are no covering timestamps. The seam exists so that future JAdES timestamp levels degrade their indication through the same shared apply_tsa_chain_revocation_for_token path as PAdES/CAdES.

8.10 Provenance, parity and reproducibility

A positively-verified signature is reported with format: JAdES-B-B and content_source: Embedded (the payload is enveloped). All refused shapes are reported with format: JAdES-unsupported and the matching INDETERMINATE sub-indication. The signer_cert_der/extra_certs_der feed the consolidated validation_objects[] inventory through the standard 016 derivation; JAdES introduces no new ValidationObjectOrigin variant (the DSS/VRI-specific pdf_dss/pdf_vri of branch 034 are PAdES-only).

The native CLI and the in-browser WASM host run the byte-identical extractor (pverify_jades::extract) and the identical verify_with kernel, so identical inputs produce byte-identical reports — the CLI↔︎WASM parity invariant, pinned by web/pverify-wasm/src/lib.rs parity tests (wasm_jades_sniff_and_extract_at_parity) and the CLI e2e suite crates/pverify-cli/tests/jades_bb_e2e.rs. The e2e tests cover the five canonical scenarios: RS256 and ES256 enveloping happy paths (TOTAL_PASSED), one-byte payload tamper and signature tamper (TOTAL_FAILED / jades_payload_digest_mismatch), signing-cert binding mismatch (TOTAL_FAILED / jades_signing_certificate_mismatch), signer-cert unavailable (INDETERMINATE), and sigD/plain-JWS refusals (INDETERMINATE / jades_unsupported_serialization and jades_unsupported_profile). Reproducibility follows from the kernel reading time only from the captured verification_time (never Clock::now), so a given (input, anchors, time, revocation-material) tuple yields a deterministic report.

8.11 Standards traceability

The JAdES path is deliberately conservative: it climbs one rung of the AdES baseline ladder (B-B), reuses the entire established path/revocation/ETSI machinery from the point the signer certificate is in hand, and refuses everything it cannot fully verify with a precise, auditable INDETERMINATE rather than a guess. The higher levels (B-T/B-LT/B-LTA) and the result-report JWS-envelope tech demo are explicitly out of scope for this slice (specs/027-jades-bb-verify/spec.md). Note: branch 037 has since implemented B-T/B-LT/B-LTA support — see §8.13 for the full implementation details.

8.13 Branch 037: JAdES B-T / B-LT / B-LTA implementation

Branch 037 (specs/037-jades-bt-blta/) extended the JAdES verification path to cover the full ETSI TS 119 182-1 §5.2.3–§5.2.7 unsigned-properties ladder. The implementation adds three new SignatureFormat variants — JAdES-B-T, JAdES-B-LT, JAdES-B-LTA — and bumps schema_version from 1.9.0 to 1.10.0. All three e2e tests in crates/pverify-cli/tests/jades_bt_blta_e2e.rs pass.

8.13.1 sigTst (B-T): signature timestamp

The sigTst unsigned property in the JWS unprotected header carries one or more RFC 3161 timestamp tokens over the JWS Signing Input. The hash input is:

sigTst_hash_input = BASE64URL(protected) || "." || BASE64URL(payload)

This is exactly the JWS Signing Input (signing_input, §8.4) — the same byte string the signer's private key operated over. The host extracts the sigTst token DER from the unprotected header and passes it to the kernel via JadesComponents.sig_tst_tokens. The kernel verifies the token imprint against a recomputation of the signing input and threads the token through apply_tsa_chain_revocation_for_token (the 033 shared helper), setting the per-object VRT for the signer objects to the token's genTime when it verifies. A sigTst-bearing input is promoted to JAdES-B-T.

8.13.2 xVals / rVals (B-LT): embedded validation material

The xVals and rVals unsigned properties carry certificate chains and revocation material (CRLs / OCSP responses) embedded in the JWS unprotected header. The host decodes and passes these as JadesComponents.x_vals and JadesComponents.r_vals. The kernel feeds them into apply_revocations via the same embedded_crls / embedded_ocsp_responses channels that PAdES-LT and the 034 DSS path use — no new revocation logic. A xVals/rVals-bearing input (that also carries sigTst) is promoted to JAdES-B-LT.

8.13.3 arcTst (B-LTA): archive timestamp with non-circular hash input

The arcTst unsigned property carries an archive timestamp token over the entire JWS structure accumulated so far, but excluding the current arcTst token itself (non-circular). The hash input is:

arcTst_hash_input = BASE64URL(protected) || "." || BASE64URL(payload) || "." || BASE64URL(signature) || "." || BASE64URL(sigTst_verbatim_b64u)

where sigTst_verbatim_b64u is the literal base64url string of the sigTst property as it appears in the unprotected header. The current arcTst token is deliberately excluded from its own hash input. The kernel verifies the arcTst imprint, threads the token through apply_tsa_chain_revocation_for_token, and sets the per-object VRT anchor to the arcTst genTime. A fully evidenced input is promoted to JAdES-B-LTA.

8.13.4 Scope: what remains out of scope

The following are explicitly out of scope for branch 037 and remain refused with jades_unsupported_profile / INDETERMINATE:

• rfsTst and tstVd unsigned properties (validation report / timestamp validation data).
• sigD detached payload reference.
• JWS Compact Serialization.
• Multiple arcTst chains (only a single arcTst token is consumed; a chain of archive timestamps is not supported).

8.12 Experimental: LTV-JWS (draft-miyachi-ltv-jws-00)

draft-miyachi-ltv-jws-00 extends JWS with a top-level ltv object that carries validation evidence at four progressive levels, described as SIG-B through SIG-LTA. pverify implements experimental support for all four levels via the same pverify-jades extractor and verify_with kernel path — no new crate, no new pipeline.

The ltv header map is parsed in crates/pverify-jades/src/parse.rs. The four levels map to SignatureFormat values LTV-JWS-SIG-B, LTV-JWS-SIG-T, LTV-JWS-SIG-LTV, and LTV-JWS-SIG-LTA. Shapes that carry an ltv key but cannot be classified (malformed or unrecognised structure) are reported as LTV-JWS-unsupported / INDETERMINATE / jades_unsupported_profile.

Level determination rules (implemented in classify_ltv_level, parse.rs):

Each ltv.* value is Base64URL-encoded JSON (not inline JSON), so the extractor decodes and re-parses each field. The ltv.signing object carries the signer certificate chain and is the bridge to the existing path-validation pipeline: the signer leaf and intermediate DER bytes are extracted and fed as x5c-equivalent chain candidates to validate_path. Revocation material embedded in ltv.signing or ltv.timestamp is threaded into apply_revocations / apply_tsa_chain_revocation_for_token via the same embedded_crls / embedded_ocsp_responses channels that PAdES-LT uses. This is additive reuse of existing infrastructure — no new revocation logic was introduced.

Interoperability findings recorded in docs/research/ltv-jws-compatibility-notes.md include: the BASE64URL wrapping (versus bare inline JSON) in ltv.timestamp/ltv.signing; the {"timestamp": BASE64URL} dict shape of ltv.archive; and the validations key as the SIG-LTV/T discriminator. These findings are candidates for feedback to the draft author.

Scope and status. This is an experimental implementation tracking draft-miyachi-ltv-jws-00. The format is subject to change as the draft evolves. The four LTV-JWS-* SignatureFormat values are additive additions to the existing closed enum and are backward-compatible. No constitutional amendment was required. The 18 integration tests in crates/pverify-cli/tests/ltv_jws_fixtures.rs cover all four levels and the unsupported-profile fallback.

9. X.509 Certification Path Validation

Release: v1.3.0 · Report schema: 1.9.0

9.1 Scope and Position in the Pipeline

This chapter specifies the X.509 certification path engine of pverify-core — the subsystem that, given a leaf (end-entity or CA) certificate, a pool of candidate intermediate certificates, a set of trust anchors and a verification time, constructs a certification path and evaluates the structural RFC 5280 §6 invariants over it. The engine is the foundation on which every AdES format verdict rests: CAdES, PAdES, XAdES, JAdES and the ASiC-delegated inner signatures all converge on the same validate_path entry point (see Chapter 4 for the format-dispatch overview).

The engine lives entirely in crates/pverify-core/src/path/:

A second concern — verifying each non-anchor step's signature against its parent's SubjectPublicKeyInfo — is deliberately not in path/mod.rs. It is wired in the orchestrator (crates/pverify-core/src/verify.rs, wire_chain_step_signatures, verify.rs:1944) so that the RustCrypto dispatch is pulled into the dependency graph exactly once and shared with the CMS signer-signature verification. This split is explained in §9.8.

The engine performs pure computation: it takes already-parsed Certificate projections and TrustAnchor byte structures (the host has done all DER ingestion and trust-anchor loading, per the Constitution §V/§VI boundary described in Chapter 3) and returns a ChainOutcome. It opens no socket, reads no file and never consults Clock::now; the only time input is the verification_time argument supplied by the caller, which is the per-object Validation Reference Time (VRT) derived as described in Chapter 12 (timestamps / VRT). This is what lets the same engine run byte-identically on native and wasm32-unknown-unknown targets.

This chapter is grounded in the specifications specs/003-v03-rfc5280-path/ (v0.3 — name constraints, policy processing, anchor-driven initialisation) and specs/008-v06-bridge-acceptance/ (v0.6 — DFS+backtrack chain construction, multi-bridge traversal, cycle detection).

9.1.1 The Two Halves of RFC 5280 §6, and an Honest Scope Statement

RFC 5280 §6 path validation has two distinct halves:

1. Structural validation — name chaining (issuer↔︎subject), validity windows, basicConstraints, keyUsage, name constraints, certificate policies. This half is implemented in path/mod.rs and its sibling modules and is the primary subject of this chapter.
2. Cryptographic validation — verifying that each certificate's signatureValue was produced by the private key matching the issuer's subjectPublicKeyInfo. This half is implemented in verify.rs::wire_chain_step_signatures (§9.8).

The engine is honest about what it does and does not enforce. In particular, the extendedKeyUsage extension is parsed and surfaced into every ChainStep (ChainStep.extended_key_usages, path/mod.rs:334) but is not enforced by the path engine: there is no rejection of an end-entity certificate lacking a required EKU, and — notably for auditors — no id-kp-timeStamping (OID 1.3.6.1.5.5.7.3.8) requirement is imposed on TSA certificates within the path engine (grep of path/ and timestamp.rs finds no EKU comparison). EKU is reported as observed fact, consistent with the Constitution §I fact-reporting discipline; relying parties who require EKU enforcement read the surfaced extended_key_usages field. This scope statement is repeated where relevant below rather than buried.

9.2 Entry Point and Outcome Shape

The single entry point is:

pub fn validate_path(
    leaf: &Certificate,
    intermediates: &[Certificate],
    anchors: &[TrustAnchor],
    verification_time: OffsetDateTime,
    required_policies: &[String],
) -> ChainOutcome

(path/mod.rs:103). Its inputs and the contract on each:

The return value:

pub struct ChainOutcome {
    pub chain_result: ChainResult,                       // the per-step report tree
    pub structural_indication: Option<StructuralFinding>, // the dominant path-level finding
}

chain_result is the ChainResult consumed by the report serialiser — one ChainStep per certificate including the terminating anchor, plus the terminating_anchor_fingerprint and the bridge_attempts vector. structural_indication is None when path validation raised no structural objection (the CMS / revocation / digest layers downstream still have to run before TOTAL_PASSED), or Some(StructuralFinding) carrying an Indication + SubIndication + locus (step[N] or anchor/chain) that aggregate_etsi (§9.9) folds into the per-signature ETSI verdict.

The StructuralFinding always carries a locus (path/mod.rs:81) so that every verdict points at the specific offending certificate, in keeping with the Constitution §I requirement that the report is a fact inventory with a failing_locus, not a bare boolean.

9.3 Chain Construction (DFS + Backtrack)

Chain construction is a depth-first search with backtracking, implemented by construct_chain (path/mod.rs:477). It replaced the v0.5 single-pass "first matching intermediate" walk in branch 008 (FR-601/FR-602) so that multi-bridge chains and dead-end intermediates are handled correctly, while preserving byte-identical output for the single-anchor straight chains that the single-pass walk already produced (V1–V23): at each depth the walker still prefers the first matching candidate, so it never needs to backtrack on a straight chain.

9.3.1 The Walk

Key invariants of construct_chain:

• Anchor-first preference (FR-025). At each step the walker first looks for a trust anchor whose subject DN matches the current certificate's issuer DN. Among matching anchors it selects by the following four-priority strategy (path/mod.rs:536-572):
  1. AKID match + validity-covering: AKID keyid matches the anchor's SKID and the anchor's validity window covers the verification time. This breaks ties when two anchors share a DN but represent different CA generations — the canonical example is GPKI OfficialStatusCA 2019 vs. 2024 key-update, which carry the same Subject DN but distinct SKIDs. TrustAnchor.subject_key_identifier carries the SKID bytes and Certificate.authority_key_identifier carries the child's AKID keyid; the comparison selects the anchor whose public key the child certificate was actually signed by.
  2. Validity-only: anchor's validity window covers the verification time (AKID absent or no SKID match).
  3. AKID-only: AKID matches but anchor is outside the validity window (expired or not-yet-valid).
  4. First-match (legacy fallback): no AKID, no validity window overlap. Without the AKID-first priority (priority 1), a DN-only match would select the wrong CA generation during a key-rollover period, leading to signature_verification: Failed on the chain step even though the chain is cryptographically valid — the signer's certificate was issued by generation A but the store contained both A and B, and a DN-only walk happened to select B first. This is why an expired-but-matching anchor still terminates the chain (and is then flagged, §9.4).
• DN matching. All issuer↔︎subject linkage uses match_dn (the rfc4518-minimal comparator, §9.10), via .linkage. The walker never compares raw DER bytes for chaining decisions.
• Per-depth try-index. tried_indices[i] records the next pool index to attempt at chain depth i+1. When the walker selects intermediate i it advances the slot to i+1 (path/mod.rs:614), so on backtrack the next sibling is tried rather than re-selecting the same intermediate — the explicit-indexing recovery of the old single-pass invariant.
• Depth cap. MAX_CHAIN_DEPTH = 10 (path/mod.rs:62). This was re-evaluated in v0.6 against the worst-case multi-bridge chain (leaf → ApCA-foreign → Foreign-Bridge → Domestic-Bridge → DomesticRoot, 5 steps) and kept at 10. Hitting the cap does not panic; the walker falls through to backtrack and ultimately surfaces a chain-incomplete INDETERMINATE (§9.6).

9.3.2 Cycle Detection

Cross-certification graphs (notably GPKI BridgeCA ↔︎ peer bridges) can contain cycles. A naive walk could loop forever. construct_chain maintains a path-local BTreeSet<[u8; 32]> (cycle_set) keyed by the SHA-256 fingerprint of the full DER-encoded certificate (cert.fingerprint, path/mod.rs:496-497). A candidate intermediate already on the current path is skipped (path/mod.rs:580); the set is populated on push and cleared on backtrack (backtrack, path/mod.rs:667).

The choice of the full-cert DER fingerprint as the identity key — rather than the SubjectPublicKeyInfo fingerprint or a (Subject DN, SPKI) tuple — is deliberate and documented in specs/008-v06-bridge-acceptance/spec.md (Clarification Q7, FR-602). During GPKI / FBCA cross-certificate rotation periods the trust store legitimately holds two Bridge-CA certificates with identical (Subject DN, SPKI) but different signatures and validity windows; SPKI- or tuple-keyed cycle detection would treat them as one logical node and falsely refuse the second, valid crossing. Full-DER fingerprint correctly distinguishes them. RFC 5280 §6 specifies no cycle-detection algorithm (it assumes a pre-constructed path), so this is pverify's own termination guarantee, not an RFC-mandated identity.

9.3.3 Output of Construction

construct_chain returns (chain, bridge_pairs, terminating_anchor):

• chain — the leaf-first certificate path (chain[0] = leaf, chain[len-1] = the intermediate closest to the anchor).
• bridge_pairs — every observed cross-certificate crossing as a [child_fp, attached_fp] pair (§9.7). Empty for straight chains.
• terminating_anchor — Some(anchor) when a path to an anchor was found, None otherwise.

9.4 Validity, BasicConstraints and KeyUsage Checks

After construction, validate_path walks chain leaf-first (path/mod.rs:144) and records the structural facts and findings per step.

9.4.1 Validity-at-Time (FR-008 / FR-025)

For each certificate the engine evaluates cert.validity.covers(verification_time) (path/mod.rs:159). When the window does not cover the time, the engine distinguishes "not yet valid" from "expired" so the sub-indication is honest (path/mod.rs:163):

The trust anchor is handled separately by anchor_chain_step (path/mod.rs:700): it uses the host-computed validity_window_covers_request_time flag, and an expired anchor yields INDETERMINATE / AnchorExpiredAtTime (path/mod.rs:715), not TOTAL_FAILED. The asymmetry is intentional — an out-of-window leaf/intermediate is a hard validity failure of the path, whereas an out-of-window anchor is a configuration question the relying party may resolve differently, so pverify reports the fact at INDETERMINATE rather than asserting forgery (Constitution §I "cannot affirm").

The anchor terminal step re-parses the anchor DER once (path/mod.rs:709) so that it can carry the same field shape — subject text, validity window, key usage, basic constraints, signature algorithm — as the leaf/intermediate steps. If the DER fails to decode (which should not happen, since the host validated it at load time) the step is still emitted with placeholder fields so the report can serialise (<unparseable anchor>, path/mod.rs:742) — the no-panic posture of Constitution §I.

9.4.2 BasicConstraints (RFC 5280 §4.2.1.9)

On every non-leaf step (idx > 0), basicConstraints.cA MUST be true (path/mod.rs:182). When the extension is absent or cA == false, the engine emits INDETERMINATE / KeyUsageMissingRequiredBit — reusing the broader KeyUsageMissingRequiredBit sub-indication because, as the code comments, the absence of the cA bit is "the structural twin of keyCertSign absence" and v0.3 chose not to mint a bespoke missing-cA sub-indication (path/mod.rs:187-194).

The numeric pathLenConstraint is surfaced into the report (ReportBasicConstraints.path_len_constraint) but not numerically enforced (path/mod.rs:179-181 comment: "v0.1 ignores path_len_constraint numerically"). Auditors should note this: a path that exceeds an intermediate's declared pathLenConstraint is reported with the constraint visible but is not rejected on that basis alone. The hard depth cap of §9.3.1 (MAX_CHAIN_DEPTH = 10) is the only depth limit actually enforced.

9.4.3 KeyUsage (RFC 5280 §4.2.1.3)

(path/mod.rs:202-225.) The leaf rule is stricter than RFC 5280 strictly requires — RFC 5280 permits an implementation to require or skip when the extension is absent; pverify v0.1+ requires the leaf to carry keyUsage with a signing bit so that signing intent is explicit (path/mod.rs:208-209). The acceptance of nonRepudiation (a.k.a. contentCommitment) alongside digitalSignature matches the GPKI/JNSA profile where non-repudiation certificates are common.

9.5 Name Constraints (RFC 5280 §4.2.1.10 / §6.1.4(g))

Name-constraints processing is anchor-first while the chain walk is leaf-first, so the engine runs a pre-pass (compute_name_constraints_states, path/mod.rs:822) that builds the cumulated state at every chain depth before the leaf-first step loop consults it. The pre-pass:

1. Initialises the state at depth 0 from the anchor's own nameConstraints (initialise_from_anchor, name_constraints.rs:83) — the RFC 5937 anchor-driven discipline mandated by FR-046a/Q3. This is the operationally important case for GPKI Bridge-CA where the domestic root declares PKI-wide constraints.
2. Walks closest-to-anchor → leaf, calling apply_intermediate (name_constraints.rs:97) to absorb each CA's constraints, recording the state after each absorption, then reverses the vector so the leaf-first step loop can index it directly (path/mod.rs:859-873).

9.5.1 State Composition

The state (NameConstraintsState, name_constraints.rs:54) keeps independent per-form lists, mirroring RFC 5280 §6.1.4(g)'s "constraints maintained for each name form":

• permitted: BTreeMap<GeneralNameForm, Vec<SubtreeConstraint>>
• excluded: BTreeMap<GeneralNameForm, Vec<SubtreeConstraint>>
• unsupported_forms_pending: Vec<String>

Per RFC 5280, permittedSubtrees compose by intersection and excludedSubtrees by union. The implementation maintains the union of every depth's permitted entries per form and performs the intersection logic at check time — equivalent to per-depth intersection for the supported-form set, and documented as such (name_constraints.rs:109-117).

The supported GeneralName forms are directoryName, dNSName, rfc822Name and uniformResourceIdentifier (name_constraints.rs:34, FR-043). Any other form (x400Address, ediPartyName, registeredID, otherName) that appears in a constraint is recorded in unsupported_forms_pending and triggers the conservative reject of §9.5.4 (FR-614).

9.5.2 Per-Form Matching (check_subject)

check_subject (name_constraints.rs:165) evaluates the subject and SAN entries against the cumulated state, with strict per-form discipline (Q1) — cross-form matching is forbidden:

• directoryName matches the certificate subject (and any directoryName SAN entries). The match rule is RFC 5280's "constrained DN is a prefix (in DIT terms) of the name." Because RFC 4514 renders RDNs most-specific-first, the implementation does a case-insensitive suffix comparison with comma-boundary checking (dn_under, name_constraints.rs:468), under the rfc4518-minimal canonicalisation (lowercase, whitespace-stripped around RDN separators, canonical_dn, name_constraints.rs:446). The limitation is disclosed in the code (name_constraints.rs:289-295): constraints depending on ASN.1-level RDN ordering or per-attribute matching fall outside the v0.3 rule.
• dNSName — case-insensitive; a leading . denotes "strict subdomain of" (.example.jp matches host.example.jp but not example.jp); without the dot the constraint matches the exact host or any subdomain (matches_dns, name_constraints.rs:388).
• rfc822Name — a constraint containing @ is a specific mailbox; a leading-dot constraint matches strict subdomains; a bare-domain constraint matches addresses whose domain is exactly that domain (matches_rfc822, name_constraints.rs:400). Per the RFC 5280 §6.1.4(g) note, an rfc822Name constraint additionally matches the emailAddress AVA inside the subject if and only if no rfc822Name SAN is present (name_constraints.rs:224-249).
• uniformResourceIdentifier — the constraint is applied to the host component of the URI authority only (uri_host extracts it, stripping scheme, userinfo and port), then matched as a dNSName (matches_uri_host, name_constraints.rs:418).

9.5.3 Self-Issued Carve-Out (Q2)

Per the RFC 5280 §6.1.4(g) note, name constraints are not applied to the subject of a self-issued, non-leaf certificate. check_subject returns NameConstraintsOutcome::SkippedSelfIssued in that case (name_constraints.rs:171-176); the leaf is always checked even when self-issued. The per-step report sets name_constraints_check.skipped_self_issued = true so the carve-out is auditable. The self-issued test is match_dn(issuer, subject).linkage (path/mod.rs:230).

9.5.4 Outcome → Indication Mapping

The outcome of check_subject is folded into the structural-finding stack (path/mod.rs:258-284). The v0.6 re-routing (T626, FR-632, Clarification Q3) is important for auditors because it changed the closed-enum surface from the v0.3 behaviour:

The rationale (path/mod.rs:241-257) is squarely Constitution §I: a constraint failure is re-routed from the v0.3 TOTAL_FAILED/ChainConstraintsFailure tag to INDETERMINATE/IndeterminateNamedConstraint because "the relying party may have a different Name-Constraints policy than what the chain's state machine concluded" — pverify surfaces "rejected by the constraint state machine" without claiming the chain is forged. An unsupported form is conservatively rejected (FR-614) to the same INDETERMINATE tag. Only a structurally malformed extension keeps its own NameConstraintsMalformed tag, because malformed-DER is a structural-soundness signal distinct from "the constraint actively rejected the chain."

9.6 Certificate Policies (RFC 5280 §6.1)

Policy processing uses the same anchor-first pre-pass discipline (compute_policy_states, path/mod.rs:884). The state (PolicyState, policy.rs:56) models the valid_policy_tree (nodes: Vec<PolicyTreeNode>) plus the three §6.1.4 countdowns: explicit_policy_pending, policy_mapping_pending, inhibit_any_policy_pending, and a malformed slot.

9.6.1 Extensions Processed (FR-051)

• certificatePolicies (§4.2.1.4, OID 2.5.29.32)
• policyMappings (§4.2.1.5, OID 2.5.29.33)
• policyConstraints (§4.2.1.11, OID 2.5.29.36) — requireExplicitPolicy / inhibitPolicyMapping
• inhibitAnyPolicy (§4.2.1.14, OID 2.5.29.54)

9.6.2 Initialisation and the State Walk

initialise (policy.rs:111) seeds the tree from the anchor's certificatePolicies when present (RFC 5937 anchor-driven, FR-046a), otherwise from {anyPolicy}, then filters through user_initial_policy_set (empty = {anyPolicy}, RFC 5280 §6.1.1(c)). Anchor policyConstraints / inhibitAnyPolicy seed the countdowns.

apply_intermediate (policy.rs:153) implements §6.1.3(d) (intersection of the cert's declared policies with the tree, intersect_with_cert_policies, policy.rs:206) and §6.1.4(a)/(b)/(c) (the countdowns, decremented saturating-at-zero after each cert so the next cert sees the decremented value, policy.rs:186-191). Policy mappings replace the issuerDomainPolicy node with the subjectDomainPolicy (apply_mappings, policy.rs:266), honouring policy_mapping_pending == 0 (when the mapping budget is exhausted, mappings are silently dropped per §6.1.4(b)).

The v0.3 simplifications are disclosed in policy.rs:33-39: expected_policy_set is populated as [valid_policy] for every node (v0.3 does not exercise multi-mapping cases that diverge them); policy-mapping cycle detection is not separately implemented because the chain walk terminates after the chain ends (self-limiting).

9.6.3 Leaf Wrap-Up (§6.1.5) and the GPKI Empty-Tree Fix

compute_outcome (policy.rs:304) performs the §6.1.5 wrap-up only at the leaf. The load-bearing subtlety, with a regression test, is the empty-tree case:

Per RFC 5280 §6.1.5, path processing succeeds when explicit_policy > 0 or the valid_policy_tree is non-NULL. An empty tree is therefore a rejection only when requireExplicitPolicy fired (modelled as explicit_policy_pending == Some(0)).

(policy.rs:316-326.) This matters because real GPKI / 官報 (Kanpō) chains commonly have a leaf whose policy OID differs from the issuer's, with no policyMappings — the tree legitimately empties at the leaf, yet the chain is accepted because no certificate asserts requireExplicitPolicy. The earlier bug that rejected empty trees unconditionally made those real chains falsely INDETERMINATE; the guard tests compute_outcome_empty_tree_at_leaf_without_explicit_policy_is_verified and its with_explicit_policy counterpart (policy.rs:413-443) pin the corrected behaviour.

Other §6.1.5 rejections: inhibitAnyPolicy == 0 with only anyPolicy in the tree (InhibitAnyPolicyViolatedAtLeaf), requireExplicitPolicy fired with no specific policy (ExplicitPolicyViolated), and a non-empty user-initial-policy-set with no matching specific policy in the tree (EmptyTree) (policy.rs:342-366).

9.6.4 Outcome → Indication Mapping

(path/mod.rs:300-323.) As with name constraints, the v0.6 re-routing flips actively-rejected policy paths to the new IndeterminatePolicyRejected tag, keeping PolicyMappingsMalformed for the structural-soundness (malformed-DER) signal. Every policy verdict is INDETERMINATE, never TOTAL_FAILED — a policy mismatch is "the chain does not satisfy this policy set," not proof of forgery.

9.7 Bridge-CA / Multi-Anchor Cross-Certificate Traversal

pverify supports inter-domain trust through cross-certificates — the GPKI BridgeCA model where a bridge CA is cross-certified with multiple domain roots. Two mechanisms cooperate.

9.7.1 Crossing Detection

bridge::detect_crossing (path/bridge.rs:56) recognises the two classic cross-certificate flavours by comparing the candidate intermediate's issuer/subject DNs against the anchor set:

1. Foreign signs Domestic — the intermediate's subject is one of our anchors but its issuer is a CA we do not hold (!issuer_in_anchors && subject_in_anchors).
2. Domestic signs Foreign — the intermediate's issuer is one of our anchors but its subject is outside our trust set (issuer_in_anchors && !subject_in_anchors).

Both return the crossing pair [intermediate_fp, anchor_side_fp] for the BridgeAttempt.crossing_pair field.

9.7.2 Traversal in the DFS Walker (FR-601)

In v0.6 the walker actively traverses bridges rather than refusing them. Every hop above the leaf is recorded as a crossing pair (path/mod.rs:618-643):

• A hop attaching an intermediate above another intermediate (chain depth ≥ 2) is always recorded as a crossing [current_fp, intermediate_fp] — this is how intermediate-to-intermediate bridge hops (the V24 multi-bridge shape) are captured.
• At the leaf→first-intermediate boundary (depth 1) the v0.3 bridge::detect_crossing heuristic is consulted; the V9 single-bridge shape hits this branch.

On backtrack, the matching bridge_pairs entry (the one whose second fingerprint equals the popped cert) is popped too (backtrack, path/mod.rs:647-653), so the recorded crossings always reflect the final chain.

9.7.3 Bridge-Attempt Verdicts (Post-Hoc)

After the chain is built and the per-step findings collected, each crossing is turned into a BridgeAttempt (path/mod.rs:397-445):

For multi-bridge chains the v0.6 implementation applies the first failure (if any) to all crossings; per-bridge per-finding correlation is noted as a future refinement (path/mod.rs:386-393). Each BridgeAttempt also carries name_constraints_evaluated — true when the bridge-side cert carried a nameConstraints extension and no bridge-side constraint failure was recorded (path/mod.rs:424-437, FR-633/US3-AS1), giving the auditor positive evidence that the crossing's constraints were checked.

9.7.4 The Retired bridge_ca_required_unsupported

In v0.1/v0.2 a chain that needed a cross-certificate produced INDETERMINATE / bridge_ca_required_unsupported. FR-048 removed that emission; the sub-indication remains in the closed enum (retained for stored-report deserialisation per the additive-schema discipline) but is no longer emitted (verify.rs:2670-2673). v0.3+ reports Bridge-CA outcomes through chain_result.bridge_attempts[*].result/detail instead, and v0.5 (FR-510) renamed the former singleton field to the bridge_attempts Vec.

If a chain genuinely reaches no anchor and no crossing was recorded (bridge_pairs empty), the engine surfaces a generic structural INDETERMINATE with locus = "chain" and no sub-indication (path/mod.rs:372-378) — the honest "this path is incomplete" signal.

9.8 Cryptographic Step Verification (Wired Outside path/)

validate_path populates each non-anchor ChainStep.signature_verification with the placeholder ChainStepSignature::Failed { reason: "cert signature verification deferred to T034" } (path/mod.rs:340). This placeholder is never mapped to a chain_signature_failed finding by the structural-finding stack (path/mod.rs:22-24), so it cannot poison reports; validate_path surfaces only structural sub-indications.

The orchestrator then calls wire_chain_step_signatures (verify.rs:1944, invoked at verify.rs:568 for the CAdES signer chain, verify.rs:783 for the per-object VRT re-validation, and verify.rs:1585 for TSA chains) to replace the placeholder with a real result. For each non-root step it:

1. Locates the parent SPKI — the next step's certificate, or the anchor's SPKI for the terminating step (parent_spki_for_step, verify.rs:2037).
2. Splits the child certificate into (tbsCertificate DER, signatureValue) (split_certificate_for_verification, verify.rs:2063).
3. Dispatches to crate::crypto::verify_with_alg(sig_alg_oid, parent_spki, tbs, sig), which routes RSA PKCS#1 v1.5, RSA-PSS, ECDSA P-256/P-384, Ed25519 and ML-DSA by OID + SPKI family (RustCrypto-only — see Chapter 3 on the WASM-clean crypto constraint).

The result mapping (verify.rs:1994-2011):

The split between path-structure and crypto-step verification exists so that the RSA / ECDSA / Ed25519 / ML-DSA dependencies are introduced into the core graph exactly once and shared with the CMS signer-signature path, rather than duplicated inside path/.

9.9 How Path Findings Become an ETSI Verdict

The per-signature ETSI indication is computed by aggregate_etsi (verify.rs:2343; see Chapter 5 §5.7 for the overall layering). Path-validation findings enter at the top of its precedence ladder:

1. Structural TOTAL_FAILED — if chain.structural_indication is a TOTAL_FAILED finding (expired/not-yet-valid cert, leaf KeyUsage failure, non-leaf keyCertSign failure), it returns immediately (verify.rs:2375-2378), ahead of every other cause. pick_dominant_finding (path/mod.rs:819) selects the most severe finding (TotalFailed > Indeterminate > TotalPassed, first-pushed wins on ties) before this point.
2. Archive-timestamp imprint mismatch, OCSP responder signature failure, signedAttrs failure, content-digest mismatch, revocation (RevokedOnCrl/RevokedOnOcsp) — these are the CMS/revocation causes layered after the structural TF (see Chapters on CMS, revocation, timestamps).
3. Unsupported algorithm / malformed key on a chain step — scanned at verify.rs:2548-2576. A step whose cert_signature_alg OID is not in the supported table yields INDETERMINATE / SignatureAlgorithmUnsupported; a recognised-OID step whose signature_verification reason begins "malformed public key:" yields INDETERMINATE / PublicKeyMalformed.
4. Name-constraints and policy INDETERMINATE — emitted at their own precedence slot (verify.rs:2604-2668) for IndeterminateNamedConstraint, NameConstraintsMalformed and IndeterminatePolicyRejected (these usually arrive via structural_indication already, but the per-step scan is defensive).

An auditor-relevant caveat. A chain step that produces a generic cryptographic verify-and-fail — verify_with_alg returns an error that is neither UnsupportedSignatureAlgorithm nor MalformedPublicKey, i.e. a true bad-signature on an intermediate's certificate — does not currently route to a dedicated TOTAL_FAILED / ChainSignatureFailed indication in aggregate_etsi. The SubIndication::ChainSignatureFailed value exists in the closed enum (report/etsi.rs:41) but the only construction of it in the codebase is inside a unit test (verify.rs:2971). The aggregation scans for unsupported-OID and malformed-key shapes explicitly, but a bona-fide forged intermediate signature is reflected only in the step's signature_verification = Failed { reason } fact in the report tree, not promoted to a top-level TOTAL_FAILED. In practice the signer's own signature (verified by the CMS layer, §2 of the ladder) and revocation cover the dominant attack surface, and a forged intermediate would typically also fail DN/issuer chaining; but this gap between the recorded step fact and the aggregated verdict is documented here for review rather than glossed over.

9.10 DN Matching: rfc4518-minimal

All issuer↔︎subject linkage decisions — chain construction, self-issued detection, bridge detection and the per-step dn_match_with_parent evidence — go through match_dn (crates/pverify-core/src/x509/name.rs), the rfc4518-minimal comparator. It applies a deliberately reduced stringprep profile (name.rs:1-24):

1. ASCII case-folding (A–Z → a–z).
2. Whitespace compression — collapse runs of [\t\n\f\r ] to one space, trim leading/trailing.
3. Encoding unification — decode UTF8String, PrintableString, BMPString, TeletexString and IA5String to a Unicode string before applying 1–2.

It deliberately does not collapse NFC vs NFD Unicode composition differences; the disclosure (name.rs and v0.1 research note R-005) records that the real GPKI mismatches observed so far are encoding-tag and trailing-whitespace differences, both of which the minimal profile catches. The method string is pinned as dn_match_method == "rfc4518-minimal-v0.1" in every report, and FR-061 forbids changing it within the v0.3 line (full stringprep is a later branch). Each ChainStep carries the DnMatchEvidence (method, bytewise_equal, and the relaxations applied) so the auditor can see exactly how a non-bytewise-equal linkage was established (path/mod.rs:155-157, report/mod.rs:678).

9.11 Report Surface (ChainStep)

Every certificate in the path — leaf, intermediates and the terminating anchor — produces one ChainStep (crates/pverify-core/src/report/mod.rs:611). The fields most relevant to path-validation audit:

The revocation record emitted by the path engine itself is always a placeholder (placeholder_revocation, path/mod.rs:787; anchor_revocation_placeholder, path/mod.rs:804) carrying IndeterminateNoCrl and the cert's CDP URIs — an honest "not yet evaluated by this layer" value. The real CRL/OCSP outcome is written by the revocation subsystem (see the revocation chapter), which is why the anchor's placeholder record is explicitly skipped when aggregate_etsi scans for revocation findings (verify.rs:2476-2489).

The name_constraints_check and policy_check fields being Option and absent for trivial states is a reproducibility-preserving design (#[serde(skip_serializing_if = "Option::is_none")], report/mod.rs:634, 643): a chain that carries no constraints/policies serialises byte-identically to the pre-v0.3 report shape, honouring the additive-feature byte-identity invariant of Constitution §II.

9.12 Summary of Invariants and Failure Modes

• Pure, deterministic, WASM-clean. No I/O, no clock; the only time input is the per-object VRT argument. Identical inputs ⇒ identical ChainOutcome on native and wasm32.
• Termination is guaranteed. Path-local full-DER-fingerprint cycle detection plus the MAX_CHAIN_DEPTH = 10 cap make construct_chain terminate on adversarial cross-certification graphs.
• Validity is the hardest structural failure. An out-of-window leaf/intermediate is TOTAL_FAILED; an out-of-window anchor is INDETERMINATE (config question, not forgery).
• Name-constraint and policy rejections are INDETERMINATE, never TOTAL_FAILED — pverify reports "rejected by the state machine under this anchor/policy set" without asserting the chain is forged (Constitution §I).
• EKU and pathLenConstraint are surfaced, not enforced. This includes the absence of an id-kp-timeStamping requirement on TSA certs within the path engine.
• Bridge-CA traversal is supported, with each crossing recorded as a BridgeAttempt carrying an Accepted / RejectedConstraintFailure / RejectedPolicyInconclusive verdict; the legacy bridge_ca_required_unsupported emission is retired.
• Generic chain-step signature failure is recorded as a per-step fact but is not currently aggregated to a top-level ChainSignatureFailed verdict (§9.9 caveat).

Downstream layers — CMS signer-signature verification, revocation (CRL/OCSP, including PAdES /DSS+/VRI material), timestamp and VRT derivation, algorithm policy and ETSI aggregation — build on the ChainOutcome this engine returns; see the respective chapters.

10. Trust Anchor Management

Release: v1.3.0 · Report schema: 1.9.0

This chapter describes where pverify's trust anchors come from, how candidate roots are authenticated and admitted into the distribution, how the verification kernel consumes them, and — equally important — what is deliberately not an anchor. Trust-anchor selection is the single most consequential decision a signature verifier makes: it determines, by axiom, which signatures can ever reach TOTAL_PASSED. pverify therefore treats anchor management as a provenance problem governed by RFC 6024 (Trust Anchor Management Requirements), kept strictly outside the cryptographic kernel, and surfaced as auditable fact in line with Constitution §I.

The material in this chapter sits on top of the kernel boundary defined in Chapter 3 (the crate::traits::TrustAnchorStore capability trait) and feeds the path-validation engine described in Chapter 9. The ingestion crates discussed here — pverify-eutl, pverify-aatl, pverify-anchor-inventory — are host-only std libraries that the cargo-tree gate (scripts/cargo-tree-gate.sh) forbids from the WASM-clean core graph; see Chapter 3 §3.2 for the topology.

10.1 The Anchor Model: Kernel Holds None, Host Supplies All

The verification kernel pverify-core ships with zero built-in trust anchors. The anchor set is always supplied by the caller through one capability trait:

// crates/pverify-core/src/traits.rs
pub trait TrustAnchorStore {
    fn anchors(&self) -> &[TrustAnchor];
}

pub struct TrustAnchor {
    pub der_bytes: Vec<u8>,                          // full Certificate SEQUENCE DER
    pub fingerprint: [u8; 32],                       // SHA-256 of der_bytes
    pub subject_dn: Vec<u8>,                         // raw encoded Name SEQUENCE
    pub validity_window_covers_request_time: bool,   // FR-025, computed host-side
    pub subject_key_identifier: Option<Vec<u8>>,     // SKID keyid bytes, for AKID-tie-break
}

This is a deliberate architectural commitment, documented at docs/trust-anchor-policy.md §10: "pverify-core does not embed trust anchors; the anchor set is always supplied by the caller (the CLI via --trust-anchors, the browser via the bundled roots.json)." It has three consequences relevant to PKI auditors:

1. The kernel cannot smuggle trust. Because pverify-core is no_std + alloc, I/O-free and forbids unsafe (Chapter 3 §3.1), there is no path by which a root could be compiled in, fetched, or otherwise materialised inside the kernel. Every anchor that reaches path validation passed through a host loader the operator can inspect.
2. The five identity/routing fields are the entire anchor surface. The kernel does not re-parse the anchor against its source. As TrustAnchor's doc-comment states, the fields are "the routing-and-identity surface only"; structural DER parsing of der_bytes happens inside the path engine (x509::Certificate), and issuer→subject matching uses the raw subject_dn bytes via the RFC 4518 minimal-DN matcher (crate::x509::name::match_dn). subject_key_identifier holds the SKID keyid bytes and is used for AKID-based tie-breaking when two anchors share the same DN (see Chapter 9 §9.3 anchor-first preference).
3. Anchor-validity is the host's responsibility (FR-025). validity_window_covers_request_time is computed at load time by the host against the verification time t (crates/pverify-cli/src/trust.rs). The store is "intentionally inert" — it surfaces every anchor including expired ones, in supplied order, never deduplicating or filtering (InMemoryTrustAnchorStore, traits.rs). Chain construction then skips any anchor whose flag is false. Excluding an expired anchor entirely would mask the fact that the operator supplied one; surfacing it lets the report record an expired-anchor finding.

10.1.1 Establishment vs. verification (RFC 6024)

A recurring auditor question — answered at length in docs/trust-anchor-policy.md §9 — is whether pverify should re-confirm, at verification time, that an anchor's authorising publication (e.g. the官報 SECOM root advertised at kanpo.go.jp) is still live, or that the distribution host's TLS is still valid. It must not, and deliberately does not. The policy follows RFC 6024's separation of establishment (a one-time secure out-of-band authentication, recorded as authority_url + the SHA-256 pin + retrieved_at) from verification (path validation against the already-established local anchor set). Once an anchor's fingerprint is pinned in the ledger it is self-authenticating; re-fetching the source at verification time would break §II reproducibility, re-introduce the SSRF surface closed by the 021 net-guard, and add nothing to the proof — exactly as an OS/browser root store does not re-contact each CA's website on every TLS handshake. The only certificate check the kernel performs against an anchor at verification time is the validity window, which path validation already evaluates at t. Re-attestation of a publication is a governance/lifecycle activity (ledger-update or release cadence), not a runtime behaviour.

10.2 Anchor Provenance Channels

pverify recognises anchors from several distribution channels, each with a data_source provenance tag. The channels divide into three trust tiers, enumerated in docs/trust-anchor-policy.md §2.

10.2.1 The pinned ledger (web/roots/*.json)

The primary channel is a machine-readable JSON ledger — one file per root — that is itself a pointer-plus-integrity-pin Trusted List. Per docs/trust-anchor-policy.md §4, the certificate bytes are not committed; each ledger entry records the source URL (retrieved_from), the SHA-256 pin, the data_source, purpose, subject DN, validity window and adoption rationale, and the web build (build-roots.mjs) downloads the bytes at build time and fails if they do not match the pin (catching either a tampered download or an issuer key rotation). The four admission conditions (§3 of the policy) are: authorised provenance with an official authority_url; SHA-256 pin match; structural validity (self-signed, BasicConstraints cA=TRUE, keyCertSign, future-dated); and a complete provenance record.

The confirmed data_source tokens carried in the ledger are:

10.2.2 LGPKI2 trust anchor (lgpki2-org-ca-r2.json)

web/roots/lgpki2-org-ca-r2.json records the J-LIS LGPKI2 Organization CA R2 (serial 5b:87:8c:23), the root for Japanese local government document signing.

Why trusted. The certificate was retrieved from J-LIS's official CA information page (authority_url: https://www.lgpki.go.jp/CAInfo/install.htm, retrieved_from: https://www.lgpki.go.jp/CAInfo/ocar2ver2.cer) and its SHA-256 fingerprint (ca137029…) is pinned in the ledger. The build breaks if the live byte does not match the pin. The CP/CPS (C-6-3-11) and technical specification (C-6-4-5_LG_tech_LGPKI_spec) are published at the same domain.

Trust scope. LGPKI2 is cross-certified with the GPKI Bridge CA, but BCA is absent from every public root store (OS / browser / Microsoft Trusted Root), so this root is closed-network in practice. Only documents signed under the LGPKI2 hierarchy — typically prefectural or municipal official records — are expected to chain to it.

Revocation. Subscriber certificates carry only DirectoryName-form CDP entries (CN=CRL{N},OU=Organization CA R2,O=LGPKI2,C=JP); www.lgpki.go.jp:389 is internet-reachable (confirmed 2026-06-26) and is reached via the dirname_to_ldap_url hint table (§11.4). Offline verification relies on /DSS-embedded CRL material.

10.2.3 The PQC-interop lab channel (isolated, not production trust)

A separate experimental tier carries the FPKI BRAWL Dev FCPCA D1 root — an ML-DSA-87 (FIPS 204, OID 2.16.840.1.101.3.4.3.19) self-signed root that exercises pverify's post-quantum verification path (010-ml-dsa-verify). It is tagged purpose: pqc-interop-lab and the web UI displays an explicit "experimental lab — not a production trust anchor" badge. It is segregated by data_source/purpose in every surface so it never silently terminates a production verification path.

10.2.4 The bootstrap/list-signer distinction

Two data_source tokens — eidas-lotl-signer and the AATL aatl-list-signer — are not document-signing anchors. They are the pinned signers used to authenticate an ingestion source (the EU LOTL XML, the Adobe AATL PDF). The policy is explicit (§2): these "are not document-signing anchors (purpose: …-signer, not injected into the verification trust store)". A national CA admitted through the LOTL is isolated under purpose: eidas-qualified; an AATL-admitted government root is isolated under data_source: adobe-aatl. The bootstrap signer never enters --trust-anchors.

10.3 EU Trusted List ingestion (pverify-eutl, slice 014)

pverify-eutl ingests an ETSI TS 119 612 TrustServiceStatusList (TSL) and emits ordinary pverify_core::traits::TrustAnchor values wrapped with ingestion provenance. It is a native std crate, gate-excluded from the core/WASM runtime graph, and performs no network I/O of its own — fetching national lists during a LOTL traversal is a caller-supplied fetch closure (crates/pverify-eutl/src/ingest.rs, ingest_lotl), keeping the crate deterministic and testable from captured bytes.

10.3.1 The trust model: signer pin, not RFC 5280 chain

Crucially, eutl does not authenticate a Trusted List by building an RFC 5280 chain to a self-signed anchor and running revocation. As crates/pverify-eutl/src/verify.rs documents (research R-003), "the trust is established by the pin (the OJEU-pinned LOTL signer, or the LOTL-vouched national signer identity)". authenticate() therefore:

1. extracts the enveloped ds:Signature via pverify_xades::extract (reusing the same Exclusive C14N engine, bergshamra-c14n, that all XAdES verification uses — Chapter 7);
2. requires the embedded signer certificate to match one of the pinned signer_certs DER-exact (signer_certs.iter().any(|pin| pin.as_slice() == signer_der));
3. verifies every ds:Reference digest (content integrity);
4. verifies the signature value over canonical SignedInfo using pverify_core's RustCrypto primitives (RSA-PSS, RSA PKCS#1 v1.5, ECDSA per the OID resolution in xades_sig_alg_oid);
5. enforces the SigningCertificateV2/CertDigest binding when present (certificate-substitution defence).

An unsupported XAdES profile, canonicalization or signature algorithm is a verification failure for the list, never a silent skip of the check (FR-004), and "no anchors are read from a list that fails here" (ingest_one returns signature_verified: false with empty anchors).

10.3.2 The status-at-time-t filter (the security core)

The single most security-critical decision in eutl is the granted-at-t filter, implemented in crates/pverify-eutl/src/status.rs and verify.rs::authenticate. A TSL service yields a trust anchor if and only if two conditions hold (ingest.rs::anchor_services):

• ServiceType is exactly …/Svctype/CA/QC (SVCTYPE_CA_QC, R-002, ServiceType-only). Qualifications are deliberately not consulted; TSA / OCSP / CRL service types are excluded with non_ca_qc_type.
• The status in effect at verification time t is granted (STATUS_GRANTED, R-001).

The status resolver ServiceStatus::status_at(t) (status.rs) is precise about time. It collects every timed (StatusStartingTime, ServiceStatus) instance from the current status plus the ServiceHistory, sorts ascending, and selects the instance whose half-open interval [starting_time, next_starting_time) contains t (the latest interval is unbounded on the right). Resolving at "now" instead of t would either trust a CA withdrawn after the document was signed, or distrust one that was granted at signing time — breaking both the security goal and §II reproducibility. The boundary semantics are inclusive-left (exactly at a StatusStartingTime the new status takes effect), as the boundary_at_exact_starting_time test asserts.

The accepted set is granted only. The eleven pre-eIDAS legacy status URIs (undersupervision, accredited, supervisionincessation, etc., enumerated in LEGACY_STATUS_URIS) are recognised — so a historical-t resolution lands on the correct interval — but they all exclude; broadening to legacy "active" states is a recorded follow-up, never silently assumed. An unrecognised status URI resolves as "not granted" (excluded), never silently accepted.

Every examined-but-not-anchored service is recorded with its reason in excluded[] (ExcludedService / ExclusionReason::{NonCaQcType, Status}), so the §I fact record is honest about both what was admitted and what was dropped. A granted CA/QC service whose ServiceDigitalIdentity carried no parseable CA cert is also recorded (granted_but_no_parseable_ca_certificate) rather than silently dropped.

10.3.3 LOTL traversal with partial success

ingest_lotl drives a full LOTL (List of Trusted Lists) traversal:

Each national list is authenticated against the signer identity the LOTL vouches for it (TslPointer.expected_signer_identity, from the pointer's ServiceDigitalIdentity), not against a global anchor set (FR-012). A single failing country becomes a SkippedList with a recorded reason and never aborts the run (FR-011, R-006 partial success) — the honest "reached but not ingested" signal. Anchors are deduplicated across countries by SHA-256 fingerprint, with seen_in accumulating every (territory, service_name) endorsement (dedup_and_sort), and emitted in fingerprint order for determinism.

The TSL is parsed (crates/pverify-eutl/src/tsl.rs) over the same bergshamra-xml DOM the C14N layer already trusts (research R-004) — one XML parser, eliminating the signature-wrapping / parser-differential risk of a second parser. Malformed or rootless XML is a fatal EutlError, never a silent empty.

10.3.4 Anchor construction and observed_status

Each admitted CA cert is turned into a TrustAnchor by build_anchor exactly as pverify-cli/src/trust.rs builds them — only CA certs (BasicConstraints.cA == true) are anchored; a leaf-shaped ServiceDigitalIdentity cert is recorded-not-anchored. Every produced anchor carries purpose: "eidas-qualified" and observed_status: "granted". Constitution §I is reinforced in the doc-comments: observed_status "records the raw TS 119 612 status string only", and purpose = "eidas-qualified" is "a provenance/isolation tag, never a verdict" — pverify never adjudicates "qualified" or "legally valid".

10.4 Adobe Approved Trust List ingestion (pverify-aatl, slice 026)

pverify-aatl is the AATL analogue of pverify-eutl. Adobe's AATL distribution (https://trustlist.adobe.com/tl12.acrobatsecuritysettings) is a CMS-signed PDF 1.6 (PAdES) whose signing chain terminates at the self-signed Adobe Root CA G2, wrapping a single FlateDecode text/xml /EmbeddedFile — a namespace-less <SecuritySettings><TrustedIdentities><Identity>… list (≈294 identities). The crate is ingest(distribution_bytes, adobe_root_ca_g2_der, at), a pure function with no network I/O.

10.4.1 Pin-based authentication via the real PAdES pipeline

Like eutl, the AATL distribution is authenticated by a pin, but the mechanism is notable: crates/pverify-aatl/src/pdf.rs::authenticate runs the actual pverify_core::pades::verify_pdf pipeline (Chapter 6) against a single-anchor store containing only the pinned Adobe Root CA G2, in VerificationMode::Offline. The accept criterion is a structural pin-based predicate, not the ETSI Indication. This is deliberate: offline, the distribution's ETSI indication is expected to be INDETERMINATE (revocation cannot be checked — the §I "cannot affirm" discipline), so consuming the indication would reject every offline ingest. Instead entry_satisfies_pin requires, over some produced SignatureEntry:

1. chain_result.terminating_anchor_fingerprint == hex(SHA-256(pin)) — the chain reached the pinned Adobe Root CA G2;
2. every chain-step signature Verified (the anchor step being NotApplicableForRoot);
3. the CMS signed-attributes signature Verified and signed_attrs_digest_match == Some(true);
4. content_digest_check.digest_match == true — the embedded XML payload is intact.

Trust is the pin, exactly as eutl trusts the OJEU-pinned LOTL signer. (The verify_pdf call passes &Default::default() for the 034 DSS/VRI material and None for the 032 algorithm policy, so authentication is a plain pinned-root chain check.)

10.4.2 The government-affiliation filter (a documented heuristic, never a verdict)

After authentication, extract_embedded_xml pulls the inflated text/xml /EmbeddedFile and parse_identities (crates/pverify-aatl/src/parse.rs) parses each <Identity> over the same bergshamra-xml DOM. classify (ingest.rs) then admits an identity as an anchor only if, in order:

1. its <Certificate> body base64-decodes and parses as X.509 (certificate_parse_failed otherwise);
2. <Trust><Root> is 1 (not_root otherwise);
3. <Trust><CertifiedDocuments> is 1 (not_certified_documents otherwise);
4. its subject DN matches the government-affiliation keyword heuristic (not_government_affiliated otherwise).

The heuristic (crates/pverify-aatl/src/filter.rs::is_government_affiliated) is a case-insensitive substring match of the subject DN against the closed, documented GOV_KEYWORDS set (government, gobierno, gouvernement, icp-brasil, cca india, bundesamt, ministry, federal, uae, dod , …). Constitution §I governs this surface explicitly: "the heuristic is NOT a verdict… a genuinely-government identity the heuristic misses is excluded and recorded, never silently anchored, and a borderline match is visible for review." The matched keyword is recorded verbatim in the anchor's affiliation_match provenance field so a human can audit every admission, and the keyword list "is the audit surface — extend it deliberately, never silently." The unit tests pin both directions: government subjects (ICP-Brasil, Swiss Confederation, CCA India) match; contested commercial CAs (WoSign) and ordinary commercial roots (DigiCert) do not.

Every excluded identity is recorded as an ExcludedIdentity with its ExclusionReason so the union (admitted anchors ∪ excluded) equals the distribution's full identity count — the invariant later surfaced in the inventory (§10.5).

10.4.3 Fetch-don't-bundle and the SECOM look-alike caveat

The AATL distribution is fetched, not committed (docs/trust-anchor-policy.md §2): Adobe's curated compilation has unclear redistribution licensing (potential compilation/database rights), so pverify follows the prevailing OSS practice (tl-create, PDF4QT, pyHanko) of having the user/CI fetch it directly from Adobe; only the pinned Adobe Root CA G2 (Adobe's own root) is recorded in the ledger. The policy also flags a concrete trap auditors should note: the官報 trust roots (SECOM RSA Root CA 2023 / OfficialStatusCA 2024) are not in AATL (DER-SHA256 confirmed distinct), and AATL contains a deceptively-named look-alike, SECOM Document Signing RSA Root CA 2023, which must not be conflated with the官報 anchor — the官報 anchor stays individually pinned.

10.4.4 Bootstrapping the list-signer cert from the distribution itself

The AATL ledger entry's retrieved_from points at the AATL distribution (tl12.acrobatsecuritysettings, a PAdES-signed PDF), not at a bare certificate — the Adobe Root CA G2 that the entry pins lives inside that PDF's CMS signature. Earlier the web build (build-roots.mjs) tried to read the pinned cert straight from the fetched bytes and, when the ledger pointed at the distribution rather than a cached DER, handed the CLI the wrong bytes — ingest-aatl then authenticated nothing and the production roots page ingested zero AATL anchors. The build now extracts the pinned cert from the distribution before the CLI call: it decodes every /Contents <hex…> CMS blob in the PDF (and falls back to a raw-byte scan for an operator-supplied bare cert), scans each for an X.509 DER SEQUENCE, and returns the first slice whose DER SHA-256 equals the ledger pin (extractPinnedCertByHash). Accepting only a slice that hashes to the pin makes the scan safe regardless of where in the bytes it points: the pin remains the sole integrity anchor (fetch-don't-bundle is preserved — nothing new is committed). If no slice matches, the build skips the AATL report rather than ingesting an unauthenticated cert.

10.5 The anchor inventory (pverify-anchor-inventory, slice 028)

pverify-anchor-inventory is a host-only std aggregation library that reads over every channel pverify's release distributes and emits a single canonical Inventory artefact, consumed byte-identically by two surfaces: the CLI pverify trust-anchors dump command and the web web/site/trust-anchors.json powering the trust-anchor visualisation page. Its construction guarantee (aggregate is a pure function with no clock read and no randomness; write_json emits 2-space-indent / LF / single-trailing-newline JSON) makes two runs against the same release inputs byte-identical — Constitution §II reproducibility, the basis for cross-release anchor-drift diffing.

10.5.1 Channels and dedup

The closed ChannelLabel enum fixes the channel set and its display order: pinned-ledger, fpki-bundle, eutl, aatl-trusted, aatl-excluded, pqc-interop (crates/pverify-anchor-inventory/src/inventory.rs). The aggregator ingests each channel (pinned ledger entries, the captured eutl IngestReport, the captured AATL IngestReport), then merge_and_sort deduplicates by fingerprint while merging attributions — when the same fingerprint appears in two channels (e.g. an FPKI cert that is also the FCPCA G2 ledger root), one AnchorEntry is emitted with multiple EntryAttributions, and first-non-empty-wins for affiliation/country/key_algorithm. FPKI roots (data_source == "fpki") route to fpki-bundle; pqc-interop-lab purpose routes to pqc-interop; the rest to pinned-ledger.

10.5.2 §I segregation of excluded identities

The AATL identities that the 026 ingest dropped are surfaced read-only as a separate type (ExcludedEntry) in a separate JSON array (excluded[]), so "no rendering / filter / sort / export path can collide them with trust anchors" (FR-007/FR-010). The web UI realises this as a distinct tab ("AATL 除外（参考）") with a persistent non-dismissible "informational, not a trust anchor" banner. For each not_government_affiliated exclusion, the inventory attaches a GovKwAudit panel embedding the full GOV_KEYWORDS snapshot beside the subject DN and a fixed plain-language audit note (GOV_KW_AUDIT_NOTE) — letting a reviewer audit the §10.4.2 heuristic by inspection without trusting it on faith (FR-009).

10.5.3 Self-checking invariants

check_invariants (crates/pverify-anchor-inventory/src/aggregate.rs) is called before the inventory is returned and fails the build loud on any violation. Of audit interest:

• INV-3: anchor fingerprints are pairwise distinct (dedup actually happened).
• INV-4 / INV-5: entries[] and excluded[] are in their deterministic sort order.
• INV-7: (AATL-trusted anchors ∪ excluded identities) count equals the captured AATL IngestReport.total_identities — the §10.4 conservation law, surfaced as a build-time check.
• INV-6 / INV-8: every next-hop edge stays within its parent's contributing channel and is_inventory_anchor is only set when the fingerprint truly exists in entries[].

10.5.4 Chain-reach: a deliberately conservative one-hop view

crate::chain_reach::derive_next_hop_issuers answers "what is on the other side of this root" (US3) by a single render-time hop: for each root, within each of its own contributing channels, it lists any distributed entry whose Issuer DN equals the root's Subject DN (RFC 4514 text equality post-trim, chosen over OID-encoded matching to mirror "how a human reads the data", R-4). Two properties are load-bearing and auditor-relevant:

• No cross-channel edges (FR-014). A root on pinned-ledger does not pick up next-hops from fpki-bundle even when DNs coincide; the same entry must contribute attributions on both channels for a cross-channel edge to surface. The cross_channel_edges_forbidden test pins this.
• Honest empty (FR-012). Channels that ship root-only material (AATL trusted, PQC-interop, the GPKI/官報 pinned roots) yield next_hop_issuers: [], and the renderer keys off the empty array to print an explicit "no next-hop issuers recorded in the distributed material" message — never a silent empty panel, never a fabricated edge (§I).

This is not path validation and makes no trust claim; it is an inspection aid over already-distributed bytes.

10.5.5 Rendering: provenance grouping and large-channel collapse

The web trust-anchor page (web/site/roots.js) groups the inventory by provenance and labels each card with why the root is bundled — which PKI / programme it came from — so a reader can judge an anchor at a glance without expanding it. Each card shows a localized data_source tag (SOURCE_KEYS: GPKI, GPKI-cross-certified accredited CA, Commercial Registration, Official Gazette, FPKI, EU Trusted List, Adobe AATL, PQC interoperability lab) plus the entry's country tag; unknown sources fall back to the raw key (never hidden, §I). Channels large enough to bury the rest of the page — in practice the EU LOTL/national trusted lists with their hundreds of national-list anchors — are collapsed by default behind a <details> whose summary is the channel banner (COLLAPSED_BY_DEFAULT), so the domestic pinned-ledger roots stay visible while the EU channel opens on deliberate click. The pinned-ledger channel is labelled "個別ピン登録のルート（手動台帳）" to convey that it is the manually-curated, individually-pinned set rather than an ingested list.

10.6 The flat-N (Trusted List) vs. bridge/hierarchy trust models

pverify's anchor channels embody two structurally different PKI trust topologies, and the distinction matters for what can and cannot be collapsed in the anchor set.

A bridge / hierarchy model (the US FBCA, CertiPath, Japan's GPKI BridgeCA federation) is reducible: a single anchor plus a pool of cross-certificates can express trust in many domains, because the bridge cross-certifies the domain roots. pverify's path engine handles bridge crossings explicitly in crates/pverify-core/src/path/bridge.rs (Chapter 9) — detect_crossing recognises the "foreign signs domestic" and "domestic signs foreign" cross-certificate shapes.

A Trusted List model (eIDAS LOTL/TSL, Adobe AATL) is not reducible: it is a flat set of N mutually-independent self-signed roots, each individually trusted by enumeration. There is no single bridge to which they all cross-certify. As recorded in the project memory note "trust-model asymmetry" (and confirmed by the eutl/aatl design): bridge/hierarchy roots can be folded into "one anchor + a cross-certificate pool", but a Trusted List cannot — the web/roots set is, by construction, a list of independent self-signed roots, so "drop everything but the bridge CA" is not a valid reduction. This is precisely why eutl and aatl emit one ordinary TrustAnchor per admitted root rather than a single ingested "super-anchor": the flat-N model demands flat-N anchors, each carrying its own provenance.

10.7 What is NOT an anchor

Three classes of certificate are deliberately excluded from the anchor set. Auditors should verify these boundaries hold, because each represents a real attack or confusion that the design forecloses.

10.7.1 PAdES /DSS /Certs are never anchors

The 034 PAdES DSS/VRI feature (Chapter 6) consumes a PDF's document-level /DSS /Certs pool to build the signer's certificate chain. These certificates are admitted only as intermediate/leaf path-building candidates, never as trust anchors (crates/pverify-core/src/pades/mod.rs, Q7/FR-005). The code is explicit at the point of use: the resolved /Certs are appended to the intermediates candidate set —

// crates/pverify-core/src/pades/mod.rs ~L662–677
// Append its `/Certs` to the intermediate-candidate set (never to anchors —
// Q7/FR-005/VR-2) …
for cert in &resolved.certs {
    if !intermediates.iter().any(|c| c.fingerprint_hex == cert.fingerprint_hex) {
        intermediates.push(cert.clone());
    }
}

This is essential: a /DSS is part of the document under verification and is attacker-controllable. If a /Certs entry could become a trust anchor, an adversary could embed a self-signed root and have their own signature chain "terminate" at it. The chain must still reach an anchor the operator supplied. The same rule applies to Adobe revocationInfoArchival material (it supplies revocation evidence, tagged signature_embedded, never anchors).

10.7.2 Synthetic fixture roots

The 28 synthetic roots under fixtures/bundles/*/trust-anchors/ exist only for the test suite. They fail admission conditions 1–3 of the policy (docs/trust-anchor-policy.md §5) and are never distributed as real document-signing anchors.

10.7.3 Ingestion bootstrap signers

As noted in §10.2.4, the EU LOTL signer (eidas-lotl-signer) and the Adobe Root CA G2 (aatl-list-signer) authenticate the ingestion source; they are never injected into the verification trust store. OS/browser trust-store membership alone is likewise not an admission reason — the four policy conditions decide (docs/trust-anchor-policy.md §5).

10.8 Re-feeding ingested anchors and the CLI surface

A unifying design choice ties the whole chapter together: ingestion produces nothing the kernel doesn't already understand. Every ingestion crate builds its anchors with the identical (der_bytes, SHA-256 fingerprint, subject_dn, validity-covers-t) shape that pverify-cli/src/trust.rs produces for --trust-anchors. The CLI ingest commands therefore materialise admitted anchors as PEM files (one <fingerprint>.pem per anchor, deterministic filenames; crates/pverify-cli/src/ingest.rs::materialize and der_to_pem), which the operator can then feed straight back through the ordinary verify --trust-anchors <DIR> walker. The CLI exposes ingest-trust-list (eutl, with --lotl for a full traversal and exit code 4 for a list-signature failure), ingest-aatl (aatl), and trust-anchors dump (the inventory).

This closes the loop on Constitution §I and the §10.1 anchor model: pverify-core gains nothing from any ingestion crate — the report enums and schema_version stay frozen — because ingestion emits ordinary TrustAnchors plus its own provenance report types, and the only trust the kernel ever sees is the flat, operator-supplied, fingerprint-pinned anchor set re-fed through the one capability trait.

11. Revocation Checking

Release: v1.3.0 · Report schema: 1.9.0

This chapter describes how pverify establishes the revocation status of each certificate on a signature's certification path. It covers the two revocation channels pverify understands — CRL (RFC 5280) and OCSP (RFC 6960) — the precedence rules that arbitrate between distribution-point fetches, embedded in-signature material and stapled responses, the LDAP-CRL transport added for the Japanese accredited-CA ecosystem, the freshness/staleness windows, the offline-honesty discipline, and the closed RevocationOutcome vocabulary the verifier ultimately reports.

Revocation evaluation lives entirely in the no_std, I/O-free verification kernel. The whole computation is in crates/pverify-core/src/revocation/ (mod.rs orchestration, crl.rs CRL parse/verify, ocsp.rs OCSP processing, indirect.rs indirect-CRL detection). The kernel performs no network I/O of its own; the bytes it consumes arrive over the RevocationFetcher trait (crates/pverify-core/src/traits.rs), whose concrete implementations are the CLI's online (ureq), offline and from-bundle fetchers (crates/pverify-cli/src/modes/). This separation is the §V/§VI boundary restated for revocation: the kernel decides which URIs are worth a fetch and how to interpret the returned bytes, while the host decides how to retrieve them. See Chapter 3 for the overall architecture and Chapter 9 for the path validation that produces the chain whose steps are revocation-checked here.

The governing principle throughout is Constitution §I "cannot affirm": every revocation result is a fact the verifier observed — good on CRL, revoked on OCSP, no CRL pointer, responder unreachable, not checked because offline. Where a status cannot be established, the verifier degrades to INDETERMINATE with a precise sub-indication rather than fabricating a pass or a failure.

11.1 Where Revocation Sits in the Pipeline

Revocation is applied after a certification path has been constructed and its intra-chain signatures verified, and it is applied per object at that object's own Validation Reference Time (VRT — Chapter 12). The signer chain is revocation-checked via apply_revocations (crates/pverify-core/src/verify.rs:2075); each timestamp's TSA chain is revocation-checked via apply_tsa_chain_revocation_for_token (verify.rs:1552), introduced in branch 033 so that TSA-certificate revocation is consistent across all formats. Both entry points converge on the single revocation orchestrator, check_revocation_ctx (crates/pverify-core/src/revocation/mod.rs:184).

apply_revocations iterates the non-anchor steps of the chain (verify.rs:2111) — the trust anchor itself is never revocation-checked, since it is trusted a priori — and for each child certificate builds a RevocationContext (revocation/mod.rs:76) carrying the parent CA's SPKI and subject DN, the fetcher, the verification time (the per-object VRT), the trust anchors, the cert pool used for OCSP responder/issuer lookup, the embedded OCSP/CRL material, and the verification mode.

Two details of apply_revocations matter to an auditor:

• Embedded OCSP responses are leaf-only. Only step index 0 (the signer or TSA leaf) receives the embedded ocspVals; intermediates pass an empty embedded-OCSP list (verify.rs:2126). This is because stapled OCSP responses are CertID-bound to a specific leaf+issuer pair.
• Embedded CRLs cover every step. Unlike OCSP, an embedded CRLValues entry can apply to any certificate on the path, so the full embedded-CRL slice is threaded into every step's context (verify.rs:2142).

11.2 The Precedence Channels: CDP-first, OCSP-fallback, Embedded-only-on-indeterminate

pverify consults up to three sources of revocation material in a strict, auditable order. The contract is that the first channel to yield a definitive fact wins, and a later channel is consulted only when the earlier channel was indeterminate. This ordering is what preserves the byte-identity invariant (Constitution §II): a signature whose CDP CRL channel succeeds produces exactly the same report whether or not embedded material is also present.

check_revocation_ctx (revocation/mod.rs:184) implements the ladder:

1. CDP / direct-CRL pipeline (run_cdp_pipeline, revocation/mod.rs:284). The CRL distribution points named in the certificate are classified and, if fetchable, retrieved and consumed. If the outcome is definitive — GoodOnCrl or RevokedOnCrl — it is returned verbatim and no further channel is consulted (revocation/mod.rs:208).

2. Embedded CRLs (try_embedded_crls, revocation/mod.rs:252). Reached only when the CDP outcome is one of the Indeterminate* CRL variants. Each in-signature CRL (CAdES/PAdES revocation-values.crlVals, XAdES RevocationValues/CRLValues) runs through the same consume_crl validation as a fetched one — issuer-DN linkage, indirect-CRL refusal, signature verification, freshness window and serial lookup. The first embedded CRL that yields GoodOnCrl/RevokedOnCrl wins (revocation/mod.rs:274); a CRL that does not apply (wrong issuer, stale, indirect) is skipped so a later embedded CRL can still match. This is the 019-xades-bt-blt mechanism that lets an LT-level signature validate its path offline.

3. OCSP pipeline (run_ocsp_pipeline, revocation/mod.rs:620). Reached only when the CDP channel was indeterminate, no embedded CRL produced a verdict, and the leaf carries OCSP material (an AIA id-ad-ocsp URI or embedded ocspVals — revocation/mod.rs:228). Within the OCSP pipeline the source order is again precedence-ranked: embedded ocspVals are tried before any AIA-fetch (revocation/mod.rs:637).