1. 序論、スコープおよび設計目標

本章では、pverify とは何か、それが何を検証し、また何を意図的に拒否するのかという正確な境界、対象とする読者層、リリース v1.3.0 時点で実際にサポートする入力フォーマットおよび高度電子署名（AdES）レベル、そしてその後のあらゆる設計判断を規定するアーキテクチャ上の立場——pure Rust でビルドし、WASM ビルド可能な検証カーネル——を確立する。章の末尾では、残りの各章への読者向けガイドを示す。

本章における主張は、リポジトリルートのソースツリーに根拠を置く。具体的な証拠は crates/<crate>/src/<file>.rs の形で引用する（論点を明確にする場合は関数または行番号を付す）。ツールの挙動が微妙な箇所——とりわけ、合格や失敗を捏造するのではなく INDETERMINATE へと縮退させる断定回避の原則——については、理想化された要約ではなく、コードが実際に行っていることを記述する。

1.1 pverify とは何か

pverify は、高度電子署名（AdES）を検証する Rust ツールキットであり、観測した事実の構造化記録を出力する——「有効／無効／適格」といった業務上の判定を下すことは決してない。これは本プロジェクトの第一かつ譲歩不能の原則であり、憲法（Constitution）において原則 I、*事実報告（Fact-Reporting）*として批准されている（.specify/memory/constitution.md、"Core Principles / I. Fact-Reporting (NON-NEGOTIABLE)"）:

pverify は観測した事実の構造化レポートを出力するのであって、「適格電子署名」や「法的に有効」といった業務上の判定を出力することは決してない。

• 出力 JSON は、参照したすべての成果物を列挙しなければならない（MUST）: 証明書チェーンの構成員、取得した CRL／OCSP レスポンス／TSA トークン、それらの出所、および各々に対して実施した評価。
• ETSI EN 319 102-1 のインディケーション（TOTAL_PASSED / INDETERMINATE / TOTAL_FAILED）は機械可読な指標として出力してよい（MAY）が、pverify はそれを領域上の判定へ翻訳してはならない（MUST NOT）。
• pverify は、法的有効性、規制上の適格性、または証拠能力を主張するいかなるテキストまたはフィールドも出力してはならない（MUST NOT）。

その理由づけは憲法に明示されている。署名の適格性は、保存期間、署名時刻と検証時刻との関係、アーカイブタイムスタンプの要件、および検証者（信頼当事者）ごとに異なる相手方との合意に依存する。これらの懸念事項を先回りして判断するツールは、誤用を強いることになる。したがって pverify は観測したこと——どの証明書をどのチェーンに組み込んだか、どの CRL および OCSP レスポンスをどの出所から参照したか、どのタイムスタンプをどのインプリントに対して再計算したか——を報告し、法的・業務的な判定は利用者に委ねる。

検証実行ごとの出力は、クローズドスキーマの JSON 文書である。署名ごとの最上位の機械可読判定は、ETSI EN 319 102-1 インディケーションであり、TOTAL_PASSED、INDETERMINATE、TOTAL_FAILED のいずれかである。これは crates/pverify-core/src/report/etsi.rs のクローズド列挙型 Indication（24 行目で宣言）で表現される。これは、単一のクローズド列挙型 SubIndication（同ファイル 39 行目）から引かれる精密な機械可読のサブインディケーションによって限定され、ルートの report-schema.json に 1:1 でミラーされる。自由形式の判定文字列は構造上禁止されている: サブインディケーション値の追加は追加的な MINOR スキーマ変更であり、いずれかの削除または転用は MAJOR 変更である。

JNSA デジタル署名検証ガイドライン（第 1.1 版）の判定語彙と pverify の ETSI インディケーションとの関係は docs/jnsa-conformance-statement.md に記載されている。高レベルのマッピングは VALID → TOTAL_PASSED（pverify が実装したチェックセットの範囲内）、INVALID → TOTAL_FAILED、INDETERMINATE → INDETERMINATE である。当該適合性ステートメントが正規のクロスウォークであり、本文書はそれを再掲しない。

1.1.1 「断定回避」の原則

pverify を特徴づける挙動の一つであり、いかなるレポートを読む前にも専門の監査人が体得すべきものは、ツールが立証できない判定を決して捏造しないことである。pverify が事実を確立できない場合、それは TOTAL_FAILED（改ざんや失効を誤って主張することになる）や TOTAL_PASSED（信頼を誤って確証することになる）をでっち上げるのではなく、精密なサブインディケーションを伴って INDETERMINATE へと縮退する。この原則の具体的な現れは次のとおりである:

• サポート外の署名アルゴリズム OID（例: Ed448、brainpool、P-521、GOST、SM2）は、失敗ではなく INDETERMINATE / signature_algorithm_unsupported を生じる——これにより、利用者は「未対応」を暗号学的危殆化と混同することなく grep で抽出できる。
• 失効したタイムスタンプ局（TSA）証明書は、INDETERMINATE における revoked_no_poe サブインディケーションを生じる（ブランチ 033 で導入）。これは、失効した TSA 証明書がそれ自体で保護対象の署名が偽造であることを証明するものではない——失効以前に確立された存在証明（PoE）が存在しうる——ことを反映している。
• 複数署名者の CMS は、最初の署名者のみを暗黙のうちに報告するのではなく、意図的に INDETERMINATE / cms_multi_signer_unsupported で拒否される（crates/pverify-core/src/verify.rs、verify_cades、約 497 行目が 1890 行目の cades_multi_signer_entry を呼び出す）——暗黙の単一署名者レポートは誤解を招く確証となるためである。
• 到達不能な失効レスポンダ、またはキャッシュ済み失効情報を持たないオフライン実行は、レスポンダ接触を捏造するのではなく IndeterminateRevocationOffline / revocation_not_checked_offline を生じる（オフラインの誠実性の原則、憲法 §VII / §I）。
• オプトインのアルゴリズムポリシー（CRYPTREC/NIST）は、最悪でも INDETERMINATE における crypto_constraints_failure_no_poe を生じ、ETSI の CRYPTO_CONSTRAINTS_FAILURE_NO_POE を反映する。これが TOTAL_FAILED へエスカレートすることは決してない。

この原則こそが、pverify のレポートが監査可能である理由である: あらゆる INDETERMINATE は、どの事実が確立できなかったかを正確に指名するクローズド列挙型の理由を伴う。サブインディケーション語彙の全体については第14章（Result Model: インディケーション、診断データおよびスキーマ）を、優先順位規則については第5章 §5.7 と第14章（ETSI インディケーション集約）を併せて参照のこと。

1.2 対象ユーザ

pverify は、ビジョンステートメント（docs/vision-statement.md §3）に定めるとおり、同心円状の三つの読者層に供する:

1. 第一義的——統合する開発者。 pverify-core を組み込み、GPKI 署名検証を自社製品に追加する、電子申請 SaaS プロバイダ、自治体ベンダ、文書管理ベンダのバックエンドエンジニア。ライブラリファーストの設計（憲法 §V）は彼らのために存在する: pverify-core は I/O を行わない no_std + alloc クレートであり、検証ロジックを変更することなく、ネイティブバイナリ、WebAssembly モジュール、または Cloudflare Worker から駆動できる。

2. 第二義的——検証オペレータおよび監査人。 CLI を直接呼び出して単発の検証や監査対応を実行する、自治体、監査法人、公文書の管理者。再現性（憲法 §II）および監査可能性（§III）の保証は彼らのために存在する: --from-bundle の呼び出しは、コンテンツアドレス指定されたバンドルから数週間後に検証を再実行し、バイト単位で同一のレポートを生成する。

3. 第三義的——研究者および標準化参加者。 pverify を ETSI EN 319 102-1 および RFC 5280 §6 のリファレンス実装としてベンチマークやテストベクタの検証に用いる者。

包括的な顧客文脈は、日本の政府認証基盤（GPKI）である: pverify は、GPKI 署名された CAdES/PAdES/XAdES 文書——省庁間または政府対民間の信頼のために GPKI のブリッジCA構造を経由する署名を含む——を受領する検証者（信頼当事者）が、共通の、堅牢かつ再現可能な検証基盤を持てるように構築されている。同時に、欧州の eIDAS / ETSI 体系（EU トラステッドリスト、CAdES/PAdES/XAdES/JAdES/ASiC のベースラインレベル）も認識しており、同一のエンジンが GPKI/JNSA プロファイルと eIDAS プロファイルの双方を検証する。

1.3 スコープ: pverify が検証するもの

pverify は五つの AdES 署名ファミリを検証し、そのうち三つは複数のベースラインレベルにわたる。サポートする範囲は意図的に誠実である: フォーマットのバリアントや AdES レベルが現行実装を超える場合、ツールは推測するのではなく、INDETERMINATE におけるクローズド列挙型のサブインディケーションで拒否する。

1.3.1 サポートする入力フォーマット

検証カーネルは、入力を正しいフォーマット別検証器へ振り分けるために、先頭バイトに対するコンテンツスニフを行う（crates/pverify-core/src/verify.rs、detect_format、359 行目）:

ASiC の ZIP マジックの場合は、バイトスニフの前に処理される: ホストが ASiC コンテナ署名を抽出していれば、verify_with は無条件に ASiC オーケストレータへ振り分ける。これは、コンテナバイトが ZIP マジックで始まり、そのままでは CAdES へフォールスルーしてしまうためである（crates/pverify-core/src/verify.rs、verify_with、約 195 行目: if !request.asic_signatures.is_empty()）。認識可能な ASiC コンテンツを持たない裸の ZIP は INDETERMINATE / asic_unsupported_container を生じる（約 225 行目）。XML 対 JSON のスニフは構造上衝突しない: XAdES 入力は < で始まり、JAdES 入力は { で始まる（356 行目、"JSON and XML are mutually exclusive on the first non-whitespace byte"）。

1.3.2 サポートする AdES ベースラインレベル

ETSI のベースラインレベル語彙（B-B/BES、B-T、B-LT、B-LTA）を正確に用い、ツールはフォーマットごとに実際にどのレベルを検証するかを明示する。

CAdES のフォーマット昇格梯子は crates/pverify-core/src/verify.rs の 1034〜1042 行目に実装されている: archive-time-stamp が存在すればワイヤフォーマットを CAdESLta へ昇格させる; さもなくば任意の LT/LTA ペイロードが CAdESLt へ昇格させる; さもなくば signature-time-stamp が CAdEST へ昇格させる; さもなくばフォーマットは CAdESBes である。

B-LTA / アーカイブ機構はフォーマットによって異なり、正確に名付けられている: CAdES は archive-time-stamp-v3（ETSI EN 319 122-1 §6.3.4、インプリント再計算を伴う; 不一致は archive_timestamp_imprint_mismatch、TOTAL_FAILED）を用い、PAdES は /DocTimeStamp（リビジョンの ByteRange 上の RFC 3161 トークンを担う PDF /Type /DocTimeStamp 辞書であり、pades_doc_timestamp という VRT 種別のタイムスタンプとして表出される）を用い、XAdES は xades:ArchiveTimeStamp（ETSI TS 101 903 v1.4.2 Annex A.1.5; インプリント = ds:Signature 要素全体の exc-C14N から同一署名内の後続 ArchiveTimeStamp が覆うノードセットを subtract したもの——ブランチ 036 で XadesUnverifiedTimestamp.imprint_input: Vec<u8> および bergshamra-c14n の node-set subtract API を用いて実装、SignatureFormat::XadesBLta を新設）を用いる。

1.3.3 サポート外バリアントに対する拒否挙動

誠実な拒否はレポートの第一級の結果であり、各々がクローズド列挙型の理由を伴う:

• detached/enveloping（enveloped ではない）であるか、または non-exclusive な正規化方式を用いる XAdES は、XadesProfile::Unsupported（理由 DetachedOrEnveloping または NonExclusiveC14n、crates/pverify-core/src/xades.rs、151 行目の UnsupportedReason）にマップされ、INDETERMINATE / xades_unsupported_profile（または正規化に固有のサブインディケーション）として表出する。一つの例外: ASiC で解決された detached XAdES は検証される。これは ASiC コンテナが解決済みのデータオブジェクトバイトを供給するためである（約 133 行目）。サポートされる形態は enveloped + Exclusive C14N（W3C exc-c14n）であり、監査済みの bergshamra-c14n クレートが提供する。
• JAdES の拒否は JadesUnsupportedReason を介して行われる: DetachedSigD（JWS sigD detached プロファイル）、CompactSerialization（JWS Compact）、HigherLevel（rfsTst/tstVd のみ——ブランチ 037 で B-T/B-LT/B-LTA を実装済み）、NotJadesBaseline。
• 複数署名者の CMS は、最初の署名者のみを報告するのではなく cms_multi_signer_unsupported で拒否される（§1.1.1 を参照）。
• 有効な ASiC コンテナでない認識不能な ZIP は asic_unsupported_container を生じる。

1.3.4 サポートする暗号プリミティブ

証明書、CRL、OCSP、TSA、および署名者の署名は、すべて RustCrypto のみのプリミティブを通じて検証され、crates/pverify-core/src/crypto.rs（verify_with_alg）において OID と SPKI 形状によってディスパッチされる。サポートする署名ファミリは次のとおりである:

• RSA PKCS#1 v1.5 および RSA-PSS（後者は verify_rsa_pss、151 行目を介して検証される; 約 284 行目の CMS OID テーブルは意図的に PSS を拒否するため、PSS は専用の PSS パスのみを流れる）。
• ECDSA P-256 / P-384（NIST 曲線; SHA-256/384/512 ダイジェスト）。
• Ed25519（RFC 8032 "pure"、RFC 8410 SPKI OID 1.3.101.112）。
• ML-DSA（FIPS 204; OID 2.16.840.1.101.3.4.3.17/18/19 の ML-DSA-44/65/87、216 行目の MlDsaParams）——先取り的なポスト量子ディスパッチ。

このセット外の署名アルゴリズムはすべて、INDETERMINATE における signature_algorithm_unsupported として表出する。本番の依存セットには署名鍵生成の面は存在しない——暗号は検証専用である。

1.3.5 pverify が規範として扱う標準

憲法 §IV（Specification-Compliance、NON-NEGOTIABLE）に従い、実装は以下を主要な規範的参照として扱い、いかなる逸脱も該当するフィーチャ仕様に書面の理由づけとともに列挙しなければならない:

• RFC 5280 —— X.509 証明書、CRL、および §6 パス検証（basic-plus アルゴリズム: 発行者／主体者 DN 照合によるパス構築、有効期間ウィンドウ、BasicConstraints、KeyUsage、名前制約 §4.2.1.10、および証明書ポリシー処理 §6.1）。
• RFC 5652 —— CMS SignedData（CAdES のコンテナであり、PAdES の埋め込みペイロード）。
• RFC 3161 / 5816 —— タイムスタンプトークン（TSP）。RFC 5816 ESS署名証明書バインディングを含む。
• RFC 6960 —— OCSP。§4.2.2.2 の指定レスポンダ認可、鮮度、およびノンス処理を含む。
• ETSI EN 319 102-1 —— 署名検証手順、およびインディケーション／サブインディケーションの値空間。
• ETSI EN 319 122 (CAdES) / 319 142 (PAdES) / 319 132 (XAdES) / TS 119 182 (JAdES) / 319 162 (ASiC) —— AdES コンテナフォーマット。
• eIDAS および EU トラステッドリスト標準 ETSI TS 119 612（pverify-eutl により取り込まれる）。
• CRYPTREC 電子政府推奨暗号リスト（主）および NIST SP 800-57 Part 1 / SP 800-131A（副）—— 憲法 v1.2.0 で批准されたアルゴリズムポリシーの典拠。
• デジタル庁 デジタル社会推進標準ガイドライン および JNSA デジタル署名検証ガイドライン（第 1.1 版） —— GPKI/日本プロファイル。pverify がオブジェクトごとの検証基準時刻（VRT）のために実装する §4 再帰的な外側カバー規則を含む。

1.4 スコープ外（明示的な非目標）

pverify は意図的に境界づけられている。以下は v1.x 系列のスコープ外であり、ビジョンステートメント §6 から引き、事実報告の原則によって補強される:

• 署名生成。 pverify は検証専用である; 署名は別プロジェクトの責務である。暗号レイヤは本番依存において署名鍵生成 API を持たない。
• 法的有効性／適格性の判定。 憲法 §I により禁止。pverify は「適格電子署名」「法的に有効」、またはいかなる証拠能力の主張も決して出力しない。
• JPKI（マイナンバーカード）署名検証。 JPKI は GPKI とは別個の PKI である; 現行系列のスコープ外（v2.0 以降の探究で再検討する候補）。
• ユーザ向け GUI。 pverify はライブラリ、CLI、および WASM モジュールとしてのみ出荷される; いかなる GUI も第三者に委ねられる。
• QTSP / QES 認証。 pverify は実装したチェックセットについて ETSI 適合を主張するが、適格トラストサービスプロバイダ認証は追求しない。

サポートするファミリ内のフォーマットレベルの除外も同様に明示的であり、クローズド列挙型の拒否として表出される（暗黙の合格ではない）: より高位の JAdES ベースラインレベル、detached/enveloping XAdES、non-exclusive C14N、複数署名者 CMS、およびサポートセット外のいかなる署名アルゴリズム（§1.3.3、§1.3.4）。ブランチ 034 の PAdES /DSS の作業も、DSS の生成、DSS /Certs のトラストアンカーへの昇格、VRI /TU//TS の内部整合性の検証、および otherRevInfo フィールドを明示的に除外する——これらは設計上スコープ外である。

1.5 設計目標 —— Pure Rust + WASM デュアルターゲットの立場

pverify における最も重大な単一の設計判断は、I/O を行わない、no_std + alloc の、WASM ビルド可能な検証カーネル（pverify-core）と、すべてのコンテナ／文書のパース、ネットワーク取得、ファイルシステムアクセス、およびクロック読み取りを行うホスト側クレート群との境界である。これは美的な好みではない; 憲法と経験的な CI ゲートによって強制される。それが供する目標は次のとおりである:

1.5.1 ライブラリファースト、I/O を行わないコア（憲法 §V）

pverify-core は、すべての暗号、RFC 5280 §6 パス検証、失効評価（CRL/OCSP）、タイムスタンプと VRT の導出、アルゴリズムポリシー評価、および ETSI インディケーション集約を行う。当該クレートは crates/pverify-core/src/lib.rs の冒頭（11〜12 行目）で #![no_std] と #![forbid(unsafe_code)] を宣言し、alloc クレートのみを取り込む（15 行目）。カーネルが自力で行えない三つのホスト関心事——検証クロック、失効情報、およびトラストアンカーセット——はトレイト経由で媒介される: crates/pverify-core/src/traits.rs 内の Clock（76 行目）、RevocationFetcher（98 行目）、TrustAnchorStore（139 行目）。カーネルはネットワーク、ファイルシステム、または環境クロックへのアクセスを一切行わない; その derive_vrt および derive_validation_objects 関数は純粋計算である。

1.5.2 コアでの文書パースを行わない（憲法 §V）

PDF、XML、ZIP、JSON は、重量級でしばしば unsafe を含み WASM クリーンでない依存を信頼コンピューティングベースへ引き込むことなしには no_std カーネル内でパースできないため、すべてのコンテナ／文書のパースはホストクレートで行われ、追加的な VerificationRequest フィールドを介してモデルに依存しないバイト構造をカーネルへ供給する（crates/pverify-core/src/verify.rs、69 行目以降: pdf_signature_dicts、pdf_validation_data、xades_components、jades_components、asic_signatures）。カーネルは、スニフされたフォーマットに一致するフィールドのみを参照する; 非 PDF 入力は空の pdf_validation_data を担う、等々。この境界は scripts/cargo-tree-gate.sh によって経験的に強制される。同スクリプトは cargo tree -e normal --no-default-features -p pverify-core を実行し、lopdf、zip、flate2、bergshamra-c14n、pverify-eutl、pverify-aatl、またはいずれかのホスト専用クレートがコアグラフに現れた場合にビルドを失敗させる。

1.5.3 WASM 互換性（憲法 §VI、NON-NEGOTIABLE）

pverify-core は wasm32-unknown-unknown 上でコンパイルおよび実行できなければならない。暗号は RustCrypto のみである: ring、aws-lc-rs、OpenSSL FFI、および rustls のデフォルトプロバイダは、コアまたは WASM グラフのいかなる箇所においても禁止される。これは cargo build --target wasm32-unknown-unknown -p pverify-core と cargo-tree ゲートによって経験的にゲートされる。pure Rust 暗号の立場は、先行プロジェクト civ（ビジョンステートメント §8.5）から継承されたものであり、同一のカーネルを CLI から Cloudflare Worker、ブラウザ内 WASM モジュールまで実行可能にしているものである。

1.5.4 CLI と WASM のパリティ

ネイティブ CLI（crates/pverify-cli）とブラウザ WASM ホスト（web/pverify-wasm）は、バイト単位で同一のホスト抽出器と同一の verify_with カーネルを実行し、同一の入力に対してバイト単位で同一のレポートを生成する。PAdES については、ネイティブ PDF パース（pverify-cli/src/pdf.rs、lopdf）とブラウザ内パース（web/pverify-wasm/src/lib.rs、lopdf）が同一の PdfSignatureDescriptor および同一の /DSS+/VRI 検証情報を抽出する; このパリティは、抽出器に対するパリティテストで担保される強制された不変条件である。

1.5.5 再現性とバイト単位の同一性（憲法 §II）

同一の入力（署名文書、トラストアンカー、検証時刻、および失効情報）に対して、pverify はいつどこで実行されてもバイト単位で同一の出力を生成する。検証時刻は --at <RFC3339> を介して注入可能であり、さもなくば CLI 起動時に一度だけ捕捉される; VRT エンジンはこの request_at 値のみを時刻源として読み取り、Clock::now を決して読まない。追加的なフィーチャを統べるさらなる不変条件: 追加的なフィーチャは、その入力が不在であるか無効化されている場合、schema_version 文字列を除いてレポート本体をバイト単位で同一に保たねばならない。例えば、/DSS を持たない PDF は、schema_version を除いて 034 以前の出力と同一のレポートを生成する（FR-008）; アルゴリズムポリシーは、オフ（デフォルト）のとき signatures[].algorithm_validity を不在にする; また埋め込み失効のフォールスルーは、ライブ/CDP チャネルが不確定な場合にのみ発火するため、オンラインの成功はバイト単位で同一のままである。

1.5.6 クローズドな約束としてのスキーマ

レポート形状は SemVer 文字列 SCHEMA_VERSION を担い、現在は "1.10.0" である（crates/pverify-core/src/report/schema.rs）。スキーマバージョニングの規律は厳格かつ追加的である: SubIndication、RevocationOutcome、および ValidationObjectOrigin 列挙型とレポート構造体はクローズドであり、ルートの report-schema.json に 1:1 でミラーされる。クローズド列挙型の値またはオプショナルフィールドの追加は MINOR バンプであり、いずれかの削除または転用は MAJOR である。非推奨となったバリアント（例: 歴史的な bridge_ca_required_unsupported）は、保存済みレポートのデシリアライズのために保持されるが、もはや出力されない。例えばブランチ 034 は、既存のバリアントの後に二つの ValidationObjectOrigin バリアント——PdfDss と PdfVri（crates/pverify-core/src/report/validation_objects.rs）——を、宣言順=ソート順として追加し、スキーマを 1.5.0 → 1.7.0 へとバンプした。続く追加的スライスも同じ規律を継続し、ブランチ 035 が OcspAttempt.request_der_hex 追加（1.7.0 → 1.8.0）と CdpEntry 構造化（1.8.0 → 1.9.0）を行い、ブランチ 037 が JAdES-B-T/JAdES-B-LT/JAdES-B-LTA など 3 つの新 SignatureFormat 値を追加（1.9.0 → 1.10.0）した。

README の開示ブロックに関する注記。リポジトリの README.md は v0.7 開発系列に固定された歴史的成果物である; その本文は schema_version が "1.1.0" のままであり、能力フェーズが "v0.6-bridge-acceptance" であると述べている。正規の現行値は report/schema.rs 内の SCHEMA_VERSION 定数（"1.10.0"）であり、そのドキュメントコメントが 1.0.0 から 1.10.0 までの各バンプを叙述している。読者は、現行リリースについては README ではなくソース定数を規範として扱うべきである。

1.6 横断的不変条件の概観

以下の不変条件は設計文書全体を通じて参照される; 後続の各章が名前で引用できるよう、ここで一度列挙する。各々はコードと憲法に根拠を置く。

1.7 文書の残りに対する読者向けガイド

本文書は、監査人が上から下へ通読することも、レビュー対象のサブシステムへ直接ジャンプすることもできるよう構成されている。以下の章番号は統合設計仕様を反映する; 後続の各章での相互参照はこれらの番号を用いる。

• 第1章（本章） —— 序論、スコープ、対象ユーザ、サポートするフォーマットおよび AdES レベル、pure Rust + WASM の立場、および横断的不変条件。
• アーキテクチャ各章 —— システムアーキテクチャ概観、11 構成員のクレートトポロジおよびホスト → クリーン → コアの依存方向、ならびに入力取得からレポートシリアライズに至るエンドツーエンドのデータフロー。これらは §1.5 の境界を具体的なクレートグラフと六段階の検証パイプライン（ホストパース → リクエスト組み立て → フォーマットディスパッチ → 署名ごとの検証 → オブジェクトごとの VRT → インディケーション集約 → レポートシリアライズ）へと敷衍する。
• パス検証の章 —— RFC 5280 §6 basic-plus: バックトラッキングを伴う深さ優先のパス構築と DER フィンガープリントによるサイクル検出、名前制約のステートマシン、証明書ポリシー処理、およびブリッジCA 相互認証証明書の経由（GPKI 省庁間ケース）。
• 失効の章 —— CRL（RFC 5280）および OCSP（RFC 6960）評価、ライブ/CDP チャネルが不確定な場合にのみ発火する埋め込み失効情報のフォールスルー、およびクローズドな RevocationOutcome 語彙。
• タイムスタンプ & VRT の章 —— RFC 3161/5816 トークン検証、およびオブジェクトごとの検証基準時刻を導出する再帰的な外側カバーエンジン。
• フォーマット別各章 —— CAdES、PAdES（ブランチ 034 の /DSS / /VRI / revocationInfoArchival 情報を含む）、XAdES、JAdES、ASiC。各々が、サポートする形態、拒否ケース、およびホスト抽出器を記述する。
• レポート & スキーマの章（第14章） —— クローズド列挙型の語彙、ETSI インディケーション集約の優先順位（aggregate_etsi）、validation_objects インベントリとその ValidationObjectOrigin 出所タグ、およびスキーマバージョニング規則。
• 適合性 & 再現性各章 —— JNSA 適合性ステートメントのクロスウォーク、CI ゲートのバッテリ（test、fmt+clippy、WASM ビルド、cargo audit/cargo vet、perf-gate、cargo-tree ゲート）、および再現性／バイト単位の同一性の保証。

本章が挙動（断定回避の原則、フォーマットの梯子、トレイト境界）を要約した箇所では、対応するサブシステムの章がフィールドレベルの詳細と障害モードの列挙を提供する。特定の判定を監査する読者は、まずレポートスキーマの章から関連するサブインディケーションを特定し、次いでその相互参照をたどってそれを生成するサブシステムへ進むべきである。

2. 設計原則とプロジェクト憲法

本章は本仕様書の残りの部分に対する規範的なアンカ（基準点）である。後続の各章 が特定のクレートやコードパスが何を行うかを記述するのに対し、本章はそれが なぜ許容されるのか——そして同程度に重要な点として、何を行うことが禁止されて いるか——を確立する。統制する文書は .specify/memory/constitution.md にあるプロ ジェクト憲法（バージョン 1.2.0、2026-06-10 批准、最終改正 2026-06-22）であ る。憲法はその場限りの慣習、README、レビュアの選好に優先する。「両者が矛盾する 場合は憲法が優先する」（Governance 節）。以下に引用する各原則は、当該ファイル から逐語的に再録し、そこで付されている条番号を併記する。

憲法は 7 つの Core Principles（中核原則 I–VII）、Technology Stack Constraints（技術スタック制約）節、Phased Path Validation Roadmap（段階的パス検 証ロードマップ）、明示的な Out-of-Scope（適用範囲外）一覧、および Governance／ バージョニングポリシーを定義する。本章の 2.1–2.10 節は、監査人が最も必要とする 順序でそれらの条項を順に辿り、各々をそれを強制するコードに結び付け、その後 2.11 節が（2.12 節が Out-of-Scope の境界を記録するとともに）アーキテクチャ概観（第3 章）と実装各章（第5章〜第13章）が繰り返し依拠する横断的不変条件を要約する。

用語に関する注記: 本書を通じて「カーネル」または「コア」は pverify-core クレ ートを指し、「ホスト」はその代理として I/O を行う任意のクレート（pverify-cli、 web/pverify-wasm、pverify-eutl、pverify-aatl、抽出系クレート群）を指す。 このホスト／カーネル分離を実現するクレートのトポロジは第3章で詳述する。本章は その分離の憲法上の根拠を説明する。

2.1 バージョン管理された検証可能な契約としての憲法

憲法はビジョンステートメントではない。それは独自のセマンティックバージョニング 体制（Governance → Versioning policy）の下にある、バージョン管理された契約である。

• MAJOR: 原則が削除される、非互換に再定義される、もしくは NON-NEGOTIABLE マーカが外される場合。または Out-of-Scope 項目が取り込まれる場合。
• MINOR: 新たな原則もしくは節が追加される場合、または既存の指針が実質的 に拡張される場合。
• PATCH: 明確化、文言、組版、または意味を変えない編集。

各改正は、バージョンの差分、影響を受けた原則、および SemVer 分類の根拠を記録す る「Sync Impact Report」コメントをファイル冒頭に伴う。直近の改正（1.1.0 → 1.2.0） はアルゴリズムポリシーのデフォルトテーブルを批准したものであり、当該レポートは NON-NEGOTIABLE マーカが外されておらず、Out-of-Scope 項目も取り込まれていないこ とを明示している。これがまさに、当該バンプが MAJOR ではなく MINOR である理由で ある。

7 つの原則のうち 3 つは NON-NEGOTIABLE とマークされている。すなわち I（事実 報告）、IV（仕様適合）、および VI（WASM 互換性）である。このマーカは load-bearing （負荷を担うもの）である。すなわち、それを外すことは定義上 MAJOR 改正となる。 憲法はまた、それ自体が憲法上の表面となるいくつかの値を固定している。アルゴリ ズムポリシーのデフォルトテーブル（§2.8）が顕著な例であり、そこではコード定数 pverify_core::algorithm_policy::AlgorithmPolicy::default_policy() が 「specs/032-algorithm-validity/contracts/default-policy.md（test C-3）と バイト単位で一致しなければならない（MUST）」とされている。これがプロジェクト全 体が従うモデルである。すなわち、原則は、それが侵されたときにテストが失敗する場 合に限って実在する。本章の残りの部分は、各原則について、その線を保持するコード とテストを特定する。

2.2 §I 事実報告／「断言できないことは断言しない」（NON-NEGOTIABLE）

原則 I はツール全体の哲学的背骨である。逐語的に引用する。

I. Fact-Reporting（NON-NEGOTIABLE）

pverify は観測した事実の構造化レポートを出力するものであり、「適格電子署 名（qualified electronic signature）」や「法的に有効（legally valid）」とい った業務上の判定を出力することは決してない。

• 出力 JSON は、参照したすべての成果物を列挙しなければならない（MUST）。すな わち、証明書チェーンの構成要素、取得した CRL／OCSP レスポンス／TSA トークン、 それらの出所、および各々に対して実施した評価である。
• ETSI EN 319 102-1 インディケーション（TOTAL_PASSED / INDETERMINATE / TOTAL_FAILED）は機械可読の指標として出力してよい（MAY）が、pverify はそれ をドメインの判定へ翻訳してはならない（MUST NOT）。
• pverify は、法的有効性、規制上の適格性、または許容性を主張するいかなるテキ ストやフィールドも出力してはならない（MUST NOT）。

根拠（Rationale）: 適格性は、保存期間、署名時と検証時の別、アーカイブ TS 要件、およびユーザごとに異なる相手方との合意に依存する。これらを先回りして 判定するツールは誤用を強いる。

この原則は、コードベース全体に浸透する 2 つの運用上の帰結を持つ。

2.2.1 判定ではなく列挙

レポートはインベントリであって、可否の二択ではない。カーネルは、参照したすべ ての証明書、CRL、OCSP レスポンス、タイムスタンプトークン——各々にその出所（プロ ビナンス）をタグ付けしたもの——から成る統合された資料インベントリを、 derive_validation_objects（crates/pverify-core/src/report/validation_objects.rs） において導出する。当該関数は、完成した &Report ツリーに対する純粋な読み取り （再計算なし）であり、すべてのオブジェクトについて、それがどこから来たかを記録す る。出所の語彙はクローズドな列挙 ValidationObjectOrigin （report/validation_objects.rs、98–118 行）である。すなわち signature_embedded、bundle、fetched_online、trust_anchor、 supplied_input、そして——PAdES /DSS+/VRI の作業のために追加された—— pdf_dss と pdf_vri である。これらのタグの要点は監査可能性（§2.4）にある。 読者は、ある CRL が使用されたという事実だけでなく、それがどこから取得された かをも知ることができる。これはまさに原則 I の「それらの出所」要件である。

2.2.2 「断言できないことは断言しない」: INDETERMINATE は第一級の結果である

第二の、より微妙な帰結は 断定回避の原則である。pverify がある事実を確立でき ない場合、失敗も合格も捏造してはならない（MUST NOT）。それは ETSI EN 319 102-1 の INDETERMINATE へと、精密でクローズドな列挙のサブインディケーションを伴っ て降格する。これは知らないことと答えが否定であると知っていることとの違いで あり、ツールは両者を一緒くたにすることを拒否する。トップレベルのインディケーシ ョンはクローズドな列挙 Indication （crates/pverify-core/src/report/etsi.rs）であり、その限定理由は同ファイル内の クローズドな列挙 SubIndication である。この原則の典型的な実例を以下に示す。

マルチサイナのケースは、この原則の能動的な強制の最も明快な例示である。素朴な 検証器は最初の SignerInfo のみを黙って報告するであろうが、pverify は意図的に これを拒否する。verify.rs:487 のコードコメントがその理由付けを記録しており、 cades_multi_signer_entry は部分的な合格ではなく INDETERMINATE / cms_multi_signer_unsupported のエントリを返す。これは断定回避を実行可能にした ものである。すなわち pverify は、完全に評価していない署名を断言しない。

同様に、失効した TSA 証明書は TOTAL_FAILED の偽造主張にはならない。033 の 作業は revoked_no_poe を導入した。失効したタイムスタンプ局は、そのタイムスタン プの存在証明（PoE）がもはや信頼できないことを意味するため、時刻のアンカが利用 不能となる——これは不確定性であって、署名の偽造が証明されたわけではない。これを TOTAL_FAILED ではなく INDETERMINATE として符号化することは、§I の直接的な適用で ある。「証明済みの失敗を決して覆い隠さない」を強制する集約処理については §2.11 で述べる。

2.2.3 法的判定を出力しない

第三の項目——法的有効性、適格性、または許容性の主張をしないこと——は、欠落によ って遵守される。すなわち、レポートスキーマ（report-schema.json、 crates/pverify-core/src/report/ からミラーされたもの）は qualified、 legally_valid、admissible といったフィールドを持たず、インディケーションの 列挙は 3 つの ETSI 値で止まる。根拠条項は憲法としては異例なほど明示的である。 すなわち適格性は「保存期間、署名時と検証時の別、アーカイブ TS 要件、およびユー ザごとに異なる相手方との合意に依存する」。pverify はそれらの判断が拠って立つ事 実を報告する。その判断そのものは行わない。

2.3 §II 再現性と判定のバイト同一性

II. Reproducibility（再現性）

同一の入力（署名文書、トラストアンカー、検証時刻、および失効情報）に対して、 pverify はいつどこで実行されるかにかかわらず、バイト単位で同一の出力を生成し なければならない（MUST）。

• 検証時刻は注入可能でなければならない（MUST）（--at <RFC3339>）。これは署 名時評価および歴史的評価を支援するためである。
• すべてのネットワーク I/O はトレイトによって媒介されなければならない（MUST）。 これにより --from-bundle 呼び出しが、外部呼び出しなしに以前の実行を再現で きるようにする。
• 非決定的なデータソース（システムクロック、環境依存の TLS ルート、ランダム化 された順序付け）はレポートに影響を与えてはならない（MUST NOT）。

再現性は、検証レポートを証拠たらしめる性質である。憲法は再現性のタプルを精密 に定義する。すなわち （署名文書、トラストアンカー、検証時刻、失効情報） であ る。このタプルが与えられれば、出力は実時間、ホスト、またはネットワーク到達性に かかわらずバイト単位で同一である。

2.3.1 注入可能な時刻、一度だけ捕捉される

CLI は起動時に検証時刻をちょうど一度だけ捕捉する（あるいは --at から取得し、 これは常に優先される）。そしてそれを request_at としてスレッドを通す。カーネル は検証ロジックのために実時間クロックを決して読まない—— crates/pverify-core/src/vrt/ 内のオブジェクトごとの VRT エンジンは、基準時刻を request_at および構造内に存在するタイムスタンプトークンのみから導出し、 Clock::now() からは決して導出しない。Clock トレイト （crates/pverify-core/src/traits.rs:76）はホスト側の配管のために存在するので あって、検証の決定のためではない。この分離こそが --at <RFC3339> による歴史的評 価を決定的にするものである。

2.3.2 トレイト経由の I/O ⇒ --from-bundle の再現性

カーネルが持つあらゆる外部依存——クロック、失効情報、トラストアンカー——はトレイ トである。すなわち Clock、RevocationFetcher、TrustAnchorStore （crates/pverify-core/src/traits.rs、76、98、139 行）である。カーネルはそれ自 体ではネットワーク、ファイルシステム、クロックへのアクセスを行わない。これが --from-bundle をして、外部呼び出しゼロで以前の実行を再生させることを可能にす る。すなわちバンドルは、元の実行が取得したのと同じ失効情報を、同じ RevocationFetcher トレイト面を通して再供給する。バンドルに対して再実行する独 立した監査人は同一のレポートを得る——これはまさに §III（§2.4）の監査可能性の保証 である。

2.3.3 追加的／無効化された機能における判定のバイト同一性

プロジェクトが積極的に強制する系として、追加的機能の下でのバイト同一性があ る。ある機能が無効化されている場合、またはその入力が存在しない場合、レポート本 体は schema_version 文字列を除いて、直前のリリースとバイト単位で同一でなけれ ばならない（MUST）。具体例を以下に示す。

• /DSS を持たない PDF は、034 以前のベースラインと schema_version のみが異な るレポートを生成する（034 の FR-008 要件）。PAdES の検証データフィールドは VerificationRequest 上の追加的な Vec／Default であり、非 PDF および no-DSS 入力に対しては空である。
• アルゴリズムポリシーが無効（デフォルト）の場合、schema_version を除いて 032 以前のレポートとバイト単位で同一の本体を生成する（032 の SC-001 要件、§2.8）。
• 埋め込み失効情報のフォールスルーは、ライブ／CDP チャネルが不確定の場合にのみ 発火する（019 の先例）。したがって、オンラインのライブ取得の成功は、埋め込み情 報が存在したか否かにかかわらず、バイト単位で同一のままである。

この規律こそ、各追加的スライスが schema_version を MINOR インクリメントで バンプし、共通パスにおいてはそれ以外に何も変わらない理由である。現在のレポート 形状のバージョンは SCHEMA_VERSION = "1.10.0" （crates/pverify-core/src/report/schema.rs:line）である。

2.3.4 環境依存の非決定性なし

憲法は、システムクロック、環境依存の TLS ルート、およびランダム化された順序付け がレポートに影響を与えることを明示的に禁止する。トラストアンカーは明示的に供給 される（--trust-anchors <DIR>、もしくは pverify-eutl／pverify-aatl が通常の アンカーへと取り込んだもの）のであって、OS のトラストストアから読まれることは決 してない。カーネルは no_std（§2.6）であり、したがって環境依存の OS 状態へのア クセスを一切持たない。

2.4 §III 監査可能性 — 検証バンドル

III. Auditability（監査可能性）

検証の実行は、使用したすべての証明書、CRL、OCSP レスポンス、および TSA トーク ンを埋め込んだ自己完結型の「検証バンドル」を出力できなければならない（MUST）。 これにより、独立した第三者がバンドルに対して pverify を再実行し、同じレポート を得られるようにする。

監査可能性は、再現性（§II）と事実報告（§I）を組み合わせた運用上の成果である。 カーネルは I/O を行わず、トレイト経由であるため、CLI はオンライン実行中に参照し た成果物の完全な集合を捕捉し、それらをバンドルディレクトリ（<bundle>/crls、 <bundle>/ocsp、<bundle>/trust-anchors）として実体化できる。そして後続の --from-bundle 実行は、同じ RevocationFetcher／TrustAnchorStore トレイトを通 してそれらを再生する。統合された validation_objects インベントリ（§2.2.1）は、 何が、どの出所で使用されたかを正確に示すレポート内のマニフェストである。したが って第三者はバンドルの内容をレポートと突き合わせて検証できる。 ValidationObjectOrigin の bundle 値はバンドルから来た資料を示す。from_bundle モードにおいては、あるオブジェクトは判明している場合にはその元の出所を保持する （report/validation_objects.rs の L303 周辺のコメント）。したがって監査の連鎖は 閉じている。すなわち レポート → マニフェスト → バンドル → 再実行 → 同一のレポー ト である。

これを実現する CLI モードはクローズドな Mode 列挙 {Online, Offline, FromBundle}（pverify-cli/src）であり、カーネルの失効 VerificationMode へとマップされる。モードの配管については第3章を参照のこと。

2.5 §IV 仕様適合（NON-NEGOTIABLE）

IV. Specification-Compliance（仕様適合、NON-NEGOTIABLE）

実装は以下を主要な規範的リファレンスとして扱う。

• RFC 5280（X.509、CRL、§6 パス検証）
• RFC 5652（CMS）
• RFC 3161 / 5816（TSP）
• RFC 6960（OCSP）
• ETSI EN 319 102-1（署名検証手続）
• ETSI EN 319 122 / 319 142（CAdES / PAdES）。319 132（XAdES、v0.4+）
• デジタル庁 デジタル社会推進標準ガイドライン（GPKI 規定）
• JIS X 5092 / 5093（CAdES / XAdES の日本語訳）

振る舞いの正しさは、公開されたテストベクタを通じて実証されなければならない （MUST）。すなわち ETSI 適合性スイート、デジタル庁が公開したサンプル、および プロジェクトが保守するゴールデンケースである。いずれかのリファレンス文書から の逸脱は、該当する機能仕様において文書化された根拠とともに列挙されなければなら ない（MUST）。

この原則は規範的コーパスを固定し——そして決定的に重要なことに——正しさが公開され たテストベクタによって実証されることを要求する。主張するだけでは足りない。標準 → 実装モジュールの対応付けは第5章〜第13章の主題である。本節はその契約と、§IV が 拘束力を持たせる AdES レベルの語彙を記録する。

2.5.1 標準からモジュールへの対応表（方向付け）

2.5.2 誠実な AdES レベルの語彙

§IV の「逸脱は……文書化された根拠とともに列挙されなければならない」条項こそ、 pverify が一律のサポートを主張するのではなく、各フォーマットの実際にどのレベル を検証するかについて精密である理由である。サポート行列を、 verify.rs:1034-1042 のフォーマット昇格ラダーおよびフォーマットごとの検証器に 根ざして以下に示す。

これらの拒否はバグではない。それらは §I／§IV の協働である——ツールは実装していな いレベルを断言することを辞退し、その逸脱は対応する機能仕様において列挙される。 詳細は第5章（CMS/CAdES）、第6章（PAdES）、第7章（XAdES/ASiC）、第8章（JAdES）を 参照のこと。

2.6 §V ライブラリファースト と §VI WASM 互換性（NON-NEGOTIABLE）

これら 2 つの原則はアーキテクチャの要石であり、併せて読むのが最良である。

V. Library-First（ライブラリファースト）

pverify-core は I/O を行わない no_std + alloc ライブラリとして実装されなけ ればならない（MUST）。これにより CLI バイナリと Cloudflare Workers のリファレ ンスビルドが単一のコアの上に座るようにする。ネットワークアクセス、時刻、およ びトラストアンカーの保管は、コアに焼き付けられるのではなく、ターゲットごとに実 装されるトレイト——RevocationFetcher、Clock、TrustAnchorStore——として 表現されなければならない（MUST）。

VI. WASM Compatibility（WASM 互換性、NON-NEGOTIABLE）

オプションのネイティブ専用アクセラレーションパスを除き、pverify-core は wasm32-unknown-unknown 上でコンパイルおよび実行できなければならない（MUST）。

• ring、aws-lc-rs、および OpenSSL FFI 依存は、コアにおいて、ならびにコアも しくは Workers ビルドが推移的に引き込む任意のクレートにおいて禁止される （PROHIBITED）。純 Rust の RustCrypto エコシステムのみが許容される。
• Workers ビルドは、バンドルサイズを削減するためにハッシュ計算と公開鍵検証を Web Crypto の SubtleCrypto API に委譲してよい（MAY）。ただし、その結果出力 が原則 II の下でネイティブパスとバイト単位で同一に保たれることを条件とする。
• 禁止された依存を再有効化するフィーチャフラグの追加（例: デフォルトフィーチャ 付きの rustls、civ の vp-federation）は禁止される（PROHIBITED）。

2.6.1 カーネルは no_std、unsafe-free、I/O-free である

crates/pverify-core/src/lib.rs の最初の 3 行が、両原則の強制である。

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

#![no_std] は、カーネルが OS に触れること（std::fs なし、std::net なし、 SystemTime なし）を構造的に不可能にする。#![forbid(unsafe_code)] は、いかな る unsafe ブロックに対しても強制的なコンパイルエラーとなる——allow による上書 きは存在しない。カーネルは alloc のみを使用する。それが真に必要とするホスト的 関心事は、traits.rs 内の 3 つのトレイト（§2.3.2）であり、ネイティブターゲット 向けに一度、WASM 向けに一度実装される。

2.6.2 コア内でコンテナを解析しない

no_std の直接的な帰結は、カーネルが PDF、XML、ZIP、または JSON を解析できないこ とである——それらは重量級の std リンクされたライブラリ（lopdf、quick-xml、 zip/flate2）を必要とする。したがって、すべてのコンテナ／文書の解析はホスト 側で行われ、追加的な VerificationRequest フィールドを介してモデルに依存しな いバイト構造をカーネルへ供給する。PAdES 署名辞書および /DSS+/VRI 資料は pverify-cli/src/pdf.rs（ネイティブ、lopdf）とバイト単位で同一の web/pverify-wasm/src/lib.rs（ブラウザ、lopdf）によって抽出され、XAdES は pverify-xades によって、ASiC は pverify-asic によって、JAdES は pverify-jades によって抽出される。カーネルは、自身が検出したフォーマットに一致 するフィールドのみを参照する。

2.6.3 経験的なガード

原則 VI は「コアが……推移的に引き込む任意のクレートにおいて」と述べる——これは 依存関係グラフについての言明であり、プロジェクトはこれを信仰によってではなく 経験的に強制する。

1. WASM へのコンパイルゲート。 cargo build --target wasm32-unknown-unknown -p pverify-core が成功しなければならない。いずれかの推移的依存が wasm32 でビル ド可能でない場合（ring/getrandom/ネイティブ FFI を引き込むため）、これは失 敗する。
2. scripts/cargo-tree-gate.sh。 このスクリプトは cargo tree -e normal --no-default-features -p pverify-core を実行し、いずれ かのホスト専用クレートがコアの本番グラフに現れた場合にビルドを失敗させる （exit 1、117 行）。すなわち pverify-eutl（L50）、pverify-aatl/lopdf （L76）、pverify-asic/zip/flate2/miniz_oxide、pverify-jades、 pverify-anchor-inventory、pverify-test-helpers、xtask である。PASS メッ セージ（L120）は、不在を確認した対象を正確に列挙する。

暗号の制約は依存選択によって実現される。カーネルの暗号依存は RustCrypto のみ （der、x509-cert、rsa、p256、p384、ed25519-dalek、ml-dsa、 sha1/sha2、spki、pkcs1、x509-ocsp）であり、すべて検証専用である——本番 グラフには署名や鍵生成の面は存在しない。web/pverify-wasm クレートはルートワーク スペースから意図的に切り離されている（その Cargo.toml 内の空の [workspace] テーブル。根拠は 3–9 行に記録）。これにより wasm-bindgen が生成する unsafe をルートの unsafe_code = "forbid" lint 面の外に保ち、また wasm グラフを リリースされる cargo test --workspace / cargo audit の面の外に保つ。完全なト ポロジと WASM ホストについては第3章を参照のこと。

2.6.4 CLIとWASMのパリティ

「単一のコア」（§V）の成果は CLIとWASMのパリティである。すなわちネイティブ CLI とブラウザホストは同一の verify_with カーネル （crates/pverify-core/src/verify.rs:178）とバイト単位で同一の抽出器を実行し、同 一の入力に対してバイト単位で同一のレポートを生成する。§VI の第二の項目で許容され る Web Crypto への委譲は、同じバイト同一性のルールによって制約される。すなわち、 いかなる SubtleCrypto アクセラレーションも「原則 II の下でネイティブパスとバイト 単位で同一に保たれなければならない」。パリティは抽出器の出力形状に対するテストに よって固定されており、これは強制された不変条件として扱われる（第3章を参照）。

2.7 §VII オフラインファーストとオフラインの誠実性

VII. Offline-First（オフラインファースト）

CLI は --offline モードをサポートしなければならない（MUST）。このモードでは、 署名に埋め込まれた資料（DSS / VRI 辞書、アーカイブタイムスタンプ）と、設定され たトラストアンカーのみを用いて検証が進行する。ネットワークアクセスは明示的な オプトインでなければならない（MUST）。verify --from-bundle のデフォルトの姿勢 は完全にオフラインである。

オフラインファーストには、プロジェクトが名付けられた不変条件にまで高める微妙な倫 理的な角がある。すなわちオフラインの誠実性である。--offline モードにおいて、 ツールは決して行わなかったレスポンダ接触を捏造してはならない。以前のある実装は、 オフラインであって OCSP レスポンダに到達できないとき、ocsp_responder_unreachable を出力していた——これは接触が試みられて失敗したかのように誤って示唆する。それは §I／§VII の侵犯であった。すなわち誠実な事実は「オフラインであるため失効検証が行わ れなかった」であって、「レスポンダがダウンしている」ではない。その是正は IndeterminateRevocationOffline の結果 → revocation_not_checked_offline サブイ ンディケーション（crates/pverify-core/src/revocation/mod.rs、~L657–667。 ocsp_attempt: None フィールドが接触の不在を明示する）である。オフラインモード はソケットを一切開かない。

これは §2.3.3 の埋め込み資料のフォールスルーとかみ合う。埋め込まれた DSS/VRI/revocationInfoArchival チャネル（ブランチ 034 の時点で PAdES 向けに消費 される）は、ライブ／CDP チャネルが不確定の場合にのみ発火する。--offline モー ドにおいてそれは常にそうであるため——証拠が十全に揃ったオフラインの PAdES-LT/LTA は、自身の埋め込み資料から definitive な結果に到達でき、一方その資料を欠く PDF は誠実に revocation_not_checked_offline へと降格する。--from-bundle のデフォル トの姿勢は、構成上、完全にオフラインである（バンドルが唯一の資料源である）。

2.8 アルゴリズムポリシー強制の適用範囲（憲法上の表面）

憲法の Phased Path Validation Roadmap 節は、異例なほど指示的な条項—— アルゴリズムポリシー強制の適用範囲——を含む。これはポリシーテーブルが憲法上 の表面であると宣言されているためである。すなわちそれを変更することは改正であっ て、コード編集ではない。一般条項は次のように述べる。

あるリリースがアルゴリズムポリシー強制（弱いアルゴリズムの存在が ETSI インディ ケーションを降格させるモード）を導入する場合、それはオプトインでなければなら ない（MUST）。デフォルトの振る舞いは v0.1 の事実報告の姿勢（原則 I）に留まらな ければならない（MUST）。正確なポリシーテーブル……は憲法上の表面である——追加 または再分類は憲法改正を要する。

その後、1.2.0 改正が具体的なテーブルを批准した。3 つの制約が実装を拘束する。

1. オプトイン、デフォルト無効。 モードは --algorithm-policy [FILE] によって のみ有効化される。デフォルト無効のレポートは、schema_version を除いて 032 以 前の本体とバイト単位で同一である（§2.3.3）。これは §I をデフォルトの姿勢として 保つ。
2. VRT スコープ。 オブジェクトごとの VRT エンジン（031）が基準時刻を導出する 各オブジェクト——署名者チェーン、署名者の署名、および各署名／アーカイブ／文書タ イムスタンプ——は、実時間に対してではなく、その オブジェクトの VRT value 時 点で有効なポリシーに対して判定される。「D 以降は許容不可」とは、当該オブジェ クトはその VRT 日付が厳密に D より前である場合に限り合格することを意味する。
3. INDETERMINATE に降格し、決して TOTAL_FAILED にしない。 失敗または断言不能な アルゴリズム結果は、crypto_constraints_failure_no_poe（ETSI EN 319 102-1 の CRYPTO_CONSTRAINTS_FAILURE_NO_POE を反映）を伴う INDETERMINATE を生む——教 科書的な断定回避（§2.2.2）である。弱いアルゴリズムは、その証明を断言できないこ とを意味するのであって、偽造を証明するものではない。

批准されたデフォルトテーブル（憲法 §「Algorithm-policy enforcement scope」）は、 CRYPTREC 電子政府推奨暗号リストを一次権威とし、NIST SP 800-57 Part 1 / SP 800-131A を二次権威とし、バージョンは 2026-06-default であり、認識されない OID または判定不能な鍵長を INDETERMINATE として扱う（決して暗黙の合格にはしない）。

コード定数 AlgorithmPolicy::default_policy()（crates/pverify-core/src/algorithm_policy/ 内）は「specs/032-algorithm-validity/contracts/default-policy.md（test C-3）と バイト単位で一致しなければならない（MUST）」。これはプロジェクトの「原則は、それを 強制するテストがある場合に限って実在する」という立場（§2.1）の最も強い形である。 すなわち憲法とコードがバイト比較テストによって結び付けられている。評価エンジンに ついては第13章（アルゴリズム妥当性ポリシー）を参照のこと。

2.9 段階的パス検証ロードマップと必須の開示

§IV のロードマップ節は RFC 5280 §6 を段階的に提供し、交渉不可能な開示ルールを伴う。

すべてのリリースは、機械可読の形で、実装する段階（phase）を出力しなければなら ない（MUST）。これにより消費者が、より早い段階を完全な検証と取り違えることがで きないようにする。

当初の v0.1 MVP は基本的なパス構築を出荷し、ブリッジCAチェーンが未対応であること を示す構造的フラグの設定が要求されていた。

Phase 1 の必須開示。 v0.1 MVP の出力は、ブリッジCAチェーンが未対応である ことを示す構造的フラグを設定しなければならない（MUST）。このフラグの抑制は、提 示上の選択ではなく憲法違反である。……当該フラグが true に反転してよいのは、 v0.3 が名前制約とポリシー処理の下でのブリッジCA走査を出荷したときに限る。

これは §I（事実報告）をツール自身の能力に適用したものである。すなわち pverify は、消費者が部分的な検証を完全な検証と取り違えることを許してはならない。現在のリ リースは v0.3/v0.4+ の帯域に到達している——名前制約 （path/name_constraints.rs、RFC 5280 §4.2.1.10）、ポリシー処理 （path/policy.rs、§6.1 valid_policy_tree）、ブリッジCA走査 （path/bridge.rs）、archive-time-stamp-v3 のインプリント再計算（EN 319 122-1 §6.3.4）、XAdES、OCSP、およびオブジェクトごとの VRT エンジンがすべて実装されてい る。歴史的な bridge_ca_required_unsupported サブインディケーションは、保存された レポートのデシリアライズのためだけに SubIndication 列挙（report/etsi.rs:63） 内に保持されている——非推奨だが削除はしないバリアントであり、追加的なスキーマバー ジョニングのルール（§2.10）と整合する。

2.10 追加的スキーマバージョニング

レポート形状は公開された契約である（リポジトリルートの report-schema.json。 crates/pverify-core/src/report/ から 1:1 でミラーされる）。クローズドな列挙—— SubIndication、RevocationOutcome、ValidationObjectOrigin——とレポート構造体は すべてその一部である。憲法のガバナンス SemVer から導出され、レポートスキーマに 具体的に適用されるバージョニングルールは以下のとおりである。

• MINOR（追加的）: クローズドな列挙値またはオプショナルフィールドを追加するこ と。本体は、新しい値を行使しない入力に対してはバイト単位で同一のままである （§2.3.3）。例: ValidationObjectOrigin に pdf_dss／pdf_vri を追加 （report/validation_objects.rs:113,118）し、SCHEMA_VERSION を 1.5.0→1.7.0 にバンプすること。
• MAJOR（破壊的）: 値またはフィールドを削除または転用すること。

監査人にとって決定的に重要な細部: 列挙の宣言順序がソート順序である。新しい pdf_dss／pdf_vri バリアントは（割り込ませるのではなく）末尾に追加された。 これにより derive_validation_objects におけるインベントリの導出が、出所 → 位置を、 既存バリアントの相対順序を乱すことなくマップする——新しいタグを使用しないレポート について、インベントリのバイト同一性を保つ。非推奨のバリアント（例: bridge_ca_required_unsupported、§2.9）は保存されたレポートのデシリアライズのため に保持されるが、現在のコードパスからは出力されない。SCHEMA_VERSION は crates/pverify-core/src/report/schema.rs:line にあり、現在 "1.10.0" である。その 系譜 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 構造化 + aia_ocsp_uris） は、追加的スライスごとに 1 つの MINOR バンプである。

2.11 横断的不変条件（リファレンス）

以下の不変条件は第5章〜第13章を通じて繰り返し現れる。それらは上記の各原則から導出 され、それらに遡及可能である。本節はその正典たるリファレンス一覧である。各々は、 それが奉仕する原則と、それを強制するコードを引用する。

2.11.1 決して覆い隠さない規律（不変条件 16、敷衍）

不変条件 16 は、それが「断言できないことは断言しない」と「失敗を過少報告しない」が 出会う場所であるため、締めくくりの注記に値する。aggregate_etsi（verify.rs:2343） は重大度順序付けされたベースインディケーション（TOTAL_FAILED > INDETERMINATE > TOTAL_PASSED、最初に見つかったものが優先）を確立する。後続のレイヤ——署名者バイン ディング、コンテンツタイプ、オプトインのアルゴリズム妥当性レイヤ、および TSA 失効レイヤ——は、TOTAL_FAILED でないベースを降格することのみができ、 証明済みの TOTAL_FAILED を決して覆い隠さない。これは、証明済みのメッセージ ダイジェスト不一致や ESS 証明書置換防御が、後続レイヤの不確定性によって黙って INDETERMINATE に格下げされ得ないことの形式的保証である。これにより §I の 2 つの半 分が同時に遵守される。すなわち pverify は決して失敗を捏造せず（断定回避の側、不変 条件 1）、また実在する失敗を決して隠さない（決して覆い隠さない側、不変条件 16）。

2.12 適用範囲外（v1.0 まで）とガバナンスの境界

憲法は明示的な Out-of-Scope 一覧で締めくくられる。いずれかの項目を取り込むことは、 バージョニングポリシーにより MAJOR 改正である。

• 署名生成。 pverify は検証専用であり……
• JPKI（マイナンバーカード）署名検証。 v2.0+ で追跡される……
• 法的有効性の判定。 原則 I により除外される。
• エンドユーザ GUI。 CLI、ライブラリ、および HTTP API のみ……
• 適格トラストサービスプロバイダ（QTSP）認定。 ETSI への整合は主張される。 認定は追求されない。

これらのうち 2 つは、単なるポリシーではなく構造的なものである。すなわち、検証専用 であることは、本番依存関係グラフに署名／鍵生成の面が存在しないことを意味し （§2.6.3）、法的有効性の判定が「原則 I により」除外されることは、§2.2.3 で述べた のと同じ境界である。

ガバナンスは開発プロセスを憲法に縛り付ける。すべての /speckit-plan は「上記の 原則に対する Constitution Check を実行しなければならない（MUST）」。文書化された違 反は、プランの Complexity Tracking 節において明示的な正当化とともに列挙されなけれ ばならない。そして「pverify-core、Workers ビルド、またはトラストアンカー処理に 触れるプルリクエストは、どの原則が検証されたかを引用しなければならない（MUST）」。 憲法は境界を定める。機能ごとの運用上の細部は各 specs/<feature>/plan.md に存在し、 （規範的でない）歴史的根拠は docs/vision-statement.md に存在する。現在の憲法バー ジョンは 1.2.0、2026-06-10 批准、最終改正 2026-06-22 である。

残りの各章は厳密にこれらの境界内で動作する。第3章は §II/§III/§V/§VI/§VII を実現す るクレートのトポロジ、データフロー、CLI モード、および WASM ホストを詳述する。そし て第5章〜第9章は §IV が固定する RFC 5280 / RFC 5652 / CMS / AdES 検証とパス検証を 詳述する。

3. システムアーキテクチャ

本章では、pverify の構造的構成について述べる。すなわち、クレートのトポロジーとその 依存関係の規律、I/O を行わない検証カーネルとそのホスト群との間にある荷重を担う境界、 2 つの具体的な実行モデル（ネイティブ CLI とブラウザ内 WebAssembly）、検証カーネル pverify-core の内部モジュール構成、そして VerificationRequest が生の入力バイト列 からクローズドスキーマの JSON 事実報告へと至る端から端までの経路である。以下のあらゆる 主張はソースツリーに根拠を置いており、レビューアが主張を直接監査できるよう、ファイル参照 および関数参照を付している。

本章が判定（verdict）やサブインディケーションの意味に触れる箇所では、その主題を所掌する 各章へ委ねる。すなわち、ETSI インディケーションの集約（第5章 §5.7 および Result Model の章）、形式ごとの検証セマンティクス（CAdES, PAdES, XAdES, JAdES, ASiC の各章）、 RFC 5280 パス検証（パス検証の章）、失効検証（失効検証の章）、そして報告スキーマと バージョニング（報告スキーマの章）である。相互参照では「… の章を参照」という語を用いる。 本ファイルを超える章番号付けは別途編纂されるためである。

3.1 アーキテクチャの意図と中心的な境界

pverify は、日本の GPKI/JNSA プロファイルおよび欧州の eIDAS/ETSI 体系に照らして 高度電子署名（AdES）を検証し、業務上の「有効／無効」判定ではなく事実報告を出力する。 システム全体を秩序づける、唯一の妥協を許さないアーキテクチャ上の境界は、以下の分離である。

• 検証カーネル — pverify-core — これは no_std + alloc であり、unsafe を 禁止し、I/O を一切行わず、wasm32-unknown-unknown 上でコンパイルおよび実行できなければ ならない。
• ホストクレート群の集合 — これがあらゆるコンテナ／文書のパース、あらゆる ネットワーク取得、あらゆるファイルシステムアクセスを行い、しかる後にカーネルへと 純粋でモデルに依存しないバイト構造を供給する。

pverify-core/src/lib.rs は冒頭の数行でこれを具体化している。

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

（crates/pverify-core/src/lib.rs:11-15）。

カーネルは、すべての暗号処理、RFC 5280 §6 パス検証、失効評価、RFC 3161/5816 タイムスタンプ検証、オブジェクトごとの検証基準時刻（VRT）の導出、オプトインの アルゴリズムポリシー評価、そして ETSI EN 319 102-1 インディケーション集約を実行する。 しかしカーネルは、外界へのアクセスを要するために自前では実行できない 3 つのことがある。 すなわち、検証クロックの読み取り、失効情報の取得または照会、そしてトラストアンカー集合の 列挙である。これら 3 つの関心事 — そしてこれらのみが、 crates/pverify-core/src/traits.rs においてケイパビリティトレイトの背後に抽象化される。 すなわち Clock、RevocationFetcher、TrustAnchorStore である。カーネルは &dyn TrustAnchorStore および &dyn RevocationFetcher の参照を保持し、それらを通じて 呼び出す。カーネルがソケットを開いたり、ファイルを読んだり、SystemTime::now() を呼んだり することは決してない。

この境界は努力目標ではない。scripts/cargo-tree-gate.sh（§3.2.2 で述べる）と、 ゲートバッテリー中の cargo build --target wasm32-unknown-unknown -p pverify-core ステップによって、経験的に強制される。その背後にある憲章上の原則は、§V（ライブラリ ファースト：コアでの文書パース禁止）、§VI（WASM クリーンなコア、妥協不可）、および §I （事実報告）である。憲章は .specify/memory/constitution.md を参照のこと。

3.1.1 なぜこの境界が存在するのか

3 つの性質がこの境界から導かれ、そのいずれも政府の顧客が独立して検証できる。

1. 決定性／再現性（§II）。 カーネルはクロックもネットワークも読まないため、 （入力バイト列、トラストアンカー、検証時刻、失効情報）という所与のタプルは、いつ どこで実行されようともバイト単位で同一の報告を生み出す。検証時刻はホストによって一度だけ 捕捉される（CLI は --at が与えられない限り起動時に一度だけ SystemTime::now() を 読む）、そして VerificationRequest を通じて引き渡される。

2. 監査可能な暗号サーフェス（§VI）。 すべての暗号処理は RustCrypto である。 カーネルや WASM グラフのいずれにも、ring、aws-lc-rs、OpenSSL FFI、デフォルトの rustls は存在しない。検証に用いられる暗号プリミティブは、RSA PKCS#1 v1.5、 RSA-PSS、ECDSA P-256/P-384、Ed25519、および ML-DSA であり、 crate::crypto::verify_with_alg（crates/pverify-core/src/crypto.rs）において OID と SubjectPublicKeyInfo によりディスパッチされる。本番の暗号サーフェスは 検証専用である — 本番依存関係には署名処理や鍵生成の経路は存在しない。

3. ネイティブとブラウザで同一の挙動。 カーネルが検証の真実の唯一の源泉であり、かつ WASM ビルド可能であるため、ネイティブ CLI とブラウザ内デモは同じ抽出済み構造に対して 同じ verify_with 関数を実行し、同一の入力に対してバイト単位で同一の報告を生み出す （「CLI と WASM のパリティ」不変条件、§3.5）。

3.1.2 「断言できないことは断言しない」の規律

システム全体は、憲章 §I に由来する「断言できないことは断言しない」という規則に 統べられている。pverify がある事実を確立できない場合、TOTAL_FAILED や TOTAL_PASSED を捏造するのではなく、精密なクローズドな列挙（閉じた語彙）の サブインディケーションを伴って INDETERMINATE へと格下げする。アーキテクチャが推測 ではなく誠実に表出する具体例を以下に挙げる。

• キャッシュ済み失効情報のないオフライン実行 → IndeterminateRevocationOffline / revocation_not_checked_offline（レスポンダ接触を捏造することは決してない — 憲章 §VII オフラインの誠実性）。
• 未対応の署名アルゴリズム OID → 失敗ではなく INDETERMINATE。
• マルチ署名者 CMS → INDETERMINATE / cms_multi_signer_unsupported （crates/pverify-core/src/verify.rs:496）。暗黙に切り詰められた署名者集合に対する 判定を下すことは決してない。
• 失効した TSA 証明書 → revoked_no_poe（INDETERMINATE）。偽造の主張ではない。

サブインディケーションの値空間は単一のクローズドな Rust 列挙 （crates/pverify-core/src/report/etsi.rs、SubIndication）であり、ルートの report-schema.json に 1 対 1 で写し取られている。報告形状のバージョンは SCHEMA_VERSION = "1.10.0"（crates/pverify-core/src/report/schema.rs:line）である。

3.2 クレートのトポロジー

ルートワークスペース（Cargo.toml）は 11 個のメンバーを宣言する。

12 番目のクレート web/pverify-wasm は、ルートワークスペースから意図的に切り離されて いる。その Cargo.toml は空の [workspace] テーブルを持ち、これにより wasm-bindgen が生成する unsafe コードと wasm 依存関係グラフが、ルートの unsafe_code = "forbid" リントのサーフェスから、またリリース対象の cargo test --workspace / cargo audit の サーフェスから外れるようにしている。これがブラウザホストである。

3.2.1 2 つのグラフ分類

クレート群は 2 つのグラフ分類に分かれ、ホスト → WASM クリーン → コアという、 ゲートによって表明される厳格な依存方向を持つ。

WASM クリーングラフ（wasm32-unknown-unknown へコンパイル可能でなければならず、 RustCrypto のみ、ring/getrandom/openssl なし）：

• pverify-core — カーネル。その依存関係は RustCrypto のフォーマットおよび プリミティブクレート（der、x509-cert、rsa、p256、p384、 ed25519-dalek、ml-dsa、sha1、sha2、spki、pkcs1、x509-ocsp）に加え、 time、serde、serde_json、hex である。ワークスペース内部には何も依存しない。
• pverify-xades、pverify-asic、pverify-jades — pverify-core に依存する ホスト抽出クレート（コアが所有する境界型、例えば XadesComponents、AsicSignature、 JadesComponents のため）であるが、それ自体は wasm32 ビルド可能であり続けることが 求められる。これらは暗号処理を含まない — パース、正規化、バイト抽出のみである。 ツリーゲートによって pverify-core のランタイムグラフから禁止されている。

ホスト専用グラフ（ネイティブ std。コア／WASM ランタイムグラフに現れては ならない）：

• pverify-eutl、pverify-aatl、pverify-anchor-inventory — アンカー取り込み。 各々が通常の TrustAnchor 値を出力し、既存の --trust-anchors 経路を通じて 再投入可能である。取り込み処理はカーネルに何も付け加えない。
• pverify-cli — ネイティブ検証器。ネイティブ I/O が許される唯一のクレートである。 すなわち cfg(not(wasm32)) 下でのオンライン取得のための ureq、PDF パースのための lopdf、そして std::fs である。
• web/pverify-wasm — ブラウザホスト。コア + xades + asic + jades + lopdf （ブラウザ内 PDF パース）+ wasm-bindgen に依存する。

破線の矢印 CLI -. dev-dep .-> TESTH は dev-dependency のみである。本番の cargo tree -e normal グラフには存在しないことが表明されている。

3.2.2 ツリーゲート

scripts/cargo-tree-gate.sh は、境界に対する荷重を担う経験的なガードである。これは cargo tree -e normal --no-default-features -p pverify-core を実行し、いずれかの ホスト専用クレートまたはその特徴的な推移的依存関係がコアの通常依存グラフに現れた場合に ビルドを失敗させる — 具体的には pverify-eutl、 pverify-asic/zip/flate2/miniz_oxide、pverify-aatl/lopdf、pverify-jades、 pverify-test-helpers、または xtask である。これにより「カーネルは PDF/XML/ZIP パーサを決してリンクしない」というアーキテクチャ上の規則を、コードレビューの慣習ではなく 機械的に検査される不変条件へと変換する。補完的な cargo build --target wasm32-unknown-unknown -p pverify-core ステップは、カーネルが 実際にブラウザターゲット向けにビルドされることを証明する。

3.3 ホスト対 WASM クリーンコアの境界の詳細

カーネルは PDF、XML、ZIP、JSON のコンテナをパースできない — これらのパーサは std と、no_std WASM カーネルと両立しない巨大な依存関係グラフを引き込む。代わりに、ホストが 各コンテナ形式を事前にパースし、抽出されたモデルに依存しないバイト構造を VerificationRequest（crates/pverify-core/src/verify.rs:69）の追加的フィールドへ 引き渡す。カーネルは判別された形式に合致するフィールドのみを参照する。関連するリクエスト フィールドとその生産者は以下のとおりである。

この追加性は意図的な再現性の契約（憲章 §II）である。すなわち、PDF でない入力は空の pdf_validation_data（その Default）を持ち、スコープ外の JSON は空の jades_components を持つ、といった具合である。従前のあらゆる呼び出し側は、より新しい フィールドを Default::default() / Vec::new() で埋めるため、チャネルを追加しても 従前の報告は schema_version 文字列を除いてバイト単位で同一のまま保たれる（FR-008 バイト単位の同一性）。例えば、/DSS を持たない PDF は、034 以前の報告と schema_version だけが異なる。

これは憲章 §V「ライブラリファースト」の構造的表現である。コンテナのパースは完全に ホストクレート（pverify-cli/src/pdf.rs、pverify-xades、pverify-asic、 pverify-jades、pverify-aatl）内に存在し、カーネルは lopdf、zip、flate2、 あるいは bergshamra-c14n 正規化器を決してリンクしない。

3.3.1 トレイトを介したケイパビリティ境界

crates/pverify-core/src/traits.rs は 3 つのホストケイパビリティと、最小限の値型一対を 定義する。

• Clock — fn now(&self) -> OffsetDateTime。カーネルは実際にはホットパスで これを呼ばない（検証時刻はホストによって VerificationRequest.verification_time へ捕捉される）。このトレイトは、ホストが時刻を 決定論的に供給できるように存在する。テストでは固定時刻のフェイクを用いる。
• RevocationFetcher — fn fetch_crl(&self, url: &str) および fn fetch_ocsp(&self, uri: &str, request_bytes: &[u8])。実装は呼び出し側のモードを 尊重する。すなわちオンライン（ureq GET/POST）、オフライン（常に Err(Error::NotAvailableOffline)）、または from-bundle（<bundle>/crls/ または <bundle>/ocsp/ から読む）である。fetch_ocsp は NotAvailableOffline を返す デフォルト実装を持ち、OCSP 以前の実装者が誠実に格下げできるようにしている。 決定的に重要なのは、カーネルが DER の OCSPRequest を自前で構築し （crate::revocation::ocsp::build_ocsp_request_bytes）、トレイトが生の BasicOCSPResponse バイト列を返す点である — パースはカーネル内に留まり、トレイトは x509-ocsp のバージョンをまたいで安定である。
• TrustAnchorStore — fn anchors(&self) -> &[TrustAnchor]。アンカーをホストが 供給した順序で返す。ストアは「意図的に不活性」であり、重複排除、ソート、フィルタを 行わない。ホストはロード時に各 TrustAnchor の SHA-256 fingerprint、生の subject_dn バイト列、および validity_window_covers_request_time フラグを計算する （FR-025）。

このクレートはまた、スケルトン実装 OfflineRevocationFetcher（規範的な「常に拒否する」 フェッチャ）と InMemoryTrustAnchorStore を同梱しており、CLI および WASM ホストが これらをラップまたは投入する。

3.4 ネイティブ CLI 実行モデル

ネイティブ検証器は pverify-cli である。そのコマンドサーフェス （crates/pverify-cli/src/main.rs、enum Command）は 4 つのサブコマンドを網羅する。

• verify — CAdES / PAdES / XAdES / JAdES / ASiC 署名を検証する。
• ingest-trust-list — EU トラステッドリスト（ETSI TS 119 612）を再投入可能な PEM アンカーへ取り込む（検証専用であり、「適格（qualified）」を決して判定しない）。
• ingest-aatl — Adobe Approved Trust List を、ピン留めされた Adobe Root CA G2 に 照らして取り込む。
• trust-anchors — あらゆるアンカー配布チャネルの読み取り専用検査。

verify の経路（Command::Verify、main.rs:346）は以下のように動作する。

1. 入力を読み、時刻を捕捉する。 署名ファイルと、任意のデタッチコンテンツをディスクから 読む。検証時刻は起動時に一度だけ、ホストの Clock（src/clock.rs）から、または --at から捕捉する。--at は常に優先される（§II 再現性）。
2. モードを選択する。 オンライン取得を伴う --trust-anchors <DIR>、--offline、 --from-bundle <DIR>、または LDAP-CRL のいずれか — src/modes/{online,offline,from_bundle,ldap}.rs に実装されている。CLI の Mode 列挙 {Online, Offline, FromBundle} はカーネルの失効 VerificationMode へ写像される。 --offline はソケットを開かない（オフラインの誠実性）。
3. トラストアンカーをロードする。 src/trust.rs が各アンカーの SHA-256 フィンガープリント、生のサブジェクト DN バイト列、および validity_window_covers_request_time フラグ — ホストの FR-025 責務 — を計算し、 InMemoryTrustAnchorStore を構築する。
4. コンテナをホスト側でパースする。 入力が PDF であれば、 src/pdf.rs::extract_signatures が lopdf を実行して PdfSignatureDescriptor 群（/ByteRange、/Contents、/SubFilter、%%EOF 走査による revision_end、 および /Sig 対 /DocTimeStamp のタグ）を出力し、extract_validation_data が 文書レベルの /DSS プールおよび /VRI をパースする（§3.8）。XAdES/ASiC/JAdES の入力は それぞれの抽出クレートによってパースされる。
5. 組み立てて呼び出す。 VerificationRequest を埋め、 verify_with(&request, &store, &fetcher) を呼ぶ。
6. レンダリングする。 src/render.rs が返された Report を JSON へシリアライズする。

CLI は規範的な検証器である。その境界付き I/O ガード（bounded_io.rs、net_guard.rs） とホスト側の責務（アンカーのロード、PDF パース）は、まさにカーネルが意図的に除外している ホストの関心事である。

3.5 ブラウザ／WebAssembly 実行モデル

ブラウザホストは web/pverify-wasm（web/pverify-wasm/src/lib.rs）である。これは 2 つの #[wasm_bindgen] エントリポイントを公開する。

• classify(bytes) — 本物の pverify-core パーサを優先順位順に実行する（PDF → ASiC ZIP → JAdES JSON → X.509 証明書 → CRL → CMS SignedData → それ以外は 「コンテンツ」）。これによりドラッグアンドドロップの UI は、ドロップされたファイルを 拡張子ではなくそれが何であるかによって自動的に振り分けできる （classify_bytes、lib.rs:158）。
• verify(req) — 完全な pverify_core::verify::verify_with パイプラインを完全に クライアント側で実行し、整形済みの JSON 報告を返す（lib.rs:288）。

verify は VerifyInput（署名バイト列、任意のデタッチコンテンツ、トラストアンカーの DER、追加の証明書、source_uri をキーとする crls/ocsp、verification_time_unix、 および任意の algorithm_policy セレクタ）をデシリアライズする。次に、ネイティブ CLI と バイト単位で同一のホスト作業を行う。

• extract_pdf_signatures（pverify-cli/src/pdf.rs::extract_signatures の移植）、
• extract_pdf_validation_data（pverify-cli/src/pdf.rs::extract_validation_data の 移植 — 同一の /DSS+/VRI の和集合、重複排除、 MAX_DSS_ENTRIES_PER_POOL/MAX_DSS_STREAM_BYTES の上限、および大文字 16 進 SHA-1 の VRI キー付け、lib.rs:519）、
• pverify_xades::extract、pverify_asic::extract、pverify_jades::extract、

これらにより同じ VerificationRequest を構築し、同じ verify_with を呼ぶ。 アンカーは anchor_from_der によって構築され、これは「pverify-cli/src/trust.rs と 同じやり方でフィンガープリントと有効期間ウィンドウを計算する」（lib.rs:115）。 ブラウザ側の DemoFetcher は CLI のバンドルフェッチャを鏡映したインメモリの source_uri → bytes ルックアップである。ミスは NotAvailableOffline を返し、これを パイプラインが IndeterminateNoCrl / IndeterminateOcspUnreachable へ写像する。

したがってCLI と WASM のパリティは偶然ではなく強制された不変条件である。両ホストは 同一の構造を抽出し同一のカーネルを実行するため、同一の入力に対してバイト単位で同一の報告を 生み出す。パリティは抽出器に対するテスト（例えば crates/pverify-cli/tests/extractor_parity.rs、および WASM 側のパリティテスト web/pverify-wasm/src/lib.rs:729 以降）によってピン留めされている。

ページのレイアウト（web/site/index.html）は検証結果セクションを先頭に、ヘッダ直下に 配置し、ドロップ／検証ツールはその下に置く。これにより、検証完了時の判定が、画面外に はみ出して見落とされかねない縦長の形式／アルゴリズム解説セクションの下ではなく、ビューポートの 最上部に表示される。renderReport（app.js）は #result の非表示を解除し scrollIntoView を呼ぶため、読者が下方へスクロールした後に再検証を発火させた場合（検証時刻の 変更など）でも、新しい判定を視界へ引き戻す。検証はドロップ時に自動実行され、「再検証する」 ボタンとその直下のステータス行が手動再実行の経路である。

第 3 の、診断用のハーネス web/verify-cli.mjs は、ビルド済みの同じ site/pkg/ WASM モジュールを Node から駆動する。これによりフィクスチャをブラウザなしで WASM パイプラインを 通して検証できる。これは明示的に製品ではない（CRL プロキシを持たないため、CDP のみの チェーンは INDETERMINATE を報告する。一方ブラウザはプロキシを通じて CRL を取得するため TOTAL_PASSED に到達する）。これは純粋にパリティ診断のために存在し、そのヘッダがその旨を 述べている（web/verify-cli.mjs:9-13）。そのプロセスの終了コードは signatures[0] の ETSI インディケーションを鏡映する（0=TOTAL_PASSED、1=TOTAL_FAILED、 2=INDETERMINATE／署名なし）。

3.6 pverify-core のモジュール構成

crates/pverify-core/src/lib.rs がカーネルの公開モジュールを宣言する。その責務は 以下のとおりである。

report 内の意図的な分割に注意されたい。schema.rs は SCHEMA_VERSION（"1.10.0"）と、 あらゆる報告ヘッダに表出される開示定数 — 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 VerificationRequest から Report へ：端から端までのフロー

唯一のオーケストレータは verify_with（crates/pverify-core/src/verify.rs:178）である。 これは (&VerificationRequest, &dyn TrustAnchorStore, &dyn RevocationFetcher) を取り、 Report を返す。このフローは 6 つのステージを持つ。

3.7.1 ステージ 0/1 — ホストパースとリクエストの組み立て

§3.4/§3.5 で扱った。ホストがコンテナをパースし、時刻を捕捉し、アンカーをロードし、 VerificationRequest を埋める。あらゆる形式チャネルは追加的な Vec / Default である。

3.7.2 ステージ 2 — 形式ディスパッチ

verify_with はまず Report::new_header を介してヘッダを初期化する。次に、以下の 優先順位でディスパッチする（verify.rs:189-327）。

1. ASiC が優先される。 asic_signatures が空でなければ、生バイトの判別にかかわらず 入力は ASiC コンテナである（コンテナのバイト列は ZIP マジック PK\x03\x04 で始まり、 そうでなければ CAdES へ流れ込んでしまう）。内部署名ごとに 1 つの SignatureEntry が crate::asic::verify_asic_signature を介して出力される。
2. 裸の ZIP、ASiC コンテンツなし。 signature_bytes が PK\x03\x04 で始まるが ホストが ASiC 署名を生成しなかった場合、入力は認識可能な ASiC コンテナでない ZIP で ある。カーネルはこれを CAdES と誤分類させるのではなく、 asic_unsupported_container（INDETERMINATE）を出力する（verify.rs:227）。
3. コンテンツ判別。 それ以外の場合、detect_format（verify.rs:359）が先頭バイトを 検査する。%PDF- → PAdES、UTF-8 BOM 許容の <?xml または裸の <+NameStartChar → XAdES、BOM 許容の先頭 { → JAdES、それ以外は CAdES。JSON と XML は最初の非空白バイト （{ 対 <）において相互排他的であるため、判別が衝突することはあり得ない。

各アームは署名ごとに 1 つの SignatureEntry を出力する。PAdES は crate::pades::verify_pdf へルーティングされる。XAdES は各 xades_components エントリを crate::xades::verify_xades を通じて写像する（ホストが何も抽出しなかった場合は xades_unsupported）。JAdES は各 jades_components エントリを crate::jades::verify_jades を通じて写像する（または JAdES 拒否エントリ）。CAdES は verify_cades へルーティングされる。

3.7.3 ステージ 3 — 署名ごとの検証（CAdES を基準として）

verify_cades（verify.rs:475）は基準となるパイプラインである。他の形式は共有ヘルパーを 通じてそのフェーズを再利用する。順に以下のとおりである。

1. 寛容なウォーカー（SignedDataParser::parse）で CMS SignedData をパースする。
2. マルチ署名者 CMS を誠実に拒否する。 signer_info_count > 1 の場合、最初の SignerInfo のみを報告するのではなく、INDETERMINATE / cms_multi_signer_unsupported （verify.rs:496）を返す — これは事実報告の要件（§I）である。029 以前のパーサは署名者 集合を暗黙に切り詰めていたためである。
3. 埋め込まれた証明書 DER ブロブを再構成し、ホストが供給した extra_certificates を 追加する（パス構築のために消費されるが、署名者として選択されることは決してない）。
4. SignerInfo.sid（issuer+serial または SKI）によって署名者を選択する。 これは select_signer_by_sid（verify.rs:1096）を介する。不正な／見つからない sid は 報告の足場としてのみヒューリスティックなインデックスへフォールバックする — 判定は いかなる署名／ダイジェストのゲートの前に、SignerIdentifierCheck の結果によって ゲートされる。
5. パスを検証し（RFC 5280 §6 の構造的検査 + パス構築、path/mod.rs）、次に各チェーン ステップの証明書署名を wire_chain_step_signatures（verify.rs:1944）を介して RustCrypto で検証する。
6. 署名なし属性を射影し（T/LT/LTA：signature-time-stamp、archive-time-stamp-v3、 certificate-values、revocation-values の CRL/OCSP）、形式繰り上げの梯子 （verify.rs:1034-1042）を計算する。すなわち、アーカイブタイムスタンプが存在する → CAdESLta、LT ペイロードが存在する → CAdESLt、signature-time-stamp が存在する → CAdEST、それ以外は CAdESBes である。
7. 署名者チェーンに失効を適用する（apply_revocations）。
8. signedAttrs のダイジェストと署名、およびコンテンツのダイジェストを検証する。ESS 署名 証明書バインディング（RFC 5035）とコンテンツタイプバインディングを検査する。

3.7.4 ステージ 4 — オブジェクトごとの VRT

crate::vrt::derive_vrt（verify.rs:757）はタイムスタンプトークンから再帰的な外側 カバーグラフを構築し、各オブジェクト — 署名者チェーン、署名者の署名、各 signature_timestamp[i]、各 archive_timestamp[i] — に固有の検証基準時刻を割り当てる Vrt ブロックを返す。署名者チェーンと各 TSA チェーンはその後それぞれ自身の VRT で 再検証され、TSA チェーンは apply_tsa_chain_revocation_for_token（verify.rs:1552）を 介して各オブジェクトの VRT で失効検証される。カバーグラフはその時刻源として request_at のみを読み（Clock::now を決して読まない）、下流の失効／アルゴリズム層によって再導出 されたり変異させられたりすることは決してない（FR-005a）。VRT の章を参照のこと。

3.7.5 ステージ 5 — インディケーション集約

aggregate_etsi（verify.rs:2343）は、構造的／署名／ダイジェスト／失効の所見を、 重大度順序 TOTAL_FAILED > INDETERMINATE > TOTAL_PASSED と、ある重大度内での最初の所見 優先の規則をもって、基底の EtsiIndication へと畳み込む。次に階層化されたパスが実行され、 各々は非 TOTAL_FAILED の基底を格下げできるのみであり、証明済みの TOTAL_FAILED を 覆い隠すことは決してできない。すなわち署名者バインディング、コンテンツタイプ、オプトインの アルゴリズム妥当性、そして TSA 失効である。優先順位の梯子はソース中で明示的である — 例えば archive_timestamp_imprint_mismatch は chain_constraints_failure の直後にランクされる （verify.rs:2357-2391）。ETSI 集約の章を参照のこと。

3.7.6 ステージ 6 — 報告のシリアライズと検証対象オブジェクトの一覧

report.signatures を投入した後、verify_with はステップごとの弱アルゴリズムフラグを ヘッダへ集約し（aggregate_for_header）、次に統合された資料インベントリを導出する。 report.validation_objects = crate::report::derive_validation_objects(&report) （verify.rs:341）。derive_validation_objects （crates/pverify-core/src/report/validation_objects.rs:191）は純粋な &Report の 読み取りである — ネットワークなし、新たな暗号処理なし（あらゆるダイジェストは既にフィールド である）。実際に参照された証明書、CRL、OCSP レスポンス、コンテンツオブジェクトを列挙し、 各々を ValidationObjectOrigin の出所（プロビナンス）値でタグ付けする。次にホストが Report を JSON へシリアライズする（CLI は src/render.rs、WASM は serde_json::to_string_pretty）。両ホストは同一のカーネルを実行するため、同一の入力に 対して出力はバイト単位で同一である。

3.8 PAdES /DSS+/VRI の特殊化（ブランチ 034）

PAdES は、文書レベルの検証情報により、そのステージ 3 が実質的に異なる唯一の形式である。 そのため、判定ロジックに触れることなく追加的機能がアーキテクチャをどのように貫くか、その 最も明快な実例として、ここで述べる価値がある。

ブランチ 034 以前、pades::verify_pdf は失効パイプラインに空の埋め込みスライスを供給して いた。そのため、証拠が完全に揃ったオフラインの PAdES-LT/LTA が INDETERMINATE / revocation_not_checked_offline で行き詰まっていた。ブランチ 034 は、カタログレベルの /DSS 辞書（/Certs、/CRLs、/OCSPs）の すべてのインクリメンタルアップデート リビジョンにわたる和集合を DER で重複排除したホスト側抽出、加えて各署名の /Contents の 大文字 16 進 SHA-1 をキーとする /VRI サブ辞書の抽出を追加した。これは型 PdfValidationData の新たな追加的 VerificationRequest.pdf_validation_data （crates/pverify-core/src/pades/mod.rs:80）としてカーネルへ届けられ、ネイティブ CLI （pverify-cli/src/pdf.rs::extract_validation_data）とブラウザホスト （web/pverify-wasm/src/lib.rs::extract_pdf_validation_data）によって同一に投入される。

pades::verify_pdf の内部でカーネルは、署名オブジェクトごとに、resolve_material （crates/pverify-core/src/pades/mod.rs:148）を介して優先される検証情報を解決する。 すなわち、オブジェクトの /Contents SHA-1 をキーとする /VRI エントリが優先される （出所 PdfVri）。それがなければ、文書レベルの /DSS プールがフォールバックである （出所 PdfDss）。解決された CRL/OCSP DER は、以前は &[],&[] を受け取っていた既存の apply_revocations（署名者チェーン）および apply_tsa_chain_revocation_for_token （各タイムスタンプ）の呼び出しへ、各オブジェクト自身の VRT で供給される。Adobe revocationInfoArchival（OID 1.2.840.113583.1.1.8）は CMS から射影され、 signature_embedded 情報として併合される。

いくつかのアーキテクチャ上の性質が設計によって保持される。

• 新たな判定ロジックなし。 DSS 情報は既存の RevocationOutcome 語彙を生み出す — 失効した署名者は既存の TOTAL_FAILED、失効した TSA は 033 の既存の revoked_no_poe （INDETERMINATE）である。新たな結果も新たなサブインディケーションも追加されなかった。
• /Certs はアンカーになることは決してない。 DSS /Certs は中間／リーフのパス構築 候補にすぎず、トラストアンカーへ昇格されることは決してない（PdfValidationData.dss_certs のドキュメントコメント、pades/mod.rs:81-83）。
• 追加的のみの素通り。 DSS 由来の CRL/OCSP は、ライブ／CDP チャネルが判定不能のときに のみ発火する既存の埋め込み情報チャネルに乗る。そのためオンラインのライブ取得の成功は バイト単位で同一のまま保たれる。
• 衝突安全なキーによる追加性。 ここでの SHA-1 は /VRI 辞書のキーのみであり、 決してセキュリティプリミティブではない。情報は追加的な証拠（CRL は issuer+serial で 照合され、OCSP は certID で照合される）であるため、衝突は追加的な証拠を誤ルーティング し得るのみであり、「good」な結果を捏造することは決してできない（sha1_uppercase_hex のドキュメントコメント、pades/mod.rs:183-188）。
• 出所のみ。 唯一のワイヤ変更は 2 つの新たな ValidationObjectOrigin バリアント pdf_dss と pdf_vri であり、supplied_input の後に追加された （crates/pverify-core/src/report/validation_objects.rs:113-118）。016 の導出が CRL ごと／OCSP ごとの出所タグ（PdfRevocationSource::{PdfDss,PdfVri}）をそれらへ 写像する（validation_objects.rs:308-336）。クローズドな列挙バリアントの追加は追加的な MINOR スキーマバンプであり、これがスキーマを 1.5.0 から 1.7.0 へと進めたものである。

3.9 アーキテクチャが対応する AdES レベル語彙

ディスパッチと形式ごとの検証器はスコープについて誠実である。以下の表は、ツールが何を 検証するか、対して何を未対応としてフラグ付けするかを述べる。詳細は形式ごとの章に 記載されている。

CAdES の形式繰り上げの梯子は verify.rs:1034-1042 にある。JAdES および XAdES の拒否 エントリは、それぞれ crate::jades::jades_unsupported_entry および xades_unsupported_entry によって出力される。レベルやバリアントがスコープ外である場合、 アーキテクチャは精密なサブインディケーションを伴って INDETERMINATE へ格下げし（§3.1.2）、 捏造された失敗を決して出さない。

3.10 アーキテクチャが保証する横断的な不変条件

以下の不変条件は、いずれかひとつのモジュールの性質ではなく、アーキテクチャそれ自体の性質 であり、各々が機械的またはテストによって強制される。

1. WASM クリーンなコア（§VI、妥協不可）。 pverify-core は no_std + alloc で あり、unsafe を禁止し、wasm32-unknown-unknown 向けにビルドされ、RustCrypto のみで ある — ツリーゲートと wasm ビルドステップによって強制される。
2. コアでのコンテナパースなし（§V）。 あらゆる PDF/XML/ZIP/JSON のパースはホスト クレートに存在する。カーネルは lopdf/zip/flate2/bergshamra を決してリンクしない — ゲートによって表明される。
3. I/O を行わない、トレイトを介した境界。 クロック、失効、アンカーが、カーネルが手を 伸ばす唯一のホストの関心事であり、それも traits.rs を通じてのみである。derive_vrt と derive_validation_objects は純粋な計算である。
4. 追加的なスキーマバージョニング。 SubIndication、RevocationOutcome、 ValidationObjectOrigin は report-schema.json に 1 対 1 で写し取られたクローズドな 列挙である。値や任意フィールドの追加は MINOR、削除や再利用は MAJOR である。非推奨の バリアント（例えば bridge_ca_required_unsupported）は、保存された報告のデシリアライズの ために保持されるが、出力されることはない。
5. 追加的／オフの機能における判定のバイト同一性（§II）。 追加的機能は、その入力が 存在しないかオフであるとき、報告本体を schema_version を除いてバイト単位で同一のまま 残す（例えば DSS を持たない PDF、アルゴリズムポリシーがオフ、空の埋め込み失効チャネル）。
6. オフラインの誠実性（§VII / §I）。 --offline はソケットを開かず、レスポンダ接触を 決して捏造しない。誠実な IndeterminateRevocationOffline / revocation_not_checked_offline の結果が、従前の不誠実な ocsp_responder_unreachable の出力を置き換えた。
7. CLI と WASM のパリティ。 両ホストはバイト単位で同一の抽出器と同一の verify_with を実行する。パリティテストが抽出器の出力形状をピン留めする。
8. 断言できないことは断言しない（§I、妥協不可）。 確立されていない事実は、クローズドな 列挙のサブインディケーションを伴って INDETERMINATE へ格下げされる。
9. インディケーションの優先順位／決して覆い隠さない。 aggregate_etsi は重大度順序の 基底を設定する。後続の層は非 TOTAL_FAILED の基底を格下げするのみである。
10. オブジェクトごとの VRT の分離。 各オブジェクトは、request_at のみを読む純粋な 再帰的外側カバーエンジンを介して、それぞれ自身の導出された VRT で判定される。カバー グラフは下流で再導出されたり変異させられたりすることは決してない。
11. ホストの取り込みは通常のアンカーを生成する。 pverify-eutl/aatl/ anchor-inventory は、--trust-anchors を通じて再投入可能な通常の TrustAnchor 値を出力する。取り込みはパース時にネットワーク I/O を行わない。
12. 再現可能な時刻捕捉（§II）。 CLI は --at が与えられない限り検証時刻を起動時に 一度だけ捕捉し、--at は常に優先される。

これらの不変条件は、まとめて、報告を監査可能な事実たらしめるものである。すなわち、同一の 入力は常に同一の報告を生み出し、暗号とパースのサーフェスは境界付けられ検査可能であり、 ツールは証明できる以上のことを決して主張しない。

4. 入力分類とフォーマットディスパッチ

本章では、pverify が不透明なバイト列をどのようにして経路付けされた検証へと変換するかを説明する。本章が扱うのは、二層からなる分類パイプライン（どの構造パーサを実行するかを決定するホスト側のスニフと、どの検証アームに入るかを決定するカーネル側のスニフ）、両者の優先順位ルール、detached（分離型）コンテンツと attached（添付型）コンテンツの取り扱い、ASiC-S/ASiC-E コンテナの検出、そして各フォーマット別検証器へのディスパッチである。以下に述べるすべての挙動上の主張はソースに根拠を持つ。中核を担う分類器は pverify_core::verify::detect_format（crates/pverify-core/src/verify.rs:359）であり、そのホスト側ミラーは crates/pverify-cli/src/main.rs と web/pverify-wasm/src/lib.rs に分割されている。

本章を通じての設計原則は、誠実で決定論的なディスパッチである。すべての入力はちょうど一つのフォーマットに割り当てられ、その割り当てはバイト列の小さなプレフィックスから行われ（よって安価かつ再現可能である）、ある系統に合致するもののツールがサポートするレベルでは検証できない入力は、別のアームへ静かに誤経路付けされたり pass/fail を捏造されたりするのではなく、正確なクローズドな列挙（閉じた語彙）のサブインディケーションを伴って INDETERMINATE へと degrade する（憲法 §I「断言できないことは断言しない」。憲法上の枠組みについては第2章を、本章が動作する範囲となるアーキテクチャ境界については第3章を参照）。

4.1 二層分類

pverify は検証カーネルの内部で PDF・XML・ZIP・JSON をパースできない。カーネルは #![no_std] であり、コンテナ/文書パーサのリンクを禁じられている（憲法 §V/§VI。クレートトポロジと、それを強制する scripts/cargo-tree-gate.sh ガードについては第3章 §3.x を参照）。したがって分類は、設計上、二度行われ、二つの層は一致しなければならない。

1. ホスト側スニフ（構造パース選択）。 ネイティブ CLI とブラウザの WASM ホストは、入力の先頭バイトを検査してどの構造抽出器を実行するかを決定する — PDF には lopdf、XML には pverify-xades、ZIP には pverify-asic、JSON には pverify-jades — とともに、CLI のコンテンツソースルール（§4.4）を強制する。ホストは VerificationRequest のフォーマット固有チャネル（pdf_signature_dicts、pdf_validation_data、xades_components、jades_components、asic_signatures）を、抽出したモデルに依存しないバイト構造で充填する。

2. カーネル側スニフ（検証アームのディスパッチ）。 verify_with（crates/pverify-core/src/verify.rs:178）は同じ request.signature_bytes を再分類し、ちょうど一つの検証アームへ経路付けする。カーネルは常に自身のスニフ結果に合致するリクエストチャネルのみを参照するため、（常に空である）pdf_validation_data を伴う非 PDF 入力は、そのフィールドを一切持たなかった入力と区別がつかない。

両層とも先頭バイトのみを読む — 分類にファイル全体のスキャンは不要である — そして両者はバイト単位で同一の述語を用いる。CLI の looks_like_xml（crates/pverify-cli/src/main.rs:399）と looks_like_json（main.rs:420）は、カーネルの looks_like_xml/looks_like_json（verify.rs:392/375）と一行一行が等価であり、WASM ホストの複製（web/pverify-wasm/src/lib.rs:419/439）には明示的に「mirrors pverify_core::verify」というコメントが付されている。この意図的な三重化が、CLIとWASMのパリティ不変条件（第3章）である。ネイティブおよびブラウザのホストは同一の構造を抽出しなければならず、カーネルは同一のアームへ到達しなければならない。よって所与の入力は、いずれのホスト上でもバイト単位で同一のレポートを生成する。

ホストの順序（ZIP → PDF → XML → JSON → CAdES）とカーネルの順序（ASiC チャネル → ZIP → detect_format）との間の非対称性は意図的なものであり、§4.5 で説明する。カーネルは detect_format の前にASiC をディスパッチしなければならない。なぜなら ASiC コンテナのバイト列は ZIP マジックで始まるが、detect_format のスニフはこれを認識せず、さもなければそれを CAdES アームへ素通りさせてしまうからである。

4.2 カーネルスニフ: detect_format

カーネルの分類器は、先頭バイトに対する四方向の判定である（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 はクローズド列挙型 {Pdf, Xades, Jades, Cades}（verify.rs:347）である。その順序は重要であり、ソースに記録されている。PDF が最初にテストされるのは %PDF- が一義的なバイナリマーカーだからである。XML と JSON は最初の非空白バイト（< 対 {）において相互排他的であるため、両者の相対的な順序が衝突を引き起こすことはない。そして CAdES は残余のデフォルトである — PDF/XML/JSON として認識されないものはすべて DER エンコードされた CMS SignedData として扱われ、verify_cades へ手渡される。ZIP は detect_format の分岐ではないことに注意されたい。ZIP 入力は verify_with の中でより早期に捕捉され（§4.5）、この関数に到達することはない。スニフは構造の残りを検証しようとはしない — 不正な形式の CMS であっても CAdES へ経路付けされ、そこで誤分類ではなく cades_parse_failed エントリとなる。

4.2.1 マーカー述語

監査人にとって記録に値する二つの精度上の論点がある。

• JSON スニフはオブジェクト根のみ。 looks_like_json は先頭の { に対してのみ true を返し、[ に対しては決して返さない。これは JAdES にとって正しい。JWS JSON Serialization（RFC 7515 §7.2）は常に JSON オブジェクトであり、裸の配列となることはない。したがって先頭の [ は非 JAdES の JSON 文書となり、意図的に JAdES アームではなく CAdES 残余へ経路付けされる。この挙動は WASM テストで表明されている（web/pverify-wasm/src/lib.rs:781、!looks_like_json(b"[]")）。
• XML の NameStartChar テストは ASCII 部分集合である。 looks_like_xml は裸の < に続く ASCII 文字、_、または : を受理する。ソースのコメントはこれを「ASCII subset is sufficient for all GPKI-shaped fixtures」（verify.rs:402）と注記している。ds:Signature や xades:… を根とする文書、あるいは <?xml プロローグを伴う任意の XML は正しく分類される。仮想的に、ルート要素名が非 ASCII の Unicode NameStartChar で始まり、かつプロローグと BOM を省略した XML は、XML としてスニフされないであろう。そのような入力が GPKI/eIDAS コーパスに生じることはなく、その失敗モードは無害である（それは CAdES へ素通りし、偽の pass ではなく cades_parse_failed という事実を生成する）。

UTF-8 BOM（EF BB BF）は XML テストと JSON テストの両方の前に剥がされる（verify.rs:376、verify.rs:394）ため、BOM をプレフィックスとして持つ XAdES または JAdES 文書は、その真の最初のコンテンツバイトに基づいて分類される。

4.3 verify_with におけるフォーマット別ディスパッチ

ASiC の捕捉（§4.5）の後、verify_with は detect_format の結果に対してマッチを行い、Vec<SignatureEntry> を構築する — 文書内の署名一つにつき一エントリ（crates/pverify-core/src/verify.rs:240）。すべてのアームが遵守する契約は、消費者は常に確定した事実を受け取る、というものである。ホストの抽出が空であっても、ちょうど一つの説明的エントリを生み、空の配列を生むことは決してない。

4.3.1 PAdES アーム（DetectedFormat::Pdf）

PDF 入力は crate::pades::verify_pdf（verify.rs:241）へ経路付けされ、ホストが抽出した pdf_signature_dicts と pdf_validation_data、トラストストア、フェッチャ、検証時刻、実際の VerificationMode（よって --offline は OCSP 接触を捏造するのではなく尊重される — §I のギャップに対する 015 の修正、verify.rs:255）、正規の required_policies 集合（verify.rs:259、よって --required-policy が PAdES に対して強制される）、そしてオプトインのアルゴリズムポリシー（verify.rs:261）とともにスレッドされる。

verify_pdf（crates/pverify-core/src/pades/mod.rs:242）は記述子を反復し、各 /Sig 辞書につき一つの SignatureEntry を生成し、カバーする各 /DocTimeStamp トークンを直前の最新の署名に付加する（mod.rs:309）。これは埋め込み CMS と /DocTimeStamp（PAdES のアーカイブタイムスタンプ機構）にわたって PAdES B-B、B-T（signature-time-stamp）、B-LT、B-LTA をサポートし、ブランチ 034 以降は文書レベルの /DSS（/Certs//CRLs//OCSPs）、/VRI、および Adobe revocationInfoArchival の検証材料を消費する（解決の詳細については PAdES 検証の章を参照）。ホストが署名辞書をまったく抽出しなかった場合、verify_pdf は空のベクタではなく単一の説明的エントリを返す。no_signature_entry（mod.rs:475）は、サブインディケーション PdfByteRangeMalformed とコンテキスト文字列 "pdf-no-signature-dict"（mod.rs:496）を伴う INDETERMINATE を発する。

PAdES は構造上常に attached である。/ByteRange は PDF 本体内のバイトを参照するため、すべての PAdES SignatureEntry は不変に content_source = Embedded を担持する（mod.rs:483）。これが、CLI が PDF 入力と --detached-content の組み合わせを禁ずる理由である（§4.4）。

4.3.2 XAdES アーム（DetectedFormat::Xades）

XML 入力はコンポーネントごとのループ（verify.rs:263）へ経路付けされる。request.xades_components が空である場合 — 入力が XML としてスニフされたがホストが ds:Signature を抽出しなかった、あるいはホストが分類しきれない抽出エラーに遭遇した場合 — アームは xades_unsupported_entry（verify.rs:272、verify.rs:413 に定義）へフォールバックする。これはサブインディケーション XadesUnsupported を伴う INDETERMINATE である。そうでなければ、抽出された各コンポーネントにつき一度 crate::xades::verify_xades を呼び出す。pverify は、監査済みの bergshamra-c14n クレートを介した Exclusive XML 正規化（C14N）を用いて、B-T/B-LT タイムスタンプおよび B-LTA ArchiveTimeStamp インプリントを伴う enveloped XAdES B-B（ブランチ 036、SignatureFormat::XadesBLta）を検証する。detached/enveloping XAdES および非 exclusive な C14N は INDETERMINATE へ degrade する（XAdES の章を参照）。この拒否へのフォールバック設計は、検証可能な XAdES 署名ではない XML 文書であっても、静かな空の結果ではなく、確定した機械可読の事実（FR-009）を生成することを意味する。

4.3.3 JAdES アーム（DetectedFormat::Jades）

JSON 入力は類似のコンポーネントごとのループ（verify.rs:296）へ経路付けされる。空の request.jades_components は jades_unsupported_entry（verify.rs:304）へフォールバックする。そうでなければ各コンポーネントは crate::jades::verify_jades によって検証される。pverify は JWS JSON Serialization の B-B のみを検証する。JAdES 抽出器は、スコープ外の形態を誤検証するのではなく、明示的に分類し拒否する（crates/pverify-jades/src/parse.rs:212）。sigD detached ペイロード参照は JadesUnsupportedReason::DetachedSigD（parse.rs:232）へマップされ、より高いベースラインレベル（B-T+）は HigherLevel（parse.rs:250）へマップされ、JAdES ベースラインプロパティを担持しない素の JWS は NotJadesBaseline（parse.rs:261）へマップされる。Compact serialization も同様にスコープ外である。各拒否は誠実な INDETERMINATE の事実であり、§I「断言できないことは断言しない」の規律に一貫している。RFC 7797 の b64:false 非エンコードペイロードは抽出器によって処理されるが、それは b64 が crit にも現れる場合のみである（parse.rs:116）。要求される crit 宣言を伴わない b64:false は、静かに受理されるのではなく誠実に取り扱われる。

4.3.4 CAdES アーム（DetectedFormat::Cades、残余のデフォルト）

PDF/XML/JSON としてスニフされず（かつ ZIP として捕捉されなかった）ものはすべて verify_cades（verify.rs:326、verify.rs:475 に定義）へ手渡される。これは単一エントリのアームである。ちょうど一つの SignatureEntry を生成する。verify_cades は SignedDataParser を介して入力を CMS SignedData（RFC 5652）としてパースする。パース失敗は cades_parse_failed_entry（verify.rs:483）となる — 誤分類された非 CMS 入力（例えば PDF/XML/JSON でない任意のバイナリ）は、偽りの出力を生成するのではなく、ここで清潔に失敗することに注意されたい。

このアームには重要な誠実性ルールが存在する。マルチ署名者の CMS は意図的に拒否される。 parsed.signer_info_count > 1 の場合、verify_cades は cades_multi_signer_entry（verify.rs:496-497）を返す。これはサブインディケーション cms_multi_signer_unsupported を伴う INDETERMINATE である。ソースはその根拠を記録している。029 以前のパーサは最初の SignerInfo のみを静かに保持し、N>1 の署名者を持つ CMS を一つしか存在しないかのように報告していた — これは、副署ワークフローや監査のために検証者（信頼当事者）が必要とする署名者集合の証拠を隠蔽してしまう事実報告のギャップであった（verify.rs:487-495）。signatures[] が SignerInfo 一つにつき一エントリのモデルへ拡張されるまで、誠実な答えは、切り詰められた署名者集合を検証することではなく拒否することである。CAdES は BES/B-B、B-T（signature-time-stamp）、B-LT、B-LTA（ETSI EN 319 122-1 §6.3.4 のインプリント再計算を伴う archive-time-stamp-v3）にわたってサポートされる。CAdES の章を参照。

4.4 detached コンテンツと attached コンテンツ

CAdES は detached となりうる唯一の系統である — すなわち署名されたペイロード（eContent）が CMS の外部に存在し、署名とともに供給されなければならない場合である。PAdES、XAdES（enveloped）、JAdES、ASiC はいずれも構造的にペイロードを担持または参照するため、detached コンテンツの問題は CAdES に対してのみ生じ、それは完全にホスト層で解決される（それはファイル I/O と CLI フラグの内省を要し、カーネルはそれを実行できない）。このロジックは、crates/pverify-cli/src/main.rs:554-606 において四セルからなる FR-027/FR-028 コンテンツソースマトリクスを実装する。

CLI はまず安価なプレフィックスチェックで系統を判定する。is_pdf（main.rs:535）、is_asic（pverify_asic::is_zip、main.rs:540）、looks_xml（main.rs:541）、looks_json（main.rs:553）である。これら四つのいずれかであれば、コンテンツソースマトリクスは完全にバイパスされ（main.rs:554）、content_source_override = None となる — PAdES は構造的に attached であり、XAdES はコンテンツソース解決の前に拒否され、ASiC は eContent を持たず --detached-content を取らず、JAdES はそのペイロードを JWS 構造内に埋め込む。入力がこれら四つのいずれでもない場合 — すなわち CAdES と推定される場合 — のみマトリクスが動作する。

明白に誤った組み合わせを防ぐためのハードな事前チェックがある。--detached-content を PDF 署名とともに供給することは、いかなるマトリクスロジックよりも前の呼び出しエラー（終了コード 2）である（main.rs:507-512）。なぜなら PAdES は決して detached ではないからである。

CAdES 入力に対して、CLI は SignedDataParser で CMS 構造を覗き、存在すれば非空の eContent を抽出し（main.rs:565-568）、続いて (eContent が存在するか?, --detached-content が供給されたか?) に対してマトリクスを適用する。

最後のセルが本節の中心的な誠実性ルールである。pverify は空のペイロードを静かに検証することは決してない。コンテンツが供給されない detached CAdES 署名は、ゼロバイトに対して検証されるのではなく CLI で拒否される（main.rs:599）。衝突セル（存在するが相違する）も同様に、二つの矛盾するペイロードのうちどちらを呼び出し者が意図したかを推測するのではなく拒否する。

解決されたタグは content_source / content_source_redundant としてリクエストにスレッドされる（第3章 §リクエスト組み立て）。オーバーライドが None の場合（PDF/XML/JSON/ASiC のケース、あるいは CLI が覗けなかった任意の CAdES）、検証パイプラインは自身の構造的デフォルトを適用する。CAdES は detached_content_bytes より埋め込みの eContent を優先し、拒否/PAdES エントリは常に Embedded である（crates/pverify-core/src/verify.rs:121-131）。

4.5 ASiC-S / ASiC-E 検出と ZIP 優先順位ルール

ASiC（EN 319 162）は CAdES または XAdES 署名を ZIP コンテナ内にパッケージするため、ASiC 入力は ZIP のローカルファイルヘッダマジック PK\x03\x04 で始まる。そのマジックは detect_format の分岐ではないため、ZIP はさもなければ CAdES 残余のデフォルトへ素通りして誤分類されてしまう。pverify は、ホストとカーネルにわたって分割された二段階の優先順位ルールでこれを防ぐ。

4.5.1 ホスト: ZIP 優先の抽出

CLI は任意の ZIP 入力を、PDF/XML/CAdES スニフの前にASiC 抽出器へ経路付けする（crates/pverify-cli/src/main.rs:723）。pverify_asic::is_zip がプレフィックステストである（crates/pverify-asic/src/lib.rs:35、bytes.starts_with(b"PK\x03\x04")）。成功時には、抽出された Vec<AsicSignature> が request.asic_signatures へスレッドされる。NotAsic/抽出失敗の場合、チャネルは空のままにされる（.unwrap_or_default()）。よってカーネルは ASiC 署名を持たない ZIP マジックを見て、入力を CAdES として誤分類するのではなく、誠実な asic_unsupported_container の事実を発する（main.rs:716-727）。WASM ホストはバイト単位で同一の経路付けを行う（web/pverify-wasm/src/lib.rs:362）。

4.5.2 カーネル: ASiC チャネル優先、続いて ZIP マジック捕捉

verify_with はカーネルでも同じ優先順位を強制する（crates/pverify-core/src/verify.rs:189-235）。これは detect_format が呼ばれるよりも前の、二つの順序付けられたチェックである。

1. asic_signatures が非空（verify.rs:195）: ホストが ASiC 署名を見つけたので、それぞれが crate::asic::verify_asic_signature を介して独立に検証され — 内側の署名一つにつき一つの SignatureEntry — verify_with は直ちにリターンする。内側の署名は既存の detached CAdES / XAdES パイプラインへ委譲される（verify.rs:194 のコメントがこれを明示している）。
2. ASiC 署名を持たない ZIP マジック（verify.rs:227）: request.signature_bytes.starts_with(b"PK\x03\x04") であるが ASiC チャネルが空の場合、入力は認識可能な ASiC コンテナではない ZIP である（あるいはホストが分類しきれないハードな抽出失敗である）。verify_with は単一の asic_unsupported_entry（INDETERMINATE、asic_unsupported_container）を発してリターンし、それが detect_format に到達して CAdES へ誤経路付けされることは決してない（verify.rs:222-235）。

両チェックがともに失敗した後にのみ、verify_with は detect_format を呼び出す（verify.rs:239）。これが、カーネルの分類順序（ASiC チャネル → ZIP マジック → detect_format）がホストの順序（ZIP → PDF → XML → JSON → CAdES）と異なる構造的理由である。

4.5.3 コンテナ内部のプロファイルと系統の検出

pverify_asic::extract（crates/pverify-asic/src/lib.rs:50）が実行されると、それは ZIP をパースし、続いて detect::detect（crates/pverify-asic/src/detect.rs:76）でコンテナを分類する。これは、パッケージングの逸脱をすべて静かに許容するのではなく記録する、ベストエフォートの認識である（FR-001a）。検出には三つの出力がある。プロファイル（ASiC-S 対 ASiC-E）、主要な署名系統（CAdES 対 XAdES）、そして AsicDeviation のリストである。

プロファイル（ASiC-S 対 ASiC-E）。 適合する mimetype エントリは権威的である。application/vnd.etsi.asic-s+zip → ASiC-S、application/vnd.etsi.asic-e+zip → ASiC-E（detect.rs:14-15、detect.rs:85-87）。mimetype はさらに EN 319 162 に従い最初のエントリかつ STORED（無圧縮）でなければならない。違反は MimetypeNotFirstEntry / MimetypeCompressed の逸脱として記録されるが、それ自体ではコンテナを失格にはしない（detect.rs:97-112）。欠落または非適合の mimetype は MimetypeMissing / MimetypeNonConformantValue を記録し、レイアウト推論へフォールバックする（detect.rs:88-96、detect.rs:136）。

レイアウト推論 infer_profile（detect.rs:147）は、mimetype が不在または非適合のときに適用される。任意の ASiCManifest の存在は ASiC-E を含意する（detect.rs:149）。そうでなければ、平易に命名された単一の署名ファイル（META-INF/signature.p7s または META-INF/signatures.xml、数値サフィックスなし）は ASiC-S を含意し、一方で数値サフィックスまたは二つ以上の署名は ASiC-E を含意する（detect.rs:157-168）。

系統（CAdES 対 XAdES）。 検出は META-INF/ のエントリ名を大文字小文字を区別する述語でスキャンする。is_cades_signature は META-INF/signatureNNN.p7s にマッチし（detect.rs:45）、is_xades_signature は META-INF/signaturesNNN.xml にマッチし（detect.rs:54）、is_asic_manifest は META-INF/ASiCManifest*.xml にマッチするが、ASiCArchiveManifest（LTA、スコープ外）と OpenDocument の manifest.xml は意図的に除外する（detect.rs:65-70）。family フィールドは主要な系統を記録する（両方が存在する場合は CAdES が優先される、detect.rs:129）が、ディスパッチには使われない — それは診断用フィールドである（detect.rs:35-39）。代わりに extract は実際に存在するすべての系統を処理する。出力を CAdES 署名（lib.rs:65）と XAdES 署名（lib.rs:68）で独立に拡張するため、混在コンテナ（signature*.p7s と signatures*.xml の両方）はいかなる署名も取りこぼさない（FR-014/FR-020、lib.rs:56-70）。

非 ASiC の境界。 detect::detect は、アーカイブが CAdES 署名ファイルも XAdES 署名ファイルも持たないとき、None を返し — extract はそれを AsicError::NotAsic（lib.rs:52-54）へマップする（detect.rs:122-124）。ソースは、適合する mimetype だけでは不十分であることを明示している。検証すべき署名材料が存在しなければならない（detect.rs:119-121）。この NotAsic の帰結こそが、ホストに asic_signatures を空のままにさせる原因であり、カーネルはそれを asic_unsupported_container として表出する（§4.5.2）。ASiC-E CAdES コンテナでは、CAdES は ASiCManifest のバイトに署名し、各 DataObjectReference のダイジェストはカーネルで再計算される。ASiC-S CAdES コンテナでは、CAdES は単一の非 mimetype データオブジェクトに直接署名する（lib.rs:110-139）。

4.6 ディスパッチ後: 集約はアームを通じて一様である

どのアームが実行されたかによらず、すべての経路は Vec<SignatureEntry> を生成し、verify_with 内の共通の末尾へ再収束する（crates/pverify-core/src/verify.rs:329-342、および verify.rs:212-218 の ASiC 早期リターンにおける等価物）。ステップごとの弱アルゴリズムフラグは aggregate_for_header を介してヘッダへ畳み込まれ、統合された資料インベントリは derive_validation_objects によって完成したレポートツリーから導出される — これはネットワークアクセスも新たな暗号も加えない純粋な &Report の読み取りである（verify.rs:341）。詳細な ETSI インディケーションの集約（aggregate_etsi、重大度の順序付けと決してマスクしない層化）は第5章 §5.7 および結果モデル（第14章）で扱う。分類の観点からの鍵となる不変条件は、出力の形状 — 一つ以上の SignatureEntry 値とヘッダ — が、どのフォーマットが検出されたかによらず同一である、ということである。よって下流の消費者は単一の一様なスキーマをパースする。

4.7 失敗モードと「断言できないことは断言しない」の規律

分類とディスパッチの層は、配置も検証もサポートレベルでできない入力に対して判定を捏造することは決してない。下表は、この層に由来する誠実な degradation の帰結を集めたものである。

二つの失敗カテゴリの区別には原則がある。CLI 呼び出しエラー（終了コード 2） は、リクエストそのものが矛盾している、または仕様が不足している場合に予約されている — PDF は detached になりえず、detached CAdES はそのコンテンツを必要とし、二つの矛盾するペイロードがともに署名対象であることはありえない。INDETERMINATE レポートエントリ（終了コード 0） は、リクエストは整形式であるが pverify がそのサポートレベルで事実を確立できない場合に予約されている — 認識されないコンテナ、サポートされない JAdES serialization、現行スキーマが表現できないマルチ署名者集合。後者は機械可読の事実として報告されるため、下流の監査人はなぜ判定に至らなかったのかを正確に見ることができ、これは憲法 §I に一貫している。

4.8 不変条件のまとめ

• 単一割り当て。 すべての入力は {ASiC, PDF, XAdES, JAdES, CAdES} のちょうど一つに割り当てられる。CAdES は残余のデフォルトであり、ASiC は detect_format の前に捕捉されるため ZIP マジックが素通りすることは決してない。
• 安価かつプレフィックスのみ。 分類は先頭バイト（マーカー、BOM、最初の非空白文字）のみを読むため、決定論的であり、ファイル全体の内容に依存しない。
• ホスト/カーネルの一致と CLIとWASMのパリティ。 ホストの構造パース選択とカーネルの検証アームディスパッチはバイト単位で同一の述語を用い、CLI・カーネル・WASM ホストにわたって三重化されている。よって経路付け — したがってレポート — はいずれのホスト上でもバイト単位で同一である。
• 静かな空の結果なし。 各フォーマットアームは、ホストが何も抽出しなかった場合でも、少なくとも一つの説明的な SignatureEntry を返す。
• 静かなペイロードなし。 コンテンツのない、あるいは矛盾するコンテンツを伴う detached CAdES は、想定されたペイロードに対して検証されるのではなく CLI で拒否される。
• 誠実な degradation。 ある系統に合致するもののサポートレベルで検証できない入力は、正確なクローズドな列挙のサブインディケーションを伴って INDETERMINATE へ degrade し、捏造された TOTAL_FAILED/TOTAL_PASSED となることは決してない（憲法 §I）。

5. CMS / CAdES の検証

本章では、pverify が RFC 5652 Cryptographic Message Syntax（CMS）の SignedData をどのように解析し、その上に構築された CAdES（ETSI EN 319 122）高度電子署名（AdES）をどのように検証するかを規定する。CMS SignedData はツール全体の根幹をなす構造である。CAdES の検証はこれを直接対象とし、PAdES（第6章）はこれを PDF の /Contents に埋め込み、RFC 3161 タイムスタンプトークン（第12章）はそれ自体が SignedData であり、ASiC（第7章）はその内部 CAdES 署名を本章で説明するのと同一のパイプラインに委譲する。したがって CAdES のパスは、他の形式の章がそれに照らして記述される際の参照実装である。他の形式が「CAdES パイプライン」に委ねると述べる箇所は、§5.7 に文書化されたオーケストレーションを指す。

本章で参照されるすべてのコードは、no_std + alloc の、I/O を行わない検証カーネル pverify-core 内に存在する（カーネルとホストの境界については第3章を参照）。構造的な CMS パーサは crates/pverify-core/src/cms/ にあり、署名ごとのオーケストレーションは crates/pverify-core/src/verify.rs の関数 verify_cades にある。JNSA が必須とする2つのバインディングチェック — 署名者識別 + ESS署名証明書バインディング（slice 025）と content-type バインディング（slice 026）— はそのオーケストレーションに統合されており、§5.5 および §5.6 に文書化されている。

5.1 スコープと AdES レベルの語彙

pverify は4つの CAdES ベースラインレベルを認識し、verify_cades によってレポートの SignatureFormat 列挙へ投影する（crates/pverify-core/src/verify.rs:1034-1042）：

繰り上げの階梯は厳密に順序付けられている（archive_timestamps が空でなければ勝ち、次に has_lt_lta_payload、次に timestamps が空でない、それ以外は BES）。このレベルは、入力が主張するプロファイルではなく、存在する構造から認識される事実である。ワイヤ列挙には「B-ES と B-B」を区別する別個の項目は存在しない — CAdESBes はレガシーの CAdES-BES（RFC 5126）と EN 319 122-1 の B-B ベースラインの両方を包含する。これは、pverify が読み取る構造的表面（署名証明書 + 署名属性、信頼されたタイムスタンプなし）が同一であるためである。

単一署名者の CMS がサポートされるケースである。複数署名者の SignedData は、最初の署名者のみを報告するのではなく、意図的に拒否される（§5.4.4）。

5.2 CMS SignedData 構造パーサ

5.2.1 設計：型付きデコーダではなく、寛容な TLV ウォーカ

パーサは crates/pverify-core/src/cms/signed_data.rs の型 SignedDataParser である。これは意図的に、厳密にフィールド順序付けされた ASN.1 デコーダではなく、BER/DER TLV ツリー（crate::ber::parse_ber_tlv で構築される）上を歩く寛容な構造ウォーカである。モジュールのヘッダはその出自を記録している。すなわち、CAdES/PAdES と同じ外形を持つ RFC 5652 SignedData である civ プロジェクトの ICAO 9303 SOD パーサから派生したもので、LDS パスポート固有の抽出は除去されている（憲章 §VII はパスポートドメインのコードを PKI 表面に持ち込むことを禁じている）。

ウォーカは、下流のチェックが必要とする最小限のフィールド集合を抽出する：

ウォーカは、素の RFC 5652 ContentInfo SEQUENCE、または外側がアプリケーションタグ 0x77 でラップされたもの（後者は ICAO SOD のフレーミングであり、civ を経由してラウンドトリップするテストベクタがここでもラウンドトリップするよう保持されている — SignedDataParser::parse）のいずれかを受理する。SignedData の位置特定は、最初の子が OID である最初の SEQUENCE を見つけ（find_signed_data_content）、content [0] EXPLICIT ラッパを通って内側の SignedData SEQUENCE へ降りていくことによって行う。

5.2.2 フィールド判別の規則とその機微

SignedData SEQUENCE 内で、extract_signed_data_components は小さなステートマシンによって子要素を宣言順に歩く：

• digestAlgorithms の後の最初の SEQUENCE は encapContentInfo として扱われ（saw_encap フラグ）、そこから eContentType OID と任意の [0] EXPLICIT eContent が抽出される。CAdES は id-data（1.2.840.113549.1.7.1）を用いる。埋め込まれた RFC 3161 トークンは id-ct-TSTInfo（1.2.840.113549.1.9.16.1.4）を担う。
• 最初の SET（0x31）が digestAlgorithms であり、それより後のいずれかの SET が signerInfos である。これは、このレベルに SET が最大2つしか存在しないことに依拠している — 適合する単一署名者の CAdES/PAdES では真である。ウォーカは signerInfos SET から signer_info_count を記録し、複数署名者ゲート（§5.4.4）が発火できるようにする。
• certificates [0] IMPLICIT（0xA0）は各 Certificate SEQUENCE の値バイトを生成する。完全な DER ヘッダは下流で再付加される（§5.4.1）。

sid の捕捉（extract_signer_info）は、パーサがタグについて正確でなければならない唯一の箇所である。SignerInfo.sid は version（INTEGER, 0x02）の直後の要素である。ウォーカは version の後の最初の要素を捕捉し、それを完全な DER へ再エンコードする（reencode_tlv）。この CHOICE は issuerAndSerialNumber（SEQUENCE, タグ 0x30）または subjectKeyIdentifier のいずれかであり、後者は [0] IMPLICIT OCTET STRING であって、そのワイヤタグは構築型の 0xA0 ではなく、プリミティブのコンテキストタグ 0x80 である。捕捉したバイトの解釈は、埋め込み証明書集合が利用可能となる選択箇所（§5.5.1）まで遅延される。

signedAttrs、signature、unsignedAttrs の各フィールドはそれぞれ一度だけ捕捉される（is_none() ガード）ため、不正な2番目の SignerInfo が最初の署名者のデータを上書きすることは決してない — ただし個数は依然としてインクリメントされ、ゲートが切り詰めを誠実に拒否できるようにする。

5.2.3 失敗時の挙動

空の入力は Error::Parse("empty CMS SignedData input") を表面化させる。切り詰められた 0x77 ラッパは Error::Ber を表面化させる。認識可能な SignedData SEQUENCE を持たない入力は、（エラーではなく）すべてのフィールドが空の SignedDataParser を返す。検証パイプラインはその後、構造的な欠落を事実として報告する。これらの挙動は signed_data.rs 内のユニットテスト（例えば parse_empty_input_returns_err、parse_returns_empty_fields_when_no_signed_data_seq_found）によって固定されている。

5.3 SignedAttrs の正規化と messageDigest チェック

5.3.1 SignedAttrs の正規化（RFC 5652 §5.4）

signedAttrs が存在する場合、署名は生の [0] IMPLICIT 本体ではなく、構成要素を昇順のオクテット順にソートした SET OF Attribute（ユニバーサルタグ 0x31）としての DER 再エンコードに対して計算される。これは RFC 5652 §5.4 / X.690 §11.5 の規則であり、検証者がワイヤ上の順序や暗黙タグの置換とは独立に、署名されたオクテットを再構築できるようにするために存在する。

crates/pverify-core/src/cms/canonical.rs — canonicalise_signed_attrs — がこれを実装する。すなわち、格納された値バイトを構成要素の Attribute TLV へ分割し、sort_unstable()（辞書式バイト比較）でソートし、0x31 タグ付きの SET として再放出する。モジュールヘッダは、ここで辞書式バイト比較が X.690 §11.5 のゼロパディング規則と等価である理由を文書化している。すなわち、外側のタグを共有する相異なる DER TLV では、パディングの考慮が生じる前に長さオクテットが分岐するため、より単純な比較で十分である。

5.3.2 messageDigest 比較（RFC 5652 §11.2）

verify_content_digest（crates/pverify-core/src/cms/verify.rs）：

1. digest_algorithm_oid からダイジェストアルゴリズムを読み取る（HashAlg::from_oid_bytes を介してマップ。SHA-1 および SHA-2 のみ — SHA-3 はスコープ外、cms/signed_attrs.rs::oid_to_hash_name）。
2. 署名がコミットするバイト — attached CAdES では埋め込みの eContent、detached CAdES では --detached-content のバイト（解決規則は §5.4.2）— に対して digest(content) を計算する。
3. find_message_digest_attribute を介して signedAttrs を歩き messageDigest 属性（1.2.840.113549.1.9.4）を探し、その OCTET STRING 値を読み取る。
4. 比較を行い、宣言されたダイジェスト、計算されたダイジェスト、ブール値の digest_match、および別個の covered_content_sha256（署名自身のダイジェストアルゴリズムによらず、SHA-256 でハッシュされた生のカバー対象バイト — slice 016 の診断データ。これにより signed_content 検証対象オブジェクトのダイジェストは、SHA-384/512 署名であっても正しい）を担う ContentDigestCheck を生成する。

この関数は判定を一切放出しない — 観測したダイジェストの事実を記録する。messageDigest_mismatch へのマッピングは後に aggregate_etsi（§5.7.4）で発生し、かつコンテンツが実際に供給された場合に限る（コンテンツのない detached 署名は、失敗としてではなく評価不能という事実として digest_match = false を生む）。

5.3.3 SignedAttrs 署名チェック

verify_signed_attrs（crates/pverify-core/src/cms/verify.rs）は signedAttrs を正規化し（§5.3.1）、署名者証明書の SubjectPublicKeyInfo DER を抽出し（RustCrypto 検証器が期待するオクテット列に一致するよう x509-cert を通して再エンコードする）、SPKI のアルゴリズムファミリと宣言されたダイジェストを対にして署名者の signatureAlgorithm OID を導出し、crate::crypto::verify_with_alg を介して検証する。

signatureAlgorithm の導出（derive_signer_sig_alg_oid）が必要なのは、構造パーサが SignerInfo の signatureAlgorithm フィールドを別個に表面化させないためである。この対応付けは、適合する SignerInfo が担うであろうのと同一の OID を再現する：

認識されない SPKI ファミリは SignedAttrsSignature::Failed { cause: UnsupportedAlgorithm } を生む。検証して失敗した場合は Failed { cause: Other }（または認識された OID で鍵がデコード不能の場合は MalformedPublicKey、slice 010）を生む。型付きの cause 列挙（SignedAttrsFailureKind）は失敗箇所で刻印されるため、aggregate_etsi は reason 文字列の接頭辞ではなく列挙でルーティングを行う（slice-029 の堅牢化 — 人間可読の理由のリファクタが、もはや判定を黙って再分類することはできない）。

結果は SignedAttrsCheck である。その signed_attrs_digest_match は独立したダイジェスト比較ではない。これは、署名全体に対する verify_with_alg（宣言されたダイジェストでハッシュされた正規化済み signedAttrs、署名者の SPKI、および signature オクテット）が成功したときにちょうど Some(true) に設定され、それ以外では Some(false) に設定される — したがってこのフィールドは、別個にチェックされる述語ではなく、検証結果の派生エイリアスである。RSA/ECDSA/Ed25519 の検証は、素のダイジェスト等価性ではなく署名プリミティブ全体をカバーするため、将来の PSS/ECDSA パスではここでハッシュのみの失敗と完全検証の失敗を区別しうる。signedAttrs が存在しない場合、RFC 5652 §5.4 の eContent への署名パスは配線されていない — 関数は構造的な Failed を表面化させ、パイプラインが判断できるようにする（CAdES B-B は signedAttrs を必須とする）。

5.4 CAdES オーケストレーション（verify_cades）

verify_cades（crates/pverify-core/src/verify.rs:475）はトップレベルの署名ごとの CAdES 検証器であり、detect_format が非 PDF・非 XML・非 JSON・非 ASiC の入力を CAdES パスへルーティングした後に verify_with から呼び出される（detect_format は DetectedFormat::Cades へフォールスルーする）。ちょうど1つの SignatureEntry を返す。

5.4.1 ステージシーケンス

5.4.2 証明書の再構成とコンテンツの解決

パーサが格納した本体のみの証明書スライスは、完全な DER SEQUENCE へ再ラップされ（reconstitute_certificate_der）、crate::x509::parse_certificate で解析される。解析不能な単一の証明書はパイプラインを沈めるのではなくスキップされる。CMS に埋め込まれた証明書の個数（cms_cert_count）は、ホストの extra_certificates（例えばバンドルの certificates/）が追加される前に記録される。なぜなら、ホストの中間証明書はチェーン材料としては適格だが、署名者としては決して適格でない — 署名者は常に CMS 埋め込みの接頭部分から選択される（§5.5.1）からである。

ダイジェストおよびアーカイブタイムスタンプのインプリントのためのコンテンツ解決：埋め込みの eContent（attached CAdES）は、両方が存在しかつ空でないときは常に detached_content_bytes に勝る。CLI のプレフライトは、両方が供給されていればすでにバイト等価性を強制している。観測された出所は SignatureEntry に対し ContentSourceTag::Embedded または Detached として記録される。

5.4.3 unsigned-attribute の投影（T/LT/LTA 材料）

project_unsigned_attrs（crates/pverify-core/src/cms/unsigned_attrs.rs）は unsignedAttrs 本体を歩いて UnsignedAttrsProjection へ投影する：

これらは、レポートの EmbeddedValidationData 監査投影と、以下の失効/タイムスタンプパイプラインの双方に供給される。

5.4.4 複数署名者の拒否

signer_info_count > 1 の場合、verify_cades は cades_multi_signer_entry を返す — サブインディケーション cms_multi_signer_unsupported を伴う INDETERMINATE（crates/pverify-core/src/verify.rs:496、:1890）。これは slice-029 の事実報告に関する是正である。それ以前は、パーサが最初の SignerInfo のフィールドのみを黙って保持していたため、複数署名者の CMS が単一署名者が存在するかのように報告されていた — これは、検証者（信頼当事者）が連署や監査のワークフローで重視する署名者集合の証拠を隠していた。レポートが SignerInfo ごとに1エントリのモデルへ拡張されるまでは、誠実な答えは拒否であって、切り詰められた署名者集合に対する判定では決してない。これは憲章 §I「断言できないことは断言しない」の直接的な適用である。

5.5 署名者識別と ESS バインディング（slice 025）

slice 025-cades-signer-binding は、JNSA デジタル署名検証ガイドライン（第1.1版）の 表5.5.2-1 の必須チェック2件（JNSA ギャップ #90/#91）をクローズする。これを規律する明確化（specs/025-cades-signer-binding/spec.md）：バインディング破綻 → TOTAL_FAILED、識別不能 → INDETERMINATE。PAdES はその埋め込み CMS の評価を CAdES パスへ委譲する（pades/mod.rs）ため、両チェックは自動的に PAdES へ拡張される。

5.5.1 SignerIdentifier の解決

slice 025 以前、pverify はヒューリスティック（「CMS 埋め込み集合の最初の非 CA 証明書」）で署名者を選択していた。署名値が照合して検証されるべき署名者は SignerInfo.sid（RFC 5652 §5.3）によって識別され、ヒューリスティックと真の sid ターゲットとの不一致は事実報告上のギャップである。

SignerIdentifier::parse（crates/pverify-core/src/cms/ess.rs）は捕捉した sid DER を解析する：

• 外側タグ 0x30 → IssuerAndSerial { issuer_dn, serial }。発行者の Name SEQUENCE は完全な DER へ再エンコードされ、Certificate::issuer_dn とまったく同様に match_dn へ供給できる。
• 外側タグ 0x80（プリミティブの [0] IMPLICIT OCTET STRING）→ SubjectKeyId(octets)。
• それ以外のタグ、または構造的失敗 → Err → 不正経路。

select_signer_by_sid（crates/pverify-core/src/verify.rs:1096）は次に、最初の cms_cert_count 個の埋め込み証明書の内部に限ってインデックスを解決する：

• IssuerAndSerial：シリアル番号の等価性 かつ 発行者DNの連結（x509::name::match_dn）によって照合する。
• SubjectKeyId：証明書の subjectKeyIdentifier 拡張によって照合する。

その結果は SignerIdentifierCheck { sid_form, match_outcome } へ投影される：

NotFound/Malformed の場合、関数は監査用にチェーンを組み立てられるよう、依然としてレガシーのヒューリスティックインデックスをレポートの足場として返す — ただし判定はいかなる署名/ダイジェストゲートよりも前に match_outcome でゲートされるため、ヒューリスティックのフォールバックが黙って「照合対象として検証される証明書」になることは決してない。

5.5.2 ESS 署名証明書バインディング（RFC 5035）

ESS の signing-certificate（v1、SHA-1 固定）/ signing-certificate-v2（宣言されたアルゴリズム、SHA-256 デフォルト）署名属性は、署名者証明書をハッシュによって暗号学的に固定し、証明書置換（同一の鍵ペアで再発行または偽造された証明書）に対して防御する。parse_ess_signing_certificate（crates/pverify-core/src/cms/ess.rs）はこの属性（id-aa-signingCertificate 1.2.840.113549.1.9.16.2.12 / id-aa-signingCertificateV2 …2.47）を見つけ、その最初の ESSCertID/ESSCertIDv2 を解析する：

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

署名者証明書のバインディングであるのは最初の ESSCertID のみであり、後続のエントリはチェーン証明書を記述するものでスコープ外である。v2 では、先頭の SEQUENCE が明示的な hashAlgorithm であり、その不在は SHA-256 デフォルトを意味する。issuerSerial の issuer は GeneralNames である。pverify は directoryName [4] GeneralName（構築型コンテキストタグ 0xA4）の内側の Name DER を抽出し、directoryName 以外の形式はすべて評価不能として扱う（Mandatory-if-Exists：失敗とはしない）。

compute_ess_binding（crates/pverify-core/src/verify.rs:1195）は sid で選択された署名者証明書に対してバインディングを計算する：

• 宣言されたアルゴリズムで digest(signer_cert.der_bytes) を再計算し、certHash と比較する → CertHashCheck { hash_match }。
• issuerSerial が存在し directoryName 形式である場合：その DN 連結とシリアルを署名者証明書と比較する → IssuerSerialCheck { matches }。
• ESS-v1（SHA-1）は受理してフラグを立てる：WeakAlgorithmFlag（役割 EssSigningCertificateDigest）が署名者チェーンステップに付加される。これは決して拒否しない（FR-012a）。

3つの評価不能 / 不正の処理（いずれも憲章 §I「断言できないことは断言しない」）：

• 未知 / 非対応の宣言ハッシュ OID → hash_match: None。
• directoryName 以外の issuerSerial GeneralName → matches: None。
• 構造的に不正な ESS 属性（slice-029）→ hash_match: None を伴う present: true（不在とは区別される。不在は present: false のまま、インディケーションへの影響なし）。既存の優先順位はすでに、それ以外は合格となる署名における hash_match: null を INDETERMINATE / signing_certificate_digest_not_evaluable へルーティングするため、新たなサブインディケーションは不要であった。

5.6 Content-Type バインディング（slice 026）

slice 026-cades-contenttype-binding は RFC 5652 §5.3 の content-type 署名属性の等価性チェック（JNSA が必須とする CAdES ステップ）を追加する。content-type 属性（1.2.840.113549.1.9.3）は EncapsulatedContentInfo.eContentType と等しい OID を担わなければならない（MUST）。さもなければ、署名を無効化することなくカプセル化されたコンテンツタイプを置換できる攻撃者が、署名されたバイトの意味を変えてしまうことになる。

find_content_type_attribute（crates/pverify-core/src/cms/verify.rs）は messageDigest の走査の構造的なクローンであり、属性 OID と、値 SET がちょうど1つの OBJECT IDENTIFIER を保持しなければならない点のみが異なる。これは Present(oid)、Absent、または Malformed を返す。compute_content_type_check（crates/pverify-core/src/verify.rs:1388）は生の OID バイト等価性によって比較し、結果を伴う ContentTypeCheck を生成する：

RFC 5652 §5.3 は、いずれかの署名属性が存在する場合にこの属性を MUST-present とする。よって Missing は TOTAL_FAILED である一方、不正な属性または eContentType の不在（断定回避）は INDETERMINATE である。

5.7 タイムスタンプ、オブジェクトごとの VRT、およびインディケーションの集約

5.7.1 signature-time-stamps（B-T）

各 signature-time-stamp トークン（RFC 3161、RFC 5126 §6.3）は署名者の signature OCTET STRING にコミットする。verify_cades はそれらのバイトを役割 SignatureTimestamp で verify_timestamp_token（第12章）へインプリント入力として渡す。埋め込み証明書は TSA チェーンの中間証明書として機能し、署名者と同一のアンカーストアに対して検証される。

5.7.2 archive-time-stamps-v3（B-LTA）

各 archive-time-stamp-v3 について、archive_v3_imprint_input（crates/pverify-core/src/cms/canonical.rs）は ETSI EN 319 122-1 §6.3.4 の正規インプリント入力を再計算し、それを verify_timestamp_token（役割 ArchiveTimestamp）へ渡す。不一致は archive_timestamp_imprint_mismatch（TOTAL_FAILED）である。

正規入力は、次の順序で連結する：(1) コンテンツバイト（埋め込み eContent または detached）、(2) ディスク上の SET-OF 順（正規ソートではない）での各埋め込み証明書の完全な DER、(3) SignedData の CRL スロット（現状は常に空 — パーサが表面化させず、pverify の LTA フィクスチャは失効材料を unsignedAttrs に置く）、(4) signedAttrs の値バイト、(5) 署名者の signature 値バイト、(6) 再計算対象のアーカイブ TS およびそれより後のすべてを除去した unsignedAttrs。これにより、逐次的なアーカイブタイムスタンプの連鎖がハッシュチェーンを形成する（unsigned_attrs_without_archive_ts_at_or_after 内の checkpoint_index 機構）。

モジュールはこれを v0.3 の簡易エンコーダとして文書化している。これは決定論的なバイトレシピ（境界を明確に保つため、スロット 4〜6 に pverify 側の SA/SI/UA 長さ前置フレーミングを伴う）であり、ETSI §6.3.4 が問題とするあらゆる改変 — 改竄されたコンテンツ、埋め込み証明書/CRL、signedAttrs、signature、または自分自身以外の任意の unsigned-attribute の変更 — を検出するのに十分である。これはまだ完全に一般的な §6.3.4 エンコーダではない（複数アーカイブのレイヤリング、certVals/revocVals の更新セマンティクス、ディスク上の SET-OF 順序のコーナーケース）。これは黙った近似ではなく、認識されたスコープの制約である。インプリントが計算できない場合（コンテンツが利用不能）、インプリントは参考情報としてのみ扱われる。複雑な多層構造にわたる LTA アーカイブを検証する監査者は、インプリントの結果を完全な §6.3.4 適合性の断言ではなく、肯定的な指標として扱うべきである。

5.7.3 オブジェクトごとの VRT と TSA チェーンの失効

タイムスタンプトークンが populate された後、crate::vrt::derive_vrt（第12章）は再帰的な外側カバーのグラフを構築し、各オブジェクト — 署名者チェーン、署名者の署名、各 signature-TS、各 archive-TS — に固有の検証基準時刻（VRT）を割り当てる。署名者チェーンはその後、その VRT が request_at と異なる場合は常に vrt.signer_chain.value において再検証される（validate_path → wire_chain_step_signatures → 弱アルゴリズムのフラグ付け → ESS フラグの再付加 → apply_revocations を再実行する）。VRT が request_at と等しい場合、再検証はバイト単位で同一になるためスキップされる。各タイムスタンプの TSA チェーンも同様にそれ自身の VRT において再検証され、各々はそのオブジェクトの VRT において apply_tsa_chain_revocation_for_token（slice 033、crates/pverify-core/src/verify.rs:1552）を介して失効検証され、埋め込みの revocation-values OCSP/CRL 材料に加え、検証モードに応じた構成済みフェッチャを消費する。これはすべてのタイムスタンプに対して無条件で実行される。なぜなら、第一パスの verify_timestamp_token は失効を一切適用しないからである。失効が確認された TSA 証明書は INDETERMINATE / revoked_no_poe へ繰り下げられる — 「タイムスタンプを断言できない」のであって、決して偽造の主張ではない。

OCSP nonce（RFC 8954、slice 035）。 ライブ OCSP フェッチャが発火する場合（オンラインモード）、プラットフォームホストの NonceSource trait 実装（CSPRNG をバックエンドとする）が生成した 16 バイトの nonce を送信する。レスポンダの返答は、同一の nonce を返すか nonce 拡張を省略した場合にのみ受理される（RFC 8954 §2.1）。nonce が不一致の場合、応答は認証されていないものとして扱われ、OCSP の試みは不確定に降格される。実行内 OCSP キャッシュ（OcspCache）は単一の verify_with 呼び出し内でリクエストを重複排除し、同じ certID の取得は実行ごとに最大1回となる。

5.7.4 基本 ETSI インディケーションの集約

aggregate_etsi（crates/pverify-core/src/verify.rs:2343）は、チェーン/署名/ダイジェスト/アーカイブインプリントの所見を、重大度順 TOTAL_FAILED > INDETERMINATE > TOTAL_PASSED で、かつ重大度の層内では最初の所見が勝つという規則で、基本の EtsiIndication へ畳み込む。優先順位の階梯（簡略、評価順）：

1. パス検証の構造的 TOTAL_FAILED（例えば chain_constraints_failure）。
2. archive_timestamp_imprint_mismatch（TOTAL_FAILED）。
3. OCSP レスポンダ署名が検証して失敗（ocsp_responder_signature_invalid、TOTAL_FAILED）。
4. SignedAttrs 署名の失敗 — 型付きの cause でルーティングされる：Other → TOTAL_FAILED / signed_attrs_signature_failed、UnsupportedAlgorithm → INDETERMINATE / signature_algorithm_unsupported、MalformedPublicKey → INDETERMINATE / public_key_malformed。
5. コンテンツダイジェストの不一致（コンテンツが供給された場合のみ）→ TOTAL_FAILED / messageDigest_mismatch。
6. 署名者証明書が CRL/OCSP で失効 → TOTAL_FAILED / signer_certificate_revoked[_via_ocsp]。
7. 非対応アルゴリズム下のアーカイブインプリント、不正な公開鍵のチェーンステップ、非対応のチェーン signatureAlgorithm、名前制約の所見、ポリシー拒否 → さまざまな INDETERMINATE。

終端アンカーのステップのプレースホルダ失効レコードは失効スキャンから除外されるため、陳腐化した CRL のサブインディケーションがアンカー自身に対して誤って放出されることは決してない。

5.7.5 階層化されたインディケーション（証明済みの TOTAL_FAILED を決してマスクしない）

基本のインディケーションは次に、順序付けられた4つの層によって繰り下げられる — 決して上方へマスクされない。各層は、基本がすでに証明済みの TOTAL_FAILED でない場合にのみ作用する：

1. 署名者バインディング（025） — apply_signer_binding_indication（:1324）：署名者識別のゲートは絶対的に最初である（NotFound/Malformed の sid は、いかなる署名/ダイジェスト結果よりも前に評価される。それらは正しく識別された署名者を前提とするからである）。次に ESS の certHash/issuerSerial の不一致は、TOTAL_FAILED でない基本を TOTAL_FAILED へ格上げする。ESS の評価不能なダイジェストは、TOTAL_PASSED となるはずのものを INDETERMINATE / signing_certificate_digest_not_evaluable へ繰り下げる。
2. content-type（026） — apply_content_type_indication（:1441）：不一致/欠落 → TOTAL_FAILED、不正/利用不能 → INDETERMINATE。
3. アルゴリズム妥当性（032、オプトイン） — apply_algorithm_validity_indication（:1480）：--algorithm-policy が供給された場合のみ。失敗/不確定のオブジェクトは INDETERMINATE / crypto_constraints_failure_no_poe へ繰り下げられ、ETSI CRYPTO_CONSTRAINTS_FAILURE_NO_POE を反映する。デフォルトでは無効。無効経路の出力はバイト単位で同一である（第13章）。
4. TSA 失効（033） — apply_tsa_revocation_indication（:1622）：いずれかのタイムスタンプにおいて失効が確認された TSA 証明書は INDETERMINATE / revoked_no_poe へ繰り下げられる。

各層の「すでに証明済みの TOTAL_FAILED でない場合にのみ繰り下げる」というガードが、決してマスクしないという規律である。暗号学的に破綻した署名は、非推奨アルゴリズムや失効した TSA という事実よりも上位にあり、証明済みの失敗がより緩やかな不確定によって上書きされることは決してない。

5.8 閉じた語彙と形式横断の再利用

本章のあらゆる処理は、閉じた SubIndication 列挙（crates/pverify-core/src/report/etsi.rs、ルートの report-schema.json へ 1:1 でミラーされる）へと解決される。自由形式の判定テキストがレポートに到達することはない。関連する CAdES パスのサブインディケーションは次のとおりである：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、および他の形式と共有されるさまざまなアルゴリズム/失効の不確定値。

SignedDataParser と verify_cades のオーケストレーションは、ツールの残りの部分が構築される基盤である。PAdES（第6章）は PDF をホスト側で解析し、埋め込み CMS をこの同一の SignedDataParser + §5.5/§5.6 のバインディングチェックを通して供給し、その上に /DSS//VRI の失効材料を重ねる。RFC 3161 タイムスタンプトークン（第12章）は id-ct-TSTInfo 型の SignedData として SignedDataParser によって解析される。ASiC（第7章）は各内部 CAdES 署名を verify_cades を通してルーティングする。したがって、署名者バインディングの優先順位、型付き cause による失敗ルーティング、決してマスクしない集約の規律は、CAdES 局所の慣行ではなく、観測された暗号学的事実がいかにして ETSI インディケーションになるかについてのツール全体の契約である。

6. PAdES 検証

本章では、pverify が PAdES（PDF Advanced Electronic Signatures、ETSI EN 319 142）をどのように検証するかを規定する。PDF パースを WASM クリーンなカーネルの外側に保つホスト/コアの分割、PDF 署名辞書の射影、/ByteRange の完全性と covers-EOF の規律、インクリメンタルアップデートのリビジョン処理、文書タイムスタンプ（/DocTimeStamp）、日本の公的 PDF の検証を可能にした RFC 5280 §6.1.5 の空ポリシーツリー緩和、そして — 詳細に — PDF が自身について保持する長期検証材料、すなわち文書レベルの /DSS 辞書（/Certs、/CRLs、/OCSPs）、その署名ごとの /VRI サブ辞書、および Adobe revocationInfoArchival CMS 属性を pverify が消費できるようにする branch-034 の作業を扱う。

PAdES 検証器は、意図的な設計として、CAdES を駆動するのと同じ CMS/チェーン/失効/タイムスタンプの機構を再利用する（フォーマットディスパッチについては第4章、CAdES については第5章を参照）。フォーマット固有の表面は小さく、ここではそこに焦点を当てる。オブジェクトごとの検証基準時刻（VRT）の導出は第12章、失効評価は第11章、レポート/スキーマモデルは第14章で扱う。本章では PAdES のパスがそれらに連なる箇所で相互参照する。

6.1 スコープと AdES レベルのサポート

PDF 署名は PDF 署名辞書に埋め込まれた CMS SignedData（RFC 5652）であり、署名対象のコンテンツは CMS の eContent ではなく、/ByteRange によって選択された PDF バイト列である。したがって pverify は PAdES を バイトレンジで選択されたメッセージに対する detached CAdES として扱い、埋め込まれた CMS を detached CAdES に用いられるのと同一のパイプラインへ流す（crates/pverify-core/src/pades/mod.rs、モジュールドキュメントと verify_one_signature）。

pverify は以下の PAdES ベースラインレベルをサポートする。

すべての PAdES SignatureEntry に対して出力されるフォーマット文字列は SignatureFormat::PAdESB である（crates/pverify-core/src/pades/mod.rs。エントリのコンストラクタはすべて format: SignatureFormat::PAdESB を設定する）。レベルの区別（B/T/LT/LTA）は、別個のフォーマット列挙値によってではなく、エントリが保持する 事実 — timestamps[] トークンの存在と検証、vrt ブロック（第12章）、および消費された失効材料の出所 — によって表現される。これは 憲章 §I の事実報告の規律と整合する。pverify は宣伝文句レベルの「これは有効な PAdES-LTA である」と断言するのではなく、観測した事実（検証済みのアーカイブタイムスタンプ、DSS に由来する CRL）を報告する。

6.1.1 複数署名者の拒否

複数の SignerInfo を保持する PAdES SignedData は誠実に拒否される。verify_one_signature はパース直後に parsed.signer_info_count > 1 を検査し、サブインディケーション CmsMultiSignerUnsupported を持つ INDETERMINATE エントリである multi_signer_entry を返す（crates/pverify-core/src/pades/mod.rs、verify_one_signature および multi_signer_entry）。これは CAdES のゲート（verify.rs:496、cms_multi_signer_unsupported）を映したものである。ソース中の修正ノートはその理由を記録している。029 以前のパーサは最初の SignerInfo のみを暗黙に保持していたため、複数署名者の PDF は最初の署名者の判定のみを報告していた — これは事実隠蔽のバグである。拒否することが §I の「断言できないことは断言しない」応答である。

複数の署名辞書を持つ1つの PDF（正当なインクリメンタルアップデートのレイアウト — §6.4 を参照、完全にサポートされ、辞書ごとに1つの SignatureEntry）と、複数の SignerInfo を持つ1つの CMS（拒否される）の区別に留意せよ。PAdES は単一の CMS 内で共署名しない。複数の PDF 署名者は、それぞれ連続するインクリメンタルアップデートで自身の署名辞書を追加する。

6.2 ホスト/コアの分割: PDF パースが行われる場所

憲章 §V（ライブラリファースト）および §VI（WASM クリーンなコア、交渉不可）は、wasm32-unknown-unknown へコンパイル可能でなければならず lopdf/zip/flate2 をリンクしてはならない pverify-core の内部での PDF パースを禁じる。したがって、すべての PDF 構造のパースは、モデルに依存しないバイト構造を生成しそれらを追加的にカーネルへ供給する2つのホスト抽出器で行われる。

• ネイティブ CLI: crates/pverify-cli/src/pdf.rs（lopdf を使用）。
• ブラウザ/WASM ホスト: web/pverify-wasm/src/lib.rs（同じく lopdf を使用、意図的に分離された web/pverify-wasm ワークスペース内）。

これら2つの抽出器は、互いの バイト単位で並行な移植 であることが要求される（CLIとWASMのパリティ不変条件）。カーネルは追加的な VerificationRequest フィールドを通じてパース済み構造を消費する（crates/pverify-core/src/verify.rs）。

• pdf_signature_dicts: Vec<PdfSignatureDescriptor>（verify.rs:86） — 署名/DocTimeStamp 辞書ごとに1つのディスクリプタ。
• pdf_validation_data: PdfValidationData（verify.rs:95） — 文書レベルの /DSS+/VRI 材料（branch 034、§6.5）。

verify_with におけるフォーマットディスパッチは、%PDF- をスニッフィングした入力を crate::pades::verify_pdf へルーティングし、両フィールドを渡す（verify.rs:241–247）。非 PDF 入力では両フィールドとも Default/空である（例: verify.rs:2205）ため、カーネルはスニッフィングしたフォーマットに合致するチャネルのみを参照する。

ホストは暗号処理や失効ロジックを一切行わない。PDF 構造の走査、ストリームのデコード（FlateDecode）、%%EOF のスキャン、および DER の抽出のみを行う。カーネルは、純粋なバイトスライス上で、すべての暗号処理、パス検証、失効評価、およびインディケーションの集約を行う。

6.2.1 PdfSignatureDescriptor 射影

ディスクリプタ（crates/pverify-core/src/pades/mod.rs、PdfSignatureDescriptor）は、単一の署名辞書のホスト→コア射影である。

dict_type と revision_end は 入力 射影フィールドであり、レポートにシリアライズされない。ホスト抽出器は、/Type が /Sig または /DocTimeStamp であり、かつ /ByteRange と /Contents の両方を保持する辞書を受け入れる。それ以外はすべてスキップされる（extract_signatures、pdf.rs の match dict.get(b"Type") のアーム）。署名辞書はオブジェクトグラフのどこにでも存在しうる（最も一般的には AcroForm.Fields[*].V の下）ため、抽出器は AcroForm のみではなくすべてのオブジェクトを走査する（pdf.rs、for (_id, object) in doc.objects.iter() およびモジュールドキュメント）。

/Contents ブロブは末尾にゼロバイトのパディングを伴う固定幅の PDF 16進文字列である（PDF 32000-1 §12.8.1）。CMS SignedData は単一の DER SEQUENCE であるため、ホストは外側 TLV の宣言された長さに切り詰め、BER パーサがパディングを見ないようにする（pdf.rs、trim_to_outer_sequence。WASM 移植版は web/pverify-wasm/src/lib.rs で同一）。切り詰めは 0x30 の構造化 SEQUENCE タグと短形式/長形式の長さを読み取り、header_len + value_len <= bytes.len() を境界チェックし、いかなる不正形式でも生のブロブにフォールバックする。

6.3 ByteRange の完全性と covers-EOF チェック

verify_one_signature（crates/pverify-core/src/pades/mod.rs）は、いかなる暗号処理よりも前に構造的な ByteRange 検証を行う。それぞれ固有の閉じたサブインディケーションを持つ、2つの異なる失敗モードが存在する。

1. 不正形式の ByteRange → PdfByteRangeMalformed を伴う TOTAL_FAILED。このチェック（オーバーフローを避けるためチェック付き算術を使用）は、start1 + len1 <= start2（2つのウィンドウは順序付けられ重複しない）と start2 + len2 <= pdf_bytes.len()（両ウィンドウがファイル内に収まる）を要求する。算術がオーバーフローする、あるいはウィンドウが順序外/範囲外であれば、malformed が真となり暗号処理は試みられない。

2. ByteRange が EOF をカバーしない → PdfByteRangeDoesNotCoverEof を伴う TOTAL_FAILED。これは、署名が（関連する）ファイル全体にコミットしていない署名 — すなわち、署名が保護しない、署名対象領域の後に追加されたコンテンツ — を捕捉する完全性チェックである。

covers-EOF の計算は リビジョンを意識する ものであり、§6.4 の主題である。単一リビジョンの PDF では、古典的な start2 + len2 == pdf_bytes.len() に帰着する。

署名がコミットするバイト列は、2つのウィンドウの連結である。

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

この covered スライスは detached コンテンツとして CMS パイプラインへ供給される（detached CAdES が用いる --detached-content スロットを置き換える）。コンテンツダイジェストは verify_content_digest(&parsed, &covered) によって計算され、署名属性ダイジェストと署名は verify_signed_attrs(&parsed, &signer_cert) によって計算される — いずれも CAdES と共有される（第5章）。

PDF が署名辞書を一切保持しない場合、verify_pdf は単一の INDETERMINATE エントリ（no_signature_entry）を返し、消費側が空配列ではなく確定した事実を見るようにする（verify_pdf、sig_dicts.is_empty() ガード）。

6.4 インクリメンタルアップデートのリビジョンと /DocTimeStamp

PDF は インクリメンタルアップデート をサポートする。後続のリビジョンは、以前のバイトを書き換えることなくバイト（新しいクロスリファレンスセクション、新しいオブジェクト、新しい %%EOF）を追加する。リビジョン1で作成された署名は、正当にリビジョン1の %%EOF のみをカバーする。リビジョン2で追加された文書タイムスタンプや第2の署名は、リビジョン2の %%EOF までのファイルをカバーする。これはまさに日本の官報（e-官報）PDF のレイアウトであり、PAdES-LTA の中心的なパターンである。

branch 009-v07-pades-incremental（v0.7）は、そのような文書が pdf_byte_range_does_not_cover_eof を誤って報告する原因となっていた、結合した2つのバグを修正した（specs/009-v07-pades-incremental/spec.md）。

1. covers-EOF テストは すべての 署名が 最終的な ファイル長をカバーすることを要求していた。リビジョン1の %%EOF のみをカバーするリビジョン1の署名は失敗した。
2. 抽出器は /Type /Sig のみを尊重し /Type /DocTimeStamp を暗黙に破棄していたため、リビジョン2の範囲を定義する文書タイムスタンプが不可視であった。

6.4.1 リビジョン境界の発見

リビジョン境界は、すべての %%EOF マーカーについて生のバイトをスキャンすることでホスト側で発見される（pdf.rs、scan_revision_ends。パリティ移植版は web/pverify-wasm/src/lib.rs）。PDF §7.2 は %%EOF の後に EOL マーカーをちょうど1つ要求するが、一部の生成器は連続する2つの改行（%%EOF\n\n）を出力する。スキャナーは EOL シーケンスを最大1つだけ absorb する。すなわち1つの \r\n、\n、または \r を読み進め、そこで停止する — 2つ目の末尾改行は消費しない。この「最大1 EOL」ルール（PR #126 off-by-1 修正）により、LGPKI2 や類似の生成器による PAdES-LT/LTA 文書が covers_own_revision チェックを通過できる。これらのリビジョン境界は %%EOF 後の最初の EOL で終わり、start2 + len2 の covered-end がちょうどそこに一致するからである。スキャンは PDF 構造理解の一部であるためホストに留まる（憲章 §V/§VI）。コアはディスクリプタごとに結果として得られる revision_end のみを消費する。

各ディスクリプタの revision_end は、その辞書の covered-end start2 + len2 以上にある最小の %%EOF オフセットであり、以上にあるものが存在しない場合はファイル長にフォールバックする（pdf.rs、revision_ends.iter().copied().find(|&e| e >= covered_end).unwrap_or(pdf_len) の代入）。

VerificationRequest は pdf_last_revision_end: u64 フィールドを保持する（デフォルト 0 は pdf_bytes.len() を意味する）。ホストがこの値を設定すると、カーネルは FR-702 の末尾コンテンツチェックに際してこの値で pdf_bytes.len() を上限として用いる。これにより、/DSS を追記するインクリメンタルアップデートを検出した呼び出し元が、その /DSS 追記リビジョンに対する pdf_byte_range_does_not_cover_eof の誤検知を抑制できる。

6.4.2 リビジョンを意識した covers-EOF ルール

カーネルは verify_one_signature（crates/pverify-core/src/pades/mod.rs）でこのルールを適用する。max_revision_end をすべての辞書にわたる最大の revision_end（verify_pdf で一度計算）とする。covered-end start2 + len2 を持つ署名について:

• covers_own_revision = (start2 + len2 == revision_end) — 署名がそれが閉じるリビジョンを正確にカバーする（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)。

言葉で表すと、署名が自身のリビジョンをカバーするとき、かつそのときに限り EOF をカバーする。ただし それが最後の署名されたリビジョンを閉じるにもかかわらず、そのリビジョンの後にカバーされていないバイトが続く場合は除く（FR-702）。第2の節は本質的な完全性である。いかなる署名もコミットしない末尾コンテンツは実際の欠陥（悪意ある追加の可能性）であり、既存の pdf_byte_range_does_not_cover_eof を通じて表出される — 新しいクローズドな列挙タグは追加されなかった（specs/009-.../spec.md の clarification Q2→A）。単一リビジョンの PDF では revision_end == max_revision_end == pdf_len であるため、ルールは古典的な start2 + len2 == pdf_len に縮退し、v0.7 以前のフィクスチャとのバイト単位の同一性を保つ。

6.4.3 DocTimeStamp の処理

/DocTimeStamp 辞書は、自身の ByteRange でカバーされたバイト列に対する RFC 3161 タイムスタンプトークンを保持する — これが PAdES のアーカイブタイムスタンプ機構である。verify_pdf は小さな状態機械でディスクリプタリストを文書順に処理する（crates/pverify-core/src/pades/mod.rs、for desc in sig_dicts ループ）。

• Signature ディスクリプタは verify_one_signature によって検証される → 1つの SignatureEntry。これは「直近の先行する署名」となる。
• DocTimeStamp ディスクリプタは verify_doc_timestamp によって検証される（ByteRange を構造的に再チェックし、カバーされたバイト列を再計算し、crate::timestamp::verify_timestamp_token を ArchiveTimestamp ロールで呼び出す）。結果として得られる TimestampToken は:
  • 先行する署名が存在する場合、そのエントリの timestamps[] に追加され、かつ そのエントリの VRT グラフに対するカバーするアーカイブトークンとして記録される（clarification 2026-06-17 Q1→A: /DocTimeStamp は、それ自身のエントリとしてではなく、先行する署名に対する archive_timestamp ロールを持つ TimestampToken として表出される）。
  • 先行する署名が存在しない場合、それ自身の最小限の doc_timestamp_only_entry となる。
  • TST のパース/検証に失敗した場合でも、破棄されるのではなく（最小限のエントリとして）依然として表出される — その不在自体が事実である。

このグルーピングは、エントリと並行してインデックス付けされた、カバーする TimestampToken（doc_ts_per_entry）と由来する /DocTimeStamp ディスクリプタ（doc_ts_descs_per_entry）の両方を保持する。ディスクリプタは第2パスで必要となる。各アーカイブトークン自身の CMS を再パースし、オブジェクトごとの VRT による失効検証のためにその TSA 証明書を回復するためである（033、§6.5.5）。

6.4.4 オブジェクトごとの VRT 第2パス

すべての /DocTimeStamp がグループ化された後、verify_pdf は署名ごとに第2パス（apply_pades_vrt）を実行する。カバーグラフは signer ← signature-time-stamp ← /DocTimeStamp である（entry.timestamps の先頭にある署名 TS トークン、末尾にあるアーカイブ /DocTimeStamp トークン）。crate::vrt::derive_vrt（第12章）は、再帰的な外側カバーのルールによって各オブジェクトの VRT を計算する。署名者チェーンは署名 TS の GenTime へ繰り上げられ、署名 TS チェーンは /DocTimeStamp の GenTime へ繰り上げられ、最も外側の /DocTimeStamp は request_at にフォールバックする。

署名者チェーンの VRT が request.verification_time と異なる場合 — かつそのときに限り — 署名者チェーンは 繰り上げられた時刻で再検証される（revalidate_pades_signer_chain）。CMS は再パースされ、validate_path + wire_chain_step_signatures + apply_revocations および ETSI/バインディング/コンテンツタイプのレイヤリングが VRT で再実行される。これが PAdES-LTA の目玉である — 署名後に失効した署名証明書も、カバーするアーカイブタイムスタンプが署名時点で有効であったことを証明するため、依然として検証に成功する。チェーンを繰り上げるタイムスタンプが存在しない場合（一般的な PAdES-B/-T のケース）、第2パスは at_request_time プレースホルダの無操作の上書きとなるため、それらのレポートは追加的な vrt ブロックを除いてバイト単位で同一に保たれる。

6.5 文書レベルの検証材料: /DSS、/VRI、revocationInfoArchival（branch 034）

本節は本章の主たる主題である。branch 034-pades-dss-vri（JNSA ガイドラインのギャップレビュー）は、PAdES 文書が 自身について 保持する失効材料を pverify に消費させる。034 以前、PAdES のパスは空の埋め込みスライス（&[], &[]）で失効パイプラインを呼び出していたため、完全に自己証明された オフライン の PAdES-LT/LTA は、必要とするすべての CRL および OCSP レスポンスが自身の /DSS の中に存在するにもかかわらず、INDETERMINATE / revocation_not_checked_offline で停滞していた（docs/pades-dss-vri.md）。034 はその材料をホスト側で読み取り、既存の 失効パイプラインへ通す。

6.5.1 3つの材料ソース

3つすべては 追加的な証拠 である。失効パイプラインは CRL を発行者+シリアルで、OCSP レスポンスを certID で照合するため、材料のスーパーセットは、不確定なものを確定した good/revoked へ 解決する ことしかできない — good な結果を捏造することは決してできない（data-model VR-5）。この性質こそが、リビジョン全体にわたる和集合と DSS グローバルフォールバックの挙動を安全にする。

6.5.2 ホスト側の /DSS+/VRI 抽出

extract_validation_data（crates/pverify-cli/src/pdf.rs。パリティ移植版は web/pverify-wasm/src/lib.rs の extract_pdf_validation_data）は、文書レベルの材料を純粋データの PdfValidationData へパースする。

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

コードに根拠を置く抽出ルール:

• 全リビジョンにわたる和集合（Q6/R-8）。 lopdf は最終的なオブジェクトグラフを解決するが、より早いリビジョンに置き去りにされた古い /DSS を残す生成器に寛容であるため、抽出器はカタログの /DSS および すべてのオブジェクトを走査して見つかったその他すべての /DSS 状の辞書を収集し、それらのプールをすべて和集合する（pdf.rs、doc.catalog() とオブジェクト走査から構築される dss_dicts ベクタ）。和集合は、材料が発行者/シリアル/certID で照合される追加的な証拠であるからこそ安全である。
• 生の DER バイトによる重複排除。 collect_pool は、!out.contains(&der) の場合にのみデコードされたストリームのバイトを追加する — 重複排除はパース済みの同一性ではなく正確な DER による。ストリームは decompressed_content()（FlateDecode などを適用）でデコードされ、デコードエラー時には生のコンテンツにフォールバックする。
• /VRI のインデックス付け。 各 /DSS /VRI サブエントリは、その辞書名をキーとし、大文字化して contents_sha1_hex を形成し、その /Cert//CRL//OCSP プールを VriEntry に収集する。重複するキー（同一署名に対する後続リビジョンの VRI）はスキップされる。VRI エントリは決定論的な順序のためキーでソートされる（pdf.rs、data.vri.sort_by(...)）。
• リソース境界（FR-011/R-9）。 MAX_DSS_ENTRIES_PER_POOL = 4096 と MAX_DSS_STREAM_BYTES = 16 MiB が作業量を上限付ける。空または過大なストリームはスキップされる。不正形式または敵対的な文書は、無制限の作業を行ったりパニックしたりするのではなく「使用可能な材料なし」に縮退する — 部分的に不正形式な DSS でも、クリーンにパースできたエントリは依然として得られる。

PdfValidationData は、すべての非 PDF 入力および /DSS を持たない PDF に対しては空（Default）である。これがバイト単位の同一性の保証（FR-008）である。/DSS を持たない PDF のレポートは、034 以前のレポートと schema_version 文字列のみが異なる（e2e テスト crates/pverify-cli/tests/pades_dss_vri_e2e.rs の no_dss_document_is_strictly_additive によって検証され、pdf_dss/pdf_vri の出所が一切現れないことをアサートする）。

2つの抽出器はバイト単位で並行な移植である（CLIとWASMのパリティ不変条件）。WASM 移植版は同一の MAX_DSS_* 定数と、同一の collect_pool/resolve_dict/scan_revision_ends/trim_to_outer_sequence ロジックを保持する。

6.5.3 オブジェクトごとの解決: VRI 優先、DSS グローバルフォールバック

カーネルは 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

キーがオブジェクトの /Contents SHA-1 と一致する空でない /VRI エントリが優先される（出所 PdfVri）。さもなければ文書レベルの /DSS プールが用いられる（出所 PdfDss）。空の VRI エントリ（材料を一切参照しないもの）は優先されない — 解決はグローバルプールへフォールバックする（VriEntry::is_empty、ユニットテスト dss_vri_empty_vri_entry_falls_back_to_dss により行使される）。解決された証明書 DER はパス構築のためにパースされる。パースに失敗するエントリはスキップされる（resolve_material、filter_map(|der| crate::x509::parse_certificate(der).ok())）。

SHA-1 キーは sha1_uppercase_hex（crates/pverify-core/src/pades/mod.rs）によって計算され、コアの既存の SHA-1 機能（SHA-1 署名検証のため既に存在 — 新たな依存関係なし、FR-012）を再利用する。ソースのコメントは明示的かつ監査上重要である。ここでの SHA-1 は辞書ルックアップのキーとしてのみ用いられ、セキュリティプリミティブとしては決して用いられない。 その暗号学的弱さは無関係である。衝突が起こりうるのは 追加的な 証拠を誤ルーティングすることだけであり、それは good な結果を捏造できないからである（VR-5）。キー導出は、空文字列および "abc" に対する既知の SHA-1 ベクタに対して固定されている（dss_vri_sha1_uppercase_hex_matches_known_vectors）。

ResolvedMaterial は、provenance ∈ {PdfDss, PdfVri} を持つ内部の非ワイヤ構造体 { crls, ocsps, certs, provenance } である。

6.5.4 署名者チェーンでの消費

verify_one_signature において、署名者証明書を選択し中間証明書候補集合を構築した後、解決された材料が適用される（crates/pverify-core/src/pades/mod.rs）。

1. DSS /Certs は中間証明書候補にのみ加わり、アンカーには決して加わらない（Q7/FR-005/VR-2）。 解決された各証明書は、未だ存在しなければ intermediates に追加される（fingerprint_hex で重複排除）。DSS 証明書はパス構築の候補である。構成されたトラストストア（anchors.anchors()）がトラストアンカーの唯一のソースであり続ける。構成済みアンカーのフィンガープリントにたまたま一致する DSS 証明書も、依然として文書からではなく ストアから アンカーされる（出所 trust_anchor）。
2. Adobe revocationInfoArchival は CMS から射影される（project_revocation_info_archival）、その CRL/OCSP DER は署名者側の材料へマージされる。これは PDF 構造ではなく CMS の中に存在するため、出所 pdf_dss ではなく signature_embedded を保持する。
3. マージされた CRL/OCSP DER は既存の apply_revocations 呼び出しへ供給される（crates/pverify-core/src/pades/mod.rs、以前は &[], &[] を受け取っていた apply_revocations(..., &signer_ocsps, &signer_crls, mode) 呼び出し）。
4. 出所タグ付け。 失効処理の実行後、tag_document_revocation_provenance は結果として得られたチェーンステップを走査し、消費された DER が（供給されたバイトの SHA-256 をレコードの body_sha256/response_sha256 に対して）一致する任意の CRL/OCSP レコードについて、pdf_source = PdfDss または PdfVri を設定する。照合は正確かつ決定論的である — 再パースなし。revocationInfoArchival 材料はタグ付けされない（空の source_uri → signature_embedded のデフォルトを保持する）。

revocationInfoArchival の射影（extract_rev_info_archival_from_attrs）は、CMS の署名済み/署名なし属性ブロブにわたるベストエフォートの BER 走査である（両方がスキャンされる。この属性は signedAttrs に「最も一般的」）。OID ボディ 2a 86 48 86 f7 2f 01 01 08 を照合し、値 SET → SEQUENCE → [0] crl SEQUENCE OF CertificateList / [1] ocsp SEQUENCE OF OCSPResponse をパースして、各内側 TLV を再エンコードする。[2] otherRevInfo は 文書化された逸脱 である — 本スライスでは無視される（crates/pverify-core/src/pades/mod.rs、_ => {} のアームとドキュメントコメント）。不正形式の入力はスキップされ、決して致命的ではない（iter_tlv ウォーカはエラーを返すのではなく最初の不正形式な長さで停止する、FR-011）。

6.5.5 TSA チェーンでの消費（各タイムスタンプ、それ自身の VRT で）

第2パス apply_pades_vrt は、各 タイムスタンプの TSA チェーンに対し、そのオブジェクト自身のオブジェクトごとの VRT で失効を適用する（033 + 034）。entry.timestamps 内の各トークンについて:

• TSA チェーン候補証明書は関連する CMS から回復される。先頭の署名 TS トークンについては署名者自身の CMS 証明書、末尾の /DocTimeStamp アーカイブトークンについてはそのトークン自身のディスクリプタの CMS 証明書（doc_ts_descs）。
• オブジェクトの DSS/VRI 材料は、適切な /Contents をキーとして resolve_material 経由で解決される — 埋め込み署名 TS については署名者の /Contents（埋め込み署名 TS 材料の VRI キー）、アーカイブカバーについては /DocTimeStamp 自身の /Contents。
• 解決された証明書は TSA チェーン候補を補足する（これも、決してアンカーではない、Q7）。
• crate::verify::apply_tsa_chain_revocation_for_token（033 の共有ヘルパー、verify.rs:1552）が、解決された OCSP/CRL DER（以前は &[], &[]）とともに、トークンの VRT で呼び出される（crates/pverify-core/src/pades/mod.rs、apply_pades_vrt のトークンごとのループ）。
• 次いで tag_document_revocation_provenance が TSA チェーンの消費されたレコードをタグ付けする。

トークンごとのループの後、apply_tsa_revocation_indication が TSA チェーンの失効判定を最後にレイヤリングする。これが 033 の作業がもたらす一貫性である。失効した TSA 証明書はエントリを revoked_no_poe を伴う INDETERMINATE へ縮退させる（「断言できないことは断言しない」応答 — TSA 自身の証明書が失効していたため、pverify はタイムスタンプの時刻を証明できない）、偽造の主張を捏造するのではなく。

6.5.6 追加的フォールバックチャネルの規律

決定的な不変条件（FR-004a/Q5/VR-4）。DSS/VRI/revocationInfoArchival 材料は、ライブ取得 / CDP ルックアップ自体が不確定であるときに のみ 発火する 019 で導入されたのと同じ埋め込み CRL/OCSP チャネル に乗る。apply_revocations および apply_tsa_chain_revocation_for_token 呼び出しは、その材料を埋め込み OCSP / 埋め込み CRL の引数として受け取り、失効エンジン（第11章）はそれらのチャネルをオーバーライドとしてではなくフォールスルーとして参照する。帰結:

• 現在パスしている オンライン のライブ取得検証は バイト単位で同一 に保たれる — ライブ OCSP/CRL の成功が先に到達し、埋め込み材料は決して参照されない。
• 以前 revocation_not_checked_offline で停滞していた オフライン 検証は、文書自身の証拠から確定的な結果に到達するようになる（e2e テスト dss_borne_crl_reaches_definitive_offline_and_is_tagged_pdf_dss の目玉。これは ネットワークアクセスなし で署名者チェーンが good であることを証明し、消費された CRL を pdf_dss とタグ付けする）。

これは恒常的なオフラインの誠実性の規律（憲章 §VII）である。--offline はソケットを開かず、誠実な IndeterminateRevocationOffline は、文書がそれを確立する証拠を保持するときにのみ確定した結果へ置き換えられる。

6.5.7 新しい判定ロジックはゼロ

DSS/VRI が供給する CRL または OCSP レスポンスは、既存の RevocationOutcome 値を生む — 新しい結果なし、新しいサブインディケーションなし（Q2/FR-007）。具体的には（docs/pades-dss-vri.md）:

• 失効した 署名者 証明書 ⇒ 既存の TOTAL_FAILED（既存の失効集約を経由）。
• 失効した TSA チェーン ⇒ 033 の既存の INDETERMINATE / revoked_no_poe。
• 一致する CRL/OCSP レコードなし ⇒ 結果は不確定のまま（追加的な証拠は決して偽の good を製造しない、VR-5）。

唯一の追加的な ワイヤ 表面は出所であり、次に説明する。

6.5.8 ワイヤ形状の変更とスキーマバージョン

034 のワイヤ表面は純粋に追加的な出所であり、ルートの report-schema.json へ 1:1 で反映される。

• 2つの新しい ValidationObjectOrigin 値、pdf_dss および pdf_vri。既存の5つの 後ろに 追加される（crates/pverify-core/src/report/validation_objects.rs、enum ValidationObjectOrigin）。宣言順序が origin[] 配列のソート順序 そのもの であるため、既存の配列はバイト安定に保たれる。導出はレコードの PdfRevocationSource を出所へマップする（validation_objects.rs、Some(PdfRevocationSource::PdfDss) => ValidationObjectOrigin::PdfDss のアーム）。
• 並行する失効ソース判別子。DSS/VRI が供給する埋め込み CRL/OCSP を CMS unsignedAttrs 埋め込みのものと区別できるようにする。CrlSummary.pdf_source および OcspAttempt.pdf_source、いずれも Option<PdfRevocationSource>（crates/pverify-core/src/report/mod.rs、enum PdfRevocationSource { PdfDss, PdfVri }、および pdf_source フィールド）。いずれも不在時に省略されるため、1.5.0 のリーダはそれらを無視する。

SCHEMA_VERSION はブランチ 034 の着地時に 1.5.0 → 1.7.0 にバンプした（crates/pverify-core/src/report/schema.rs）。後続スライス（035 OCSP nonce、CdpEntry 構造化）によってさらに 1.9.0（現在値）まで進んでいる。本節は 034 固有のワイヤ追加を文書化する。完全な lineage は第14章を参照。バンプは追加的な MINOR 変更である。クローズドな列挙値またはオプションフィールドの追加は MINOR であり、削除または再目的化は MAJOR である（第14章）。スキーマのドキュメントコメントは、新しい失効結果なし、新しい ETSI サブインディケーションなし、新しいトップレベルフィールドなし であること、および 034 が 憲法的な表面ではない（ポリシーテーブルなし。失効語彙を再利用する）ことを明示する。/DSS//VRI/revocationInfoArchival を持たない入力は、schema_version 文字列を除いて 1.5.0 のボディとバイト単位で同一である。

6.5.9 エンドツーエンドのフロー

6.6 RFC 5280 §6.1.5 の空ポリシーツリー緩和

別個の、より早い修正（PR #48、commit 0650b2d）は、実際の日本の公的 PDF が検証できるようになる以前に必要であり、PAdES モジュール内ではなく共有のパス検証ポリシー処理（crates/pverify-core/src/path/policy.rs、compute_outcome）の中に存在する — しかしその動機となるユースケースは PAdES であるため、ここに文書化する。

RFC 5280 §6.1.5 は証明書ポリシー処理のリーフでの締め括りを統べる。#48 以前の実装は、空の valid_policy_tree を 無条件に 拒否しており、これが実際の GPKI/官報チェーンを失敗させていた。そのようなリーフは発行者と異なるポリシー OID を policyMappings なしで保持するため、チェーンが健全であっても valid_policy_tree はリーフで正当に空になる。修正されたロジック（compute_outcome、is_leaf ブロック）は RFC 5280 に正確に従う。

• 空のツリーが拒否となるのは requireExplicitPolicy が発火したとき のみである（explicit_policy_pending == Some(0) としてモデル化）。requireExplicitPolicy が一度も主張されなかった場合、{anyPolicy} のユーザ初期ポリシー集合の下での空のツリーは 有効 である — explicit_policy > 0 または ツリーが非 NULL のとき、パス処理は成功する。
• requireExplicitPolicy が発火したとき、空のツリーは Inconclusive { EmptyTree } を生み、anyPolicy のみを含む（特定のポリシーが生き残らなかった）ツリーは Inconclusive { ExplicitPolicyViolated } を生む。
• 非空の user_initial_policy_set（CLI の --required-policy）はリーフでさらに絞り込む。少なくとも1つのツリーノードが集合内にある特定のポリシーを保持しなければならず、さもなければ Inconclusive { EmptyTree }。

対応する ETSI 表面は、requireExplicitPolicy の空ツリーおよびポリシー集合の積が空となるケースに対する IndeterminatePolicyRejected（crates/pverify-core/src/report/etsi.rs）である。より古い PolicyProcessingInconclusive タグは保存済みレポートのデシリアライズのために保持される。PAdES のパスは同じ required_policies を validate_path へ通す（branch 029、verify_one_signature および revalidate_pades_signer_chain）ため、PAdES は CAdES と同一のユーザ初期ポリシー集合の絞り込みを強制する — 空のスライスは依然として {anyPolicy} を意味し、--required-policy なしの実行との互換性を保つ。

6.7 不変条件と失敗モード（要約）

全体を通じて、PAdES 検証器はシステムの横断的な規律を尊重する。PDF パースはホスト側に留まる（憲章 §V/§VI）。カーネルは I/O を行わず WASM クリーンである。追加的な材料は、ライブの成功を決してオーバーライドしないフォールスルーとしてのみ流れる（再現性 / バイト単位の同一性）。そして事実が確立できないところでは、検証器は判定を捏造するのではなく、正確なクローズドな列挙のサブインディケーションを伴う INDETERMINATE へ縮退する（憲章 §I、「断言できないことは断言しない」）。

6.8 相互参照

• 第4章 — 入力分類、フォーマットディスパッチ（detect_format）、エンドツーエンドのデータフロー。
• 第5章 — CAdES。その CMS/チェーン/署名属性/コンテンツダイジェスト/ESS バインディング/コンテンツタイプの機構を PAdES が再利用する。
• 第11章 — 失効（CRL/OCSP、埋め込みチャネルのフォールスルー）。解決された DSS/VRI 材料がこれに供給される。
• 第12章 — オブジェクトごとの VRT 導出（再帰的な外側カバー）。apply_pades_vrt が使用する。
• 第14章 — レポートスキーマ、schema_version のセマンティクス、ValidationObjectOrigin、derive_validation_objects の出所導出。

7. XAdES および ASiC の検証

本章では、pverify が XML 高度電子署名（XAdES、ETSI EN 319 132 / JIS X 14533‑2） および関連署名コンテナ（ASiC、ETSI EN 319 162）をどのように検証するかを述べる。 両者はいずれも委譲型の形式である。ホストクレートである pverify-xades と pverify-asic がすべての XML/ZIP のパースと 正規化（C14N）を実施し、I/O を行わない no_std カーネル（pverify-core）へ モデルに依存しないバイト構造を引き渡す。カーネルはその後、CAdES（第5章を参照） および PAdES（第6章を参照）に用いるものと同一の RFC 5280 パス検証、 RFC 6960/5280 失効検証、RFC 3161/5816 タイムスタンプ、 ETSI EN 319 102‑1 インディケーション機構を通してそれらを処理する。 アーキテクチャ上の境界とクレートのトポロジは第3章に記述されている。 本章は XML 署名と ZIP コンテナに形式固有なものに焦点を当て、 どのプロファイルが検証されるか、あるいは未対応として明示されるかを正確に示す。

対応する AdES レベルは埋もれてしまわないよう冒頭で明示する。

全体を通じて譲れない唯一の原則は、憲法 §I の 「断定回避」（断言できないことは断言しない）の規律である。pverify が事実を 確立できない場合（未対応の正規化、パース不能なタイムスタンプトークン、 コンテナに存在しないデータオブジェクトなど）には、正確なクローズドな列挙 （閉じた語彙）のサブインディケーションを伴って INDETERMINATE へ降格し、 捏造された TOTAL_FAILED や TOTAL_PASSED を返すことは決してしない。

7.1 XAdES の統合境界

カーネルは XML をパースできない。それを行えば DOM と正規化機構を no_std/WASM クリーンなコアに引き込むことになり、憲法 §V（ライブラリファースト） および §VI（WASM クリーンなコア）に違反する。代わりに、ホストクレート pverify-xades（crates/pverify-xades/src/lib.rs）が XML をパースし、 監査済みの bergshamra-c14n クレートを通して Exclusive XML 正規化を実施し、 ds:Signature 要素ごとに1つの、モデルに依存しない XadesComponents 値を 出力する。この境界型はカーネルが所有しており（crates/pverify-core/src/xades.rs、 XadesComponents）、ホストクレートから再エクスポートされるため、 VerificationRequest へ渡る形状について単一の真実の源が存在する。境界を越えるのは Vec<u8> と小さなクローズドな列挙のみであり、XML ノードも std 型も渡らない。 カーネルの検証器 verify_xades（crates/pverify-core/src/xades.rs）は1つの XadesComponents を消費して1つの SignatureEntry を生成し、署名者証明書が 手に入った時点から既存の RFC 5280 / 失効 / ETSI パイプラインを再利用する。 これは verify_cades（crates/pverify-core/src/verify.rs）と意図的に同一である。

境界フィールドは、いずれもホストが既にデコードと正規化を済ませており、 カーネルが XML に触れることは決してない。各フィールドは以下のとおりである。

B‑T/B‑LT のフィールドはすべて追加的であり、ブランチ 019 により導入された。 素朴な B‑B 署名は UnsignedSignatureProperties を持たないためそれらは空のまま 残り、すなわち B‑B レポートは 019 以前の出力とバイト単位で同一になる （再現性の不変条件、憲法 §II）。同じバイト同一性の規律はカーネルの挙動も統制する。 追加的な埋め込み失効情報のチャネルは、ライブ/CDP チャネルが判定不能なときにのみ 発火する。

7.2 正規化（C14N）

XML 正規化は XML 署名検証の中で要となる部分であり、また歴史的に最も 誤りを生みやすい部分でもある。ダイジェスト計算され署名される対象のバイト列は、 ディスク上のリテラルなバイト列ではなく、ノード集合の正規シリアライズだからである。 pverify は2つの異なる正規化アルゴリズムを用い、それぞれ特定の箇所に適用する。 いずれも監査済みの bergshamra-c14n クレートが提供する （crates/pverify-xades/src/c14n.rs）。

1. Exclusive XML 正規化（xml-exc-c14n#、W3C）。ds:SignedInfo （検証されるメッセージ）と各々の同一文書内 ds:Reference サブツリーに適用する。 Exclusive C14N は、可視的に使用されていない継承された名前空間宣言を刈り取り、 InclusiveNamespaces PrefixList が存在する場合はそれを尊重する。ホストは その接頭辞リストを CanonicalizationMethod/Transform 要素から読み取り （inclusive_prefixes、crates/pverify-xades/src/parse.rs）、 exc_c14n_subtree へ引き渡す。

2. 素の Canonical XML 1.0（REC-xml-c14n-20010315、コメントありおよびなし）。 RFC 3161 タイムスタンプのメッセージインプリント計算（§7.5）にのみ適用する。 Exclusive C14N とは異なり、素の C14N はスコープ内のすべての名前空間を出力し、 継承された宣言は刈り取られない。したがって inclusive‑prefix リストを取らない。 これは bergshamra-c14n の既存の C14nMode::Inclusive 上で実装されている （B‑B ビルドが既にこれをコンパイルするため、B‑T では新たな依存は追加されなかった — crates/pverify-xades/src/c14n.rs::plain_c14n_subtree）。

「タイムスタンプインプリントには素の C14N、ds:SignedInfo には Exclusive C14N」 という使い分けは恣意的な選択ではない。これは実際の EU DSS XAdES コーパスに対して バイト単位で正確であることが確認された（019 のリサーチノートは、ds:SignedInfo 自体が Exclusive C14N を使う場合であっても、SignatureTimeStamp がインプリント する対象のデータに対しては素の C14N 1.0 を宣言することを記録している）。 両方の正規化面は libxml2 のゴールデンオラクルに対してバイト単位で回帰固定されており （crates/pverify-xades/tests/exc_c14n_golden.rs および tests/plain_c14n_golden.rs）、正規化器のいかなるドリフトも、現場での検証 不一致として発見されるのではなく、決定論的に捕捉される。

enveloped 署名変換（W3C XML‑DSIG §6.6.4）は、正規化に隣接する3つ目の操作である。 URI="" と #enveloped-signature 変換を伴う参照は、文書全体から ds:Signature サブツリーを差し引いたものをダイジェストする。ホストは、 全文書のノード集合を取り、署名サブツリーを差し引き、その後 Exclusive C14N を 適用することでこれを計算する（exc_c14n_enveloped、 crates/pverify-xades/src/c14n.rs）。まさにこの URI="" + enveloped 変換 参照の存在が、署名を対応済みの enveloped プロファイルとして分類する根拠となる （§7.4）。

7.3 XAdES B‑B 検証

verify_xades（crates/pverify-core/src/xades.rs）は、固定された事実順序の 手順を実行する。各失敗は特定の結果へマップされる。この順序は意図的なものであり、 確定的な偽造が、より弱い判定不能の条件より先に検出され、それによって決して 隠蔽されないようにしてある。

ステップ 1 — プロファイルとアルゴリズムのゲーティング。 ホストが profile を Unsupported と分類した場合、カーネルは直ちに INDETERMINATE を返す。 サブインディケーションは xades_unsupported_profile（detached/enveloping の パッケージング）または xades_unsupported_canonicalization（非 Exclusive C14N） のいずれかである。Unsupported な SignatureMethod URI は INDETERMINATE signature_algorithm_unsupported を返す。これらは断定回避の結果である。 pverify は形状を認識するが、実装していないものの検証を、推測するのではなく辞退する。

ステップ 2 — 署名者証明書の存在。 signer_cert_der == None → INDETERMINATE xades_signer_certificate_unavailable。同じ結果は、DER パースに 失敗した証明書や、SubjectPublicKeyInfo を再エンコードできない証明書 （extract_spki_der）も対象とする。

ステップ 3 — 参照ダイジェスト。 すべての ds:Reference について、カーネルは digest_alg(transformed_c14n) を再計算し、格納された expected_digest と 比較する。いかなる不一致も TOTAL_FAILED xades_reference_digest_mismatch であり、署名された内容が改変されたという積極的証拠である。これは署名値より前に 検査される。なぜなら参照の不一致は、署名値の暗号処理とは独立した内容完全性の 失敗だからである。

ステップ 4 — SignedInfo に対する署名値。 カーネルは、署名者証明書の SubjectPublicKeyInfo を用いて、signed_info_c14n に対する signature_value を 検証する。RSA‑PSS はホストが解決したソルト長を伴って直接ディスパッチされる （verify_rsa_pss）。RSA PKCS#1 v1.5 と ECDSA は共有の OID 駆動の verify_with_alg に到達する（ホストは既に ECDSA の r‖s を DER に変換済みのため、 既存の検証器は変更されない）。真正な検証失敗は TOTAL_FAILED signed_attrs_signature_failed（CMS のクラスを再利用 — XML 署名値は CMS 署名者 署名の対応物である）。この時点で表出した未対応のアルゴリズムは INDETERMINATE signature_algorithm_unsupported へ降格し、「誤り」と 「評価できない」の間の事実報告上の区別を保持する。

ステップ 5 — SigningCertificateV2 バインディング。 署名が XAdES の SigningCertificateV2 を持つ場合、カーネルは宣言された DigestMethod の下で 署名者証明書 DER のダイジェストを再計算し、格納された CertDigest と比較する。 不一致は TOTAL_FAILED xades_signing_certificate_mismatch であり、証明書 すり替えに対する防御である（攻撃者が埋め込み証明書を、その鍵もまた再署名された SignedInfo を検証できる別の証明書にすり替える攻撃はここで捕捉される）。 このバインディングはダイジェストに基づく。IssuerSerialV2 は記録されるが 判別子としては用いられない。

ステップ 6 — パス検証、失効、ETSI。 ここから先のフローは verify_cades と 同一である。validate_path（検証時刻における RFC 5280 §6 のパス構築）、 wire_chain_step_signatures（RustCrypto による証明書署名検証）、署名者チェーンに 対する apply_revocations、そして aggregate_etsi による ETSI 集約である。 埋め込まれた B‑LT 証明書はチェーン材料として利用可能とされ、埋め込まれた OCSP/CRL DER は既存の埋め込み材料チャネルを通して供給されるため、 オフラインで確定する署名者失効の判定に到達できる。

成功時、レポートは XAdES 署名がコミットするバイト列を記録する。signed_content 検証対象オブジェクトのダイジェストは、Exclusive‑C14N の ds:SignedInfo の SHA‑256 に設定される（covered_content_sha256）。CMS 形状の signed_attrs と content_digest ブロックは該当なしの事実として記録される（XAdES には CMS の messageDigest が存在しない）ため、レポートを読む消費者は、捏造された一致では なく誠実な「該当なし」を目にする。

弱いアルゴリズムの取り扱い。 SignatureMethod または任意の参照の DigestMethod における SHA‑1 は認識して旗を立てるのであり、決して拒否しない — これは CAdES/PAdES の姿勢および憲法 §I と整合する。カーネルは署名を通常どおり 検証し、署名者ステップに対して WeakAlgorithmFlag を記録し（flag_if_weak 経由）、ホストの aggregate_for_header がそれをレポートヘッダに表出する。これは オプトインのアルゴリズムポリシー判定（§7.6）とは区別される。後者は別個の、 時刻でスコープ付けされた評価である。

7.3.1 アルゴリズムのマッピング

ホストは XML アルゴリズム URI を crates/pverify-xades/src/algid.rs で モデルに依存しない記述子へ解決する。対応する SignatureMethod のファミリは 以下のとおりである。

DigestMethod URI は SHA‑1/256/384/512 へマップされる。認識されないダイジェスト URI は未対応である。SHA‑1 は妥当な認識済みのダイジェストであり（検証された後に 弱いとして旗を立てる）、未対応値ではない — ここでも事実報告の原則が働く。

7.4 プロファイル分類（enveloped 対 detached）

スタンドアロンの XAdES 対応は、Exclusive 正規化を伴う enveloped プロファイルに意図的にスコープを絞っている。これは e‑Gov の公文書 XML 署名 （官職署名）、法務省の電子定款、および EU の LOTL/トラステッドリストで用いられる 形状である。ホストは process_reference / extract_one （crates/pverify-xades/src/parse.rs）でプロファイルを次の優先順位で決定する。

1. CanonicalizationMethod が Exclusive C14N でない場合 → Unsupported{NonExclusiveC14n}。
2. それ以外で、resolver が供給され（ASiC のケース、§7.7）、非フラグメントの ds:Reference URI が ZIP エントリへ解決された場合 → DetachedResolved。
3. それ以外で、URI="" + enveloped 署名参照が存在しない場合 → Unsupported{DetachedOrEnveloping}。
4. それ以外 → EnvelopedBB。

DetachedResolved への引き上げは狭い。それは、ASiC 抽出器が既に参照 URI を 具体的なバイト列へ解決済みである場合にのみ、detached のゲートを引き上げる。 スタンドアロンの detached/enveloping XAdES は依然として Unsupported へ マップされるため、ASiC コードが存在するか否かにかかわらず enveloped パス （011/019）はバイト単位で同一である。これが、pverify が別個の detached 検証器を 導入することなく ASiC‑E XAdES のために XAdES の参照ダイジェスト機構を再利用する 方法である（§7.7）。

7.5 XAdES B‑T および B‑LT タイムスタンプ

ブランチ 019 が B‑T および B‑LT 対応を追加した。スコープ内の B‑T タイムスタンプは SignatureTimeStamp と SigAndRefsTimeStamp である。両者は RFC 3161 トークンであり、 共有の crate::timestamp::verify_timestamp_token を通して検証される。ホストは インプリント対象のデータを正規化し（カーネルは生のインプリントバイト列のみを 受け取る、§V）、カーネルは CAdES がその署名タイムスタンプに対して行うのと まったく同様にインプリントを計算して比較する。

SignatureTimeStamp。 インプリントは素の C14Nで正規化された ds:SignatureValue にコミットする（R‑1、DSS コーパスに対してバイト確認済み）。 ホストは ds:SignatureValue を素の C14N 1.0 で正規化し、それを imprint_input として格納する。カーネルは RFC 3161 トークンとインプリントを検証する。

SigAndRefsTimeStamp。 これは本スライスで最も難しい計算である。 ETSI TS 101 903 §7.5.1 の type‑1 カバレッジに従い、インプリントは順序付き連結に 対して計算される。各サブツリーは素の C14N で正規化され、ds:SignatureValue に 続いてすべての SignatureTimeStamp、CompleteCertificateRefs、 CompleteRevocationRefs、および（存在する場合）AttributeCertificateRefs / AttributeRevocationRefs を、UnsignedSignatureProperties の下でタイムスタンプ 自体まで（自体は含まない）文書順に辿る（build_sig_and_refs_imprint、 crates/pverify-xades/src/parse.rs）。この再構築は本形式において最も高リスクな バイト単位の正確さを要する操作である。設計は明示的に誠実な判定不能である。 再構築された連結がインプリントを再現しない場合、カーネルは message_imprint_match = false を記録してそれを表出し、一致を捏造することは しない。選定された DSS フィクスチャに対しては type‑1 インプリントが実際に再構築 され、降格ではなく真正な TOTAL_PASSED を生む。

インプリント不一致の判定。 スコープ内のタイムスタンプのインプリントが一致 しない（または検証できなかった — 例えばタイムスタンプが未対応の正規化を宣言した、 canonicalization_supported = false）場合で、かつ署名の残りがそれ以外は妥当である （基底の集約が TOTAL_PASSED を返した）場合、カーネルは INDETERMINATE xades_timestamp_imprint_mismatch へ降格する。署名は偽造されていないが、その 主張された時刻を確証できない（ETSI EN 319 102‑1）。真正な TOTAL_FAILED の 署名者/参照失敗は優先を保つ。降格は通過した判定にのみ作用し、証明された失敗を 隠蔽することは決してない。

B‑LT 埋め込み材料。 CertificateValues/EncapsulatedX509Certificate は チェーン材料となる。RevocationValues/CRLValues/EncapsulatedCRLValue と OCSPValues/EncapsulatedOCSPValue は既存の埋め込み CRL/OCSP チャネルへ供給される。 形式固有の微妙な点が1つある。XAdES の EncapsulatedOCSPValue は完全な RFC 6960 の OCSPResponse（responseStatus + responseBytes ラッパ）を運ぶのに対し、 カーネルは（CAdES の revocation-values.ocspVals と同様に）裸の BasicOCSPResponse を消費する。したがってホストは、それを引き渡す前に最小限の 手書き DER 走査（unwrap_ocsp_response、crates/pverify-xades/src/parse.rs）で OCSPResponse を内側の BasicOCSPResponse へアンラップする。構造が一致しない ものはそのまま返されるため、カーネルはそれを事実として評価または拒否し、決して パニックしない。いずれかの B‑LT ペイロードの存在は、報告される format を XAdES-B-LT へ昇格させる。LT ペイロードのない検証済み署名タイムスタンプは XAdES-B-T であり、いずれでもなければ XAdES-B-B である。

オブジェクトごとの VRT。 あらゆる形式と同様、各オブジェクト（署名者チェーン、 署名者署名、各署名タイムスタンプ）は、再帰的な外側カバーのエンジン （crate::vrt::derive_vrt、第12章を参照）によって導出される、それ自身の 検証基準時刻（VRT）で判定される。署名タイムスタンプの GenTime が署名者チェーンの VRT を request 時刻より後へ繰り上げる場合、カーネルはその繰り上げられた時刻で チェーンを再検証する（crates/pverify-core/src/xades.rs）。これにより、署名後に 失効はせず期限切れになったが、有効な間にタイムスタンプされた署名者証明書も 依然として検証される — これが B‑LT の主たる成果である。TSA チェーンの失効検証は、 共有の apply_tsa_chain_revocation_for_token ヘルパ（ブランチ 033）を通して、 各タイムスタンプそれ自身の VRT においてタイムスタンプごとに適用され、TSA 失効 整合性に関して XAdES を CAdES/PAdES と同等の水準にする。

7.5.1 XAdES B‑LTA：ArchiveTimeStamp インプリント検証（ブランチ 036）

ブランチ 036-xades-blta は XAdES B‑LTA の ArchiveTimeStamp インプリント再計算を実装し、 この層に関する §I のギャップをクローズする（ETSI TS 101 903 v1.4.2 Annex A.1.5）。

SignatureFormat::XadesBLta（"XAdES-B-LTA"）は、UnsignedSignatureProperties に少なくとも1つの ArchiveTimeStamp が存在するときに昇格する。B‑T/B‑LT の各レベルと同様、 昇格は認識された構造的事実であり、主張されたプロファイルではない。

インプリント構築。 インプリント入力は、ds:Signature 要素全体を対象とした Exclusive‑C14N（bergshamra-c14n）シリアライズから、後続の ArchiveTimeStamp 要素 （現在のトークンをインデックス k-1 とするとき、インデックス k 以降のもの）の ノード集合を差し引いたものである。これが「非循環 imprint」の規律である。各 ATS は それより前のすべての ATS と署名本体にコミットし、前向きのハッシュチェーンを形成する。 一方、再計算対象のトークン自身は除外されるため、そのインプリントを独立に検証できる。 事前計算済みバイト列はホスト（pverify-xades）によって XadesUnverifiedTimestamp.imprint_input: Vec<u8> として格納される。 カーネル（verify_xades）は XML に触れることなく、これらのバイトで verify_timestamp_token を呼び出すだけである。

共有 LTA インフラ。 LongTermArchivalIndication と ArchiveTimestampImprintRecord は CAdES B‑LTA パス（第5章）と共有され、新しい型は不要である。検証済みの XAdES アーカイブタイムスタンプは embedded_validation_data.long_term_archival_indication に反映される （以前は LT ペイロードが存在する場合でも XAdES では no_archive_timestamp であったが、 インプリントが検証された際に実際の LongTermArchivalIndication が設定されるようになった）。

スコープと制限。 現在の実装がカバーするもの：

• 単一チェーンの ArchiveTimeStamp、またはノード集合が明確に定義される短い順序付き連鎖。
• ETSI TS 101 903 形式の ArchiveTimeStamp（ArchiveTimeStampV3 は非対応）。

スコープ外：

• 複数の ArchiveTimeStamp チェーン（長い ATS チェーンのループ処理は将来のスライス）。
• XPath トランスフォームを宣言している ArchiveTimeStamp トークン：ホストに XPath 評価器が ないため再計算不可。これらは空の imprint_input を持つ unverified_timestamps に表出され、 判定を降格しない（断定回避）。DSS XAdES‑LTA 相互運用フィクスチャが XPath トランスフォームを 使用するため、これらは expectations.json から除外されている。
• JAdES arcTst（別フォーマット、本スライスのスコープ外）。

RefsOnlyTimeStamp は従来どおり「存在するが未検証」として表出される（インプリント再計算なし）。

7.6 XAdES のアルゴリズムポリシー評価

オプトインのアルゴリズムポリシーが有効な場合（--algorithm-policy、既定では無効）、 evaluate_xades_algorithm_validity（crates/pverify-core/src/xades.rs）は オブジェクトごとのインベントリを組み立て、各オブジェクトのダイジェスト / 署名 ファミリ / 鍵長を、そのオブジェクトの VRT 時点でポリシーに照らして評価する （031 の vrt ブロックから逐語的に読み取り、決して再計算しない）。署名者署名の ファミリとダイジェストは SignatureMethod 記述子から、鍵長は署名者 SPKI から 得られる。署名者チェーンオブジェクトはリーフ証明書それ自身の signatureAlgorithm を用いる。各署名タイムスタンプはそのインプリントダイジェスト で判定される。結果は apply_algorithm_validity_indication を通してインディ ケーションに重ねられる。これは ETSI の CRYPTO_CONSTRAINTS_FAILURE_NO_POE の 姿勢を反映し、TOTAL_FAILED を決して生成せず、また決してそれを隠蔽しない。 ポリシーが無効のとき、このフィールドは None であり、レポートはポリシーなしの 実行とバイト単位で同一である（憲法 §II）。アルゴリズムポリシーのエンジン自体に ついては第13章を参照。

7.7 ASiC コンテナ構造

ASiC（ETSI EN 319 162）は、1つ以上のデータオブジェクトを1つ以上の detached な AdES 署名へ束ね、加えてコンテナのプロファイルを識別する mimetype エントリを持つ ZIP アーカイブである。pverify は ASiC‑S（単一データ オブジェクト）と ASiC‑E（複数データオブジェクト、マニフェストで記述）に対応し、 各内部署名を既存の detached CAdES または detached XAdES パイプラインへ委譲する ことで検証する。唯一の真に新しい暗号上の判断は、ASiC‑E CAdES のマニフェスト ダイジェストチェーンである（§7.9）。

XAdES と同様、カーネルは ZIP/DEFLATE をパースできない。それを行えば zip + flate2 + miniz_oxide をコアグラフへ引き込むことになる（scripts/cargo-tree-gate.sh によりゲートで禁止されている）。ホストクレート pverify-asic （crates/pverify-asic/src/lib.rs）はコンテナをメモリ上で読み取り、 META-INF/ の署名材料とデータオブジェクトを発見し、ASiCManifest をパースし、 detached XAdES のために ZIP 相対の ds:Reference URI を解決し、署名ごとに1つの、 モデルに依存しない AsicSignature を出力する（境界型は crates/pverify-core/src/asic.rs が所有する）。ホストはこれらを VerificationRequest.asic_signatures へ引き渡す。カーネルの検証器 verify_asic_signature（crates/pverify-core/src/asic.rs）は、各々をその AsicPayload のバリアントが選択する再利用パスを通してマップする。

ディスパッチの優先順位。 ZIP コンテナはローカルファイルヘッダのマジック PK\x03\x04 で始まる。これはバイトのスニフがそのままでは CAdES へルーティングして しまうものである。そこで verify_with（crates/pverify-core/src/verify.rs）は 形式スニフより前に request.asic_signatures を検査する。ホストがいずれかの ASiC 署名を抽出した場合、それらが優先され、各々が独立に検証される（署名ごとに 1つの signatures[] エントリとなるため、1つの失敗が他を抑制することは決してない）。 ホストがいかなる ASiC 署名も生成しなかった ZIP マジック入力 — 認識可能な ASiC コンテナではない ZIP — は INDETERMINATE asic_unsupported_container （asic_unsupported_entry）として報告され、CAdES のスニフへ落ちて誤分類される ことは決して許されない。

ZIP リーダ（crates/pverify-asic/src/zip.rs）は純粋 Rust の zip クレートを ラップし、ASiC が必要とするセキュリティの封じ込めを加える。すなわち、4096 エントリの上限、256 MiB の総展開予算、エントリごとの 128 MiB の上限（zip 爆弾の 拒否。黙って切り詰めるのではなく明示的な ResourceBoundExceeded を返す）、および パストラバーサルの拒否（enclosed_name() == None、加えて .. 構成要素と絶対パスに 対する多層防御の検査）である。すべてはメモリ上に読み込まれ、一時ファイルは 用いない。

7.8 ASiC プロファイル検出と適合性からの逸脱

detect（crates/pverify-asic/src/detect.rs）はプロファイルをベストエフォートで 決定し、いかなるパッケージングの逸脱も黙って許容するのではなく記録する — これは §I の誠実性の原則をコンテナ適合性に適用したものであり、実際の DSS 出力が出すものと 整合させてある。適合する mimetype はプロファイルを権威的に確定する。

ETSI EN 319 162 は mimetype が ZIP の最初のエントリであり、かつ STORED （非圧縮）であることを要求する。pverify は両方を検査し、mimetype_not_first_entry と mimetype_compressed を逸脱として表出する（AsicDeviation、 crates/pverify-core/src/report/mod.rs）が、依然としてコンテナを検証する。 逸脱の集合はコンテナから生じるすべての SignatureEntry に付与される （asic_conformance_deviations）ため、監査者は、判定が抑制されることなく、コンテナが どの ETSI パッケージング規則に違反したかを正確に把握できる。

mimetype が欠落しているか非適合の場合、infer_profile は META-INF/ の レイアウトからプロファイルを導出する。いずれかの ASiCManifest*.xml ⇒ ASiC‑E。 単一の META-INF/signature.p7s（数値接尾辞なし）⇒ ASiC‑S、数値接尾辞または2つ以上の 署名 ⇒ ASiC‑E。signatures.xml 対 signaturesNNN.xml についても同様である。 認識には何らかの署名材料が必要である — 認識可能な META-INF/signature*.{p7s,xml} も適合する mimetype も持たない ZIP は ASiC では ない（detect は None を返す）。また適合する mimetype のみでは不十分である （検証すべき何かが存在しなければならない）。署名ファイル名の照合は標準に従い 大文字小文字を区別する（is_cades_signature、is_xades_signature、 is_asic_manifest）。ASiCArchiveManifest（LTA、スコープ外）と OpenDocument の 情報用 manifest.xml は意図的にマニフェスト認識から除外される。

コンテナは両方のファミリ（混在した signature*.p7s と signatures*.xml）を 運びうる。extract は存在する両方のファミリを処理するため、いかなる署名も 黙って捨てられることはない（crates/pverify-asic/src/lib.rs）。Detection.family フィールドは診断用に過ぎず、ディスパッチには用いられない。

7.9 ASiC ペイロードの検証

各 AsicSignature は、再利用パスを選択する AsicPayload を運ぶ （crates/pverify-core/src/asic.rs::verify_asic_signature）。

CadesDirect（ASiC‑S CAdES）。 detached CAdES の messageDigest は単一の データオブジェクトの生バイト列を直接カバーする（マニフェストなし）。カーネルは verify_cades_detached を data_object.bytes を detached コンテンツとして呼び出す — CAdES パス全体（チェーン構築、コンテンツダイジェスト、失効、タイムスタンプ、 ETSI）が逐語的に再利用される。単一のデータオブジェクトは、mimetype でもなく META-INF/ の下でもない唯一のエントリである（sole_data_object）。

CadesManifest（ASiC‑E CAdES） — 二段のダイジェストチェーン。 これは ASiC スライスにおける唯一の新しい検証ロジックである（R‑1）。

1. ステップ 1 — CAdES は ASiCManifest の XML バイト列を逐語的に署名する。 カーネルは verify_cades_detached を manifest_bytes を detached コンテンツと して呼び出す。
2. ステップ 2 — 各 <asic:DataObjectReference> は DigestMethod と DigestValue を宣言する。ホストは各参照 URI を実際の ZIP エントリのバイト列へ 解決する（resolve_entry。先頭の ./ と DSS が出すパーセントエスケープを許容する）。 カーネルは digest_alg(actual_bytes) を再計算し、マニフェストが宣言した ダイジェストと比較する（apply_manifest_digest_chain、 crates/pverify-core/src/asic.rs）。この再計算はカーネル内に存在するため、 完全性の判断は再現可能なレポートの一部となる。

各再計算は asic_manifest_checks に記録される（§III の監査証跡。URI、宣言された ダイジェスト OID、一致のブール値）。判定ロジックはその後、次を強制する。

ダイジェストの不一致（改竄の積極的証拠）は、欠落したオブジェクト（これは内容を 評価できないことを意味するに過ぎない）に優先する。不一致は TOTAL_FAILED、 単なる不在は INDETERMINATE であり — これは改変の証明と検査不能との間の断定回避の 区別である。重要なことに、データオブジェクトのダイジェスト不一致は、マニフェストに 対する CAdES 署名が完璧に検証された場合でも失敗として報告される。なぜなら、 マニフェストは署名を、実際のバイト列がもはや一致しない内容へ束ねており — 完全性の チェーンはステップ 2 で断ち切られているからである。

Xades（ASiC‑S/E XAdES）。 ホスト（extract_xades、 crates/pverify-asic/src/lib.rs）は各 META-INF/signatures*.xml を pverify_xades::extract_detached を通してパースし、各 ZIP 相対の ds:Reference URI を名前付きエントリのバイト列へマップするリゾルバを供給する。結果として得られる XadesComponents は DetachedResolved プロファイル（§7.4）を運び、カーネルは verify_xades を変更せず呼び出す。参照ダイジェストの検査（§7.3 のステップ 3）は その後、解決された各データオブジェクトのバイト列を、格納された DigestValue に 照らして検証する。解決不能な URI は参照バイト列を空のままにするため、その検査は 誠実に失敗し、黙って通過することは決してない。これが、ASiC‑E XAdES — 既定の DSS ASiC‑E 出力 — を、enveloped XAdES とまったく同一の参照ダイジェスト機構を再利用して、 detached ゲートを狭く引き上げるだけで検証する方法である。

すべてのエントリは、どのペイロードパスがそれを生成したかにかかわらず、その container フィールドが設定され（ASiC-S / ASiC-E）、適合性の逸脱が付与される。

7.10 結果の語彙と不変条件

XAdES/ASiC のパスは新しいトップレベルの Indication を追加しない。それらは TOTAL_PASSED / INDETERMINATE / TOTAL_FAILED を再利用し、次のクローズドな SubIndication 値を提供する（crates/pverify-core/src/report/etsi.rs。ルートの report-schema.json へ 1:1 で反映されている）。

レビュアーが実装に課すべき形式固有の不変条件は次のとおりである。

• カーネルに XML/ZIP を持ち込まない。 pverify-xades と pverify-asic は WASM クリーンな抽出クレートであり、暗号処理を一切運ばない（パース、正規化、 バイト抽出のみ）。それらは pverify-core の実行時グラフから外れていることが ゲートにより保証される。カーネルは Vec<u8> とクローズドな列挙のみを見る。
• CLIとWASMのパリティ。 ブラウザのホスト（web/pverify-wasm/src/lib.rs）は バイト単位で同一な pverify_xades::extract / pverify_asic::extract と、同一の verify_with カーネルを実行し、同一の入力に対してバイト単位で同一のレポートを 生成する。
• 機能不在時のバイト同一性。 B‑B の XAdES 署名（UnsignedSignatureProperties なし）とアルゴリズムポリシー無効の実行は、schema_version 文字列を除いて スライス以前の出力とレポートをバイト単位で同一に保つ。埋め込み失効情報の チャネルは、ライブ/CDP チャネルが判定不能なときにのみ発火する。
• 断定回避。 未対応の正規化、パース不能または未対応 C14N のタイムスタンプ、 スコープ外のアーカイブタイムスタンプ、欠落した ASiC データオブジェクトは、 いずれも正確なサブインディケーションを伴って INDETERMINATE へ降格する — 捏造された通過や失敗を返すことは決してない。
• 隠蔽しない。 ダイジェストの不一致（XAdES の参照または ASiC のデータ オブジェクト）と署名証明書の不一致は TOTAL_FAILED であり、より弱い タイムスタンプや失効のインディケーションによって上書きされることは決してない。 タイムスタンプインプリントによる降格とマニフェストダイジェストの強制は、明示的に 失敗していない基底にのみ作用する。

レポート形状のバージョンは SCHEMA_VERSION = "1.10.0" である （crates/pverify-core/src/report/schema.rs）。XAdES/ASiC のサブインディケーションと ContainerFormat / AsicDeviation / AsicManifestCheck 型は追加的なクローズドな 列挙/構造体である（値の追加は MINOR バンプ）。ブランチ 036 は SignatureFormat::XadesBLta（"XAdES-B-LTA"）と XadesUnverifiedTimestamp の imprint_input フィールドを追加した。これらはいずれも追加的かつ後方互換の MINOR 追加であり、schema_version には影響しない。これらのパスが再利用する共有のパス、 失効、タイムスタンプ、VRT のエンジンについては、第9章、第11章、第12章を参照。

8. JAdES 検証

JAdES（JSON Advanced Electronic Signatures、ETSI TS 119 182-1）は、pverify が検証する ETSI AdES ファミリの第4の構成要素であり、CAdES（EN 319 122）、PAdES（EN 319 142）、XAdES（EN 319 132）と並ぶものである。他の3ファミリがそれぞれ CMS、PDF、XML の上に構築されるのに対し、JAdES は RFC 7515 の JSON Web Signature（JWS）構造の上に構築され、RFC 7797 のペイロード非エンコード拡張を伴う。本章では、JAdES の処理経路において pverify が実際に検証する内容、すなわち JWS JSON Serialization 上の JAdES baseline-basic（JAdES-B-B） レベルについて、ホスト側の JSON 抽出器と no_std の検証カーネルとの境界、そして適合性を過大に主張するのではなく意図的に INDETERMINATE として拒否する形の正確な集合を文書化する。

実装は2箇所に存在し、第3章で述べたアーキテクチャ全体のホスト／カーネル分離に対応する。すなわち、JSON パースと全バイト抽出を行うホスト抽出クレート pverify-jades（crates/pverify-jades/）と、モデルに依存しない境界型を所有し、暗号検証および共有された RFC 5280 のパス／失効／ETSI パイプラインを実行するカーネルオーケストレータ crates/pverify-core/src/jades.rs である。このサポートを導入したスライスは specs/027-jades-bb-verify/ である。

8.1 スコープ：何を検証し、何を拒否するか

この処理経路の規律は、pverify が実際に供給された資料について 誠実な 結果を報告し、別の実装に一致させるために判定を調整することは決してない、という点にある。次の2つの事実は厳密に分離される（specs/027-jades-bb-verify/spec.md、Clarification Q3）。

1. 暗号的 事実：再構築された JWS Signing Input に対して、署名者証明書の公開鍵を用いて、JWS 署名が検証されるか。
2. AdES レベルの主張：入力が JAdES-B-B 署名であるか、すなわち素の JWS の上に JAdES baseline の署名済みプロパティを保持しているか。

JAdES baseline プロパティを欠く well-formed な JWS は、暗号的には依然として意味を持つが、pverify はそれを JAdES-B-B とラベル付けしない。それは検出されたが baseline ではないものとして報告され、AdES レベルの主張については INDETERMINATE を返す。これにより、素の JWS に対して JAdES 適合性を過大に主張することを回避する。

サポートされる形と拒否される形を以下にまとめる。「拒否」とは常に正確な INDETERMINATE のサブインディケーションを意味し、捏造された pass や failure を意味することは決してない（憲法 §I、「断言できないことは断言しない」）。

クローズドな SubIndication 列挙（crates/pverify-core/src/report/etsi.rs）は、5つの JAdES 固有の値を保持し、ルートのレポートスキーマに1対1で反映される。すなわち jades_payload_digest_mismatch、jades_signing_certificate_mismatch、jades_unsupported_profile、jades_unsupported_serialization、jades_signer_certificate_unavailable である。SignatureFormat 列挙（crates/pverify-core/src/report/mod.rs）は JAdES-B-B（肯定的に検証された baseline 署名）と JAdES-unsupported（拒否された形に対して保持されるラベル）を追加する。これらは追加的で後方互換性のある成長であった。スライス 027 は既存のクローズドな列挙に値を追記しただけであり、レポートの最上位の形には変更がない。レポートが保持する schema_version は本章の内容とは独立しており、その後のスライス（033 TSA 失効、034 PAdES DSS/VRI、035 OCSP nonce + CdpEntry、037 JAdES B-T/B-LT/B-LTA——これにより 1.9.0 → 1.10.0 へバンプし、3つの新たな SignatureFormat バリアント JAdES-B-T、JAdES-B-LT、JAdES-B-LTA が追加された）を通じて 1.10.0 へと進んでいる。本章は 027 について特定のバンプを主張しない。

8.2 フォーマットのディスパッチとコンテンツのスニフ

カーネルオーケストレータ verify_with（crates/pverify-core/src/verify.rs）は、detect_format におけるコンテンツのスニフによってルーティングする。%PDF- → PAdES、XML で始まる入力 → XAdES、JSON で始まる入力 → JAdES、それ以外は CAdES（ASiC は asic_signatures が非空のときに先行して処理される）。JSON スニフは looks_like_json（verify.rs:375）である。これはオプションの UTF-8 BOM をスキップし、次に ASCII 空白をスキップし、最初の非空白バイトが { である場合にのみ受理する。最上位の配列（[）は明示的に JWS JSON Serialization 文書では ない とされ、スニフによって拒否される。JSON（{）と XML（<）は最初の非空白バイトにおいて相互排他的であるため、XAdES と JAdES のスニフが衝突することは決してない（verify.rs:354-369、research R-8）。

ホスト（pverify-cli/src/main.rs::looks_like_json および web/pverify-wasm/src/lib.rs）はこのスニフをバイト単位で反映し、CLI とブラウザ内 WASM ビルドが JSON で始まるペイロードに対してのみ JAdES 抽出器を呼び出すようにする。これは CLI と WASM のパリティ不変条件の一例である。ネイティブ CLI では次のとおりである。

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

ここでは抽出のハードエラーが空の Vec に飲み込まれるが、これは黙示的な pass ではない。verify_with において、JSON とスニフされた入力に対する空の jades_components は crate::jades::jades_unsupported_entry にフォールバックし、これは JAdES-unsupported / jades_unsupported_profile / INDETERMINATE を発する（verify.rs:303-306）。したがって、消費者は常に確定的な事実を受け取る。

8.3 抽出境界：JadesComponents

いかなる JSON/XML/PDF パーサも pverify-core にリンクされてはならないというアーキテクチャ全体の規則（憲法 §V）に従い、すべての JSON パースはホスト側の pverify-jades で行われ、モデルに依存しないバイトのみがカーネルへと渡る。境界型 JadesComponents は crates/pverify-core/src/jades.rs で宣言され（したがって no_std 側がその形を所有する）、pverify-jades（crates/pverify-jades/src/lib.rs）によって再エクスポートされる。文書内の JWS 署名ごとに1つの値が生成される。general シリアライゼーションでは N 個、flattened では1個である。

ホストは抽出した Vec<JadesComponents> を追加的な VerificationRequest.jades_components フィールドへ通す（verify.rs:110）。JAdES 以外の入力ではこれは空のままとなり、他のあらゆるフォーマットについてバイト単位の同一性の不変条件を保つ。抽出器自身は 暗号処理を一切行わない。JSON パースとバイト抽出のみである（crates/pverify-jades/src/lib.rs）。

8.4 JWS Signing Input の再構築（RFC 7515 / RFC 7797）

signing input は、JWS 署名が計算される対象となるバイト列である。ホストはこれを crates/pverify-jades/src/signing_input.rs::build で構築する。

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

load-bearing な機微：ホストは文書中の protected メンバーの base64url 文字列を 逐語的に 使用する。デコードされたヘッダを再エンコードすることは しない。JSON が異なる空白で再出力されたとき、再エンコードは生成者が署名した内容からずれる可能性があり、signing input を破損させてしまう。デコードされたヘッダは、そのメンバー（alg、b64、x5c、x5t#S256、profile キー）を読むためにのみ使用される。署名検査へ供給されるバイト列は、伝送された生の形である。

payload_segment は RFC 7797 の b64 protected ヘッダフラグに依存する（signing_input.rs::build、parse.rs:123）。

• b64 が不在または true（RFC 7515 のデフォルト）：文書の payload メンバーは それ自体が BASE64URL(payload_bytes) であり、その ASCII 文字列がそのまま付加される。
• b64:false（RFC 7797 非エンコードペイロード）：生のペイロードバイトが直接付加され、第2の base64url ステップは行われない。

現在の実装では両方の分岐が payload_str.as_bytes() を付加する（b64:false の分岐は、文書の payload メンバーを UTF-8 文字列として運ばれる生のペイロードバイトとして解釈する）。本スライスは両方を意図的にサポートする。なぜなら、ETSI DSS 参照ベクトルを含む実際の JAdES 出力は、日常的に b64:false を設定するからである（Clarification Q1）。抽出器は、生成者が宣言した b64 値を、それが crit にも列挙されていない場合（RFC 7797 §6 に照らせば生成者のプロトコルエラー）であっても、誠実に記録する。それでもなお生成者が署名したとおりに signing input を構築し、カーネルの署名検査がその真実を報告する。この構築は、signing_input.rs のユニットテストにおいて RFC 7515 §A.1 および RFC 7797 §4.2 の正準ベクトルに対して検証される。

8.5 署名者証明書と署名証明書バインディング

署名者証明書はホスト側で crates/pverify-jades/src/parse.rs::resolve_x5c において解決される。x5c ヘッダは protected ヘッダから優先的に取得され、保護されない header へフォールバックする。RFC 7515 §4.1.6 に従い、各 x5c 要素は 標準 base64（パディング付き） DER である。JWS の他のあらゆる箇所で使われる base64url との意図的な対比に注意されたい。パーサは x5c には STANDARD エンジンを、protected/signature/x5t#S256 には URL_SAFE_NO_PAD を使用する。x5c[0] は signer_cert_der となり、残りは extra_certs_der のパス候補となる。これは XAdES に埋め込まれた証明書の流れを反映している。x5c が存在しない場合、結果は (None, []) となり、カーネルは jades_signer_certificate_unavailable（INDETERMINATE）を表出する。MVP はホスト側の x5t#S256 証明書ストアルックアップを 行わない。したがって x5c を伴わない x5t のみの文書は、解決されるのではなく利用不能となる（parse.rs のコメント、R-3）。

署名証明書バインディング は証明書すり替えに対する防御である。ホストは JOSE x5t#S256 サムプリント（RFC 7515 §4.1.8 — 署名者証明書の固定 SHA-256 ダイジェストで、base64url デコードされる）を JadesSigningCertBinding { cert_digest, digest_alg: Sha256 } へ抽出する（parse.rs:147-158）。JAdES x5t#o 署名済みプロパティは MVP のスコープ外である。カーネルは verify_jades のステップ5でこのバインディングを検証する（jades.rs:262-271）。compute_digest(SHA-256, signer_der) を再計算し、主張されたダイジェストと比較する。不一致は TOTAL_FAILED / jades_signing_certificate_mismatch である。これは XAdES の xades_signing_certificate_mismatch の挙動を反映し、CAdES の ESS 署名証明書バインディングの JSON 版に相当する（第5章を参照）。

8.6 アルゴリズムのマッピング（alg → 検証可能なファミリ）

ホストは JWS alg protected ヘッダ文字列を crates/pverify-jades/src/algid.rs::map_alg で JadesSigAlg へマップする。このマッピングは 新しい暗号プリミティブを一切導入しない。サポートされるすべての alg は、pverify-core::crypto が既に検証するファミリに解決される（research R-7 / FR-004）。

none は拒否される。決して pass ではない（RFC 7518 §3.6。algid.rs のユニットテスト refuses_alg_none）。Unsupported な alg はカーネルに到達し、INDETERMINATE / signature_algorithm_unsupported として表出する。失敗した入力が監査可能となるよう、locus が alg を名指しする（alg:ES512）。

ECDSA については、JWS 署名は固定幅の連結 r‖s（RFC 7518 §3.4）であるのに対し、RustCrypto の検証器は DER Ecdsa-Sig-Value SEQUENCE { r INTEGER, s INTEGER } を期待する。ホストはこれを parse.rs::ecdsa_rs_to_der（pverify-xades を反映）で変換し、最小整数エンコーディングと、最上位ビットが立っている場合の先頭ゼロパディングを正しく処理する。奇数長の（不正な）r‖s はそのまま素通しされ、カーネルが panic するのではなく 事実 として拒否するようにする。

8.7 プロファイル分類

ホストはプロファイルを parse.rs::classify_profile で分類し、サポートされる EnvelopedBB と4つの JadesUnsupportedReason の判別子との間で決定する。検査の順序は重要である。

• sigD がまず勝つ：JAdES detached ペイロード参照はスコープ外である（FR-008）。これは後に jades_unsupported_serialization にマップされる。
• ETSI B-T/B-LT/B-LTA（ブランチ 037）：sigTst（B-T）、xVals/rVals（B-LT）、または arcTst/atsHashIndex（B-LTA）の存在は、もはや入力を HigherLevel とマークしない。ブランチ 037 はこれらを ETSI 検証パスへルーティングする。詳細は §8.13 を参照のこと。
• rfsTst/tstVd のみ未サポートのまま：これらは入力を HigherLevel → jades_unsupported_profile とマークする。
• B-B の最低条件：EnvelopedBB は sigT 署名時刻ヘッダ と 署名証明書バインディングの 両方 を要求する（Clarification Q3）。JOSE x5t#S256 サムプリントがバインディングとして数えられる。いずれも満たさない well-formed な JWS は NotJadesBaseline → jades_unsupported_profile となる。要求されれば暗号的には検証されるが、決して JAdES とラベル付けされることはない。

カーネルはこれらの理由を verify_jades のステップ1でサブインディケーションへマップする（jades.rs:164-180）。NotJadesBaseline → JadesUnsupportedProfile、DetachedSigD と CompactSerialization → JadesUnsupportedSerialization。HigherLevel は現在 rfsTst/tstVd についてのみ発火し → JadesUnsupportedProfile。CompactSerialization は予約済みのバリアントである。JWS Compact 文字列は決して JSON オブジェクトを根とせず、したがって JSON 専用の抽出器には到達しない。ホストの JSON スニフはそれをここへルーティングしないであろう。

8.8 カーネル検証：verify_jades

crate::jades::verify_jades（crates/pverify-core/src/jades.rs:154）は1つの JadesComponents を消費し、1つの SignatureEntry を生成する。構造的には verify_xades と同一である。JAdES 固有のゲートを実行し、その後、解決された署名者証明書を、他のあらゆるフォーマットが使う 同一の RFC 5280 パス／失効／ETSI 集約パイプラインへ引き渡す。順序付けられたステップは次のとおりである。

ステップ4 — 署名検証。 RSA-PSS は明示的なダイジェストと salt 長を伴って crate::crypto::verify_rsa_pss へ直接ディスパッチする。それ以外はすべて jades_sig_alg_oid を介して signatureAlgorithm OID を解決し、verify_with_alg を呼び出す（jades.rs:228-242）。SPKI は署名者証明書 DER から extract_spki_der を介して再抽出される。検証器が UnsupportedSignatureAlgorithm エラーを返すと、結果は INDETERMINATE / signature_algorithm_unsupported となる。その他のエラー（真正の署名不一致）は TOTAL_FAILED / jades_payload_digest_mismatch である。このサブインディケーションは XAdES の xades_reference_digest_mismatch の JSON 版に相当する。JAdES についてはこれが、改ざんされたペイロード（signing input を変える）と改ざんされた署名値の 両方 をカバーする点に注意されたい。いずれも signing input に対する署名検証の失敗として現れるからである（e2e テスト tampered_payload_… と tampered_signature_…、いずれも → jades_payload_digest_mismatch）。

ステップ6 — 共有パイプライン。 署名者証明書と extra_certs_der のパス候補は validate_path（RFC 5280 §6 basic-plus パス構築 — 第9章を参照）へ引き渡され、次に wire_chain_step_signatures が各チェーンステップの証明書署名を RustCrypto プリミティブで検証し、次に apply_revocations が署名者チェーンの失効を評価する。決定的に重要なこととして、apply_revocations は 空の埋め込み CRL スライスと空の埋め込み OCSP スライス を伴って呼び出される（&[], &[]、jades.rs:295-305）。JAdES-B-B は埋め込み検証材料を一切保持しないため、失効はアクティブな Mode の下でのライブ／CDP チャネルによってのみ駆動される。キャッシュ材料のない --offline モードでは、これは誠実に IndeterminateRevocationOffline / revocation_not_checked_offline（INDETERMINATE）へ縮退し、レスポンダ接触を捏造することは決してない（憲法 §VII）。

SignedAttrsCheck は合成された「検証済み」レコードとして報告される（jades_signed_attrs_ok、jades.rs:575）。JWS にはそれ自体としての CMS signedAttrs は存在しない。signing input に対する署名 こそが 完全性のバインディングであり、それは既にステップ4で検査されている。ContentDigestCheck は signing input の SHA-256 を covered_content_sha256 として記録し、016 の validation_objects[] 資料インベントリが署名済み材料を表出できるようにする（jades.rs:312-313）。これは XAdES を反映している。

8.9 ETSI インディケーション集約とオブジェクトごとの VRT

基底の ETSI インディケーションは、共有された aggregate_etsi（jades.rs:315）によって、チェーンの結果、（検証済みの）signed-attrs レコード、content-digest レコードにわたって畳み込まれる。重大度の順序は TOTAL_FAILED > INDETERMINATE > TOTAL_PASSED で、最初の所見が勝つ。供給材料において失効問題のない、供給アンカーへ至る健全なチェーンは TOTAL_PASSED を返す（e2e rs256_enveloping_total_passed、es256_enveloping_total_passed）。失効した、またはパスが破断したチェーンは、CAdES と全く同様に対応する INDETERMINATE/TOTAL_FAILED を返す。JAdES の処理経路はチェーンレベルの新しい判定ロジックを一切導入しない。

JAdES-B-B はカバーするタイムスタンプを一切保持しない（本スライスでは etsiU は空である）ため、オブジェクトごとの検証基準時刻（VRT）ブロックは誠実な縮退ケースである。verify_jades はそれでも空のタイムスタンプスライスと CoveringSource::Jades を伴って共有された crate::vrt::derive_vrt を呼び出す（jades.rs:332-339）。エンジンは、signer_chain と signer_signature の両方が derivation == request_at かつ value == verification_time を持つ Vrt ブロックを返す（FR-005 / FR-011a）。ブランチ 037 では、sigTst（B-T）トークンと arcTst（B-LTA）トークンが wire 形の変更なしに共有された再帰的な外側カバーエンジンを通って流れる。arcTst のハッシュ入力は非循環である: BASE64URL(protected).BASE64URL(payload).BASE64URL(signature).BASE64URL(sigTst_verbatim_b64u) — 現在の arcTst トークン自体はハッシュ入力から除外される。オブジェクトごとの VRT は第12章で詳細に文書化されている。

後続の2つの横断的レイヤは配線されているが、今日の B-B については縮退している。

• アルゴリズム妥当性（032）。 オプトインの --algorithm-policy がアクティブな場合、evaluate_jades_algorithm_validity（jades.rs:394）は2つの ObjectUnderEvaluation を組み立てる。すなわち署名者チェーン（リーフ証明書自身の signatureAlgorithm OID により判定される）と署名者署名（JWS の alg 記述子から取られたファミリ／ダイジェスト。例えば RS256 → RSA + SHA-256 で、OID 1.2.840.113549.1.1.11 へマップし戻される）であり、いずれも（リクエスト時刻の）VRT において共有された CRYPTREC/NIST ポリシー評価器を実行する。結果は algorithm_validity を充填し、TOTAL_FAILED でない基底を縮退させ得るのみで、TOTAL_FAILED を生成することは決してない（e2e jades_algorithm_validity_populates_when_enforced）。デフォルトでは無効であり、これによりレポートはバイト単位で同一のまま保たれる。
• TSA チェーン失効（033）。 apply_tsa_revocation_indication は空のトークンスライスを伴って呼び出される（jades.rs:363）。カバーするタイムスタンプが存在しないため、B-B については no-op である。この継ぎ目は、将来の JAdES タイムスタンプレベルが PAdES/CAdES と同じ共有された apply_tsa_chain_revocation_for_token の経路を通じてそのインディケーションを縮退させられるように存在する。

8.10 出所、パリティ、再現性

肯定的に検証された署名は format: JAdES-B-B と content_source: Embedded（ペイロードが enveloping である）を伴って報告される。拒否されたすべての形は format: JAdES-unsupported と、対応する INDETERMINATE のサブインディケーションを伴って報告される。signer_cert_der/extra_certs_der は標準の 016 導出を通じて統合された validation_objects[] インベントリへ供給される。JAdES は新しい ValidationObjectOrigin バリアントを一切導入しない（ブランチ 034 の DSS/VRI 固有の pdf_dss/pdf_vri は PAdES 専用である）。

ネイティブ CLI とブラウザ内 WASM ホストは、バイト単位で同一の抽出器（pverify_jades::extract）と同一の verify_with カーネルを実行するため、同一の入力はバイト単位で同一のレポートを生成する。これが CLI と WASM のパリティ不変条件であり、web/pverify-wasm/src/lib.rs のパリティテスト（wasm_jades_sniff_and_extract_at_parity）と CLI e2e スイート crates/pverify-cli/tests/jades_bb_e2e.rs によって固定される。e2e テストは5つの正準シナリオをカバーする。すなわち RS256 と ES256 の enveloping ハッピーパス（TOTAL_PASSED）、1バイトのペイロード改ざんと署名改ざん（TOTAL_FAILED / jades_payload_digest_mismatch）、署名証明書バインディングの不一致（TOTAL_FAILED / jades_signing_certificate_mismatch）、署名者証明書の利用不能（INDETERMINATE）、sigD／素の JWS の拒否（INDETERMINATE / jades_unsupported_serialization および jades_unsupported_profile）である。再現性は、カーネルがキャプチャされた verification_time（Clock::now は決して使わない）からのみ時刻を読むことに由来する。したがって、与えられた（入力、アンカー、時刻、失効材料）のタプルは決定論的なレポートを生成する。

8.11 標準のトレーサビリティ

JAdES の処理経路は意図的に保守的である。AdES baseline の梯子を1段（B-B）登り、署名者証明書が手に入った時点から確立済みのパス／失効／ETSI 機構の全体を再利用し、完全には検証できないものすべてを、推測ではなく正確で監査可能な INDETERMINATE をもって拒否する。上位レベル（B-T/B-LT/B-LTA）および結果レポートの JWS 封筒テックデモは、本スライスでは明示的にスコープ外である（specs/027-jades-bb-verify/spec.md）。注: ブランチ 037 が B-T/B-LT/B-LTA サポートを実装した——実装の詳細については §8.13 を参照のこと。

8.13 ブランチ 037: JAdES B-T / B-LT / B-LTA 実装

ブランチ 037（specs/037-jades-bt-blta/）は、ETSI TS 119 182-1 §5.2.3–§5.2.7 の完全な unsigned-properties の梯子をカバーするよう JAdES 検証パスを拡張した。実装では3つの新たな SignatureFormat バリアント——JAdES-B-T、JAdES-B-LT、JAdES-B-LTA——を追加し、schema_version を 1.9.0 から 1.10.0 へバンプする。crates/pverify-cli/tests/jades_bt_blta_e2e.rs の3つの e2e テストはすべて PASS している。

8.13.1 sigTst（B-T）: 署名タイムスタンプ

JWS の unprotected ヘッダ内の sigTst unsigned プロパティは、JWS Signing Input に対する1つ以上の RFC 3161 タイムスタンプトークンを運ぶ。ハッシュ入力は次のとおりである:

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

これはまさに JWS Signing Input（signing_input、§8.4）であり——署名者の秘密鍵が操作した同じバイト列である。ホストは unprotected ヘッダから sigTst トークン DER を抽出し、JadesComponents.sig_tst_tokens を介してカーネルへ渡す。カーネルはトークンのインプリントを signing input の再計算に対して検証し、トークンを apply_tsa_chain_revocation_for_token（033 共有ヘルパー）に通して処理し、検証が成功した場合にはトークンの genTime を署名者オブジェクトのオブジェクトごとの VRT に設定する。sigTst を持つ入力は JAdES-B-T へ昇格される。

8.13.2 xVals / rVals（B-LT）: 埋め込み検証材料

xVals および rVals unsigned プロパティは、JWS の unprotected ヘッダに埋め込まれた証明書チェーンおよび失効情報（CRL / OCSP レスポンス）を運ぶ。ホストはこれらを JadesComponents.x_vals および JadesComponents.r_vals としてデコードして渡す。カーネルはそれらを、PAdES-LT および 034 DSS パスが使用するのと同じ embedded_crls / embedded_ocsp_responses チャネルを介して apply_revocations へ供給する——新たな失効ロジックはない。xVals/rVals を持ち（かつ sigTst も持つ）入力は JAdES-B-LT へ昇格される。

8.13.3 arcTst（B-LTA）: 非循環ハッシュ入力を持つアーカイブタイムスタンプ

arcTst unsigned プロパティは、現在の arcTst トークン自体を除いた（非循環）、ここまでに蓄積された JWS 構造全体に対するアーカイブタイムスタンプトークンを運ぶ。ハッシュ入力は次のとおりである:

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

ここで sigTst_verbatim_b64u は、unprotected ヘッダに現れる sigTst プロパティのリテラルな base64url 文字列である。現在の arcTst トークンは自身のハッシュ入力から意図的に除外される。カーネルは arcTst インプリントを検証し、トークンを apply_tsa_chain_revocation_for_token に通して処理し、オブジェクトごとの VRT アンカーを arcTst の genTime に設定する。完全に証拠を持つ入力は JAdES-B-LTA へ昇格される。

8.13.4 スコープ: 依然としてスコープ外のもの

以下はブランチ 037 では明示的にスコープ外であり、jades_unsupported_profile / INDETERMINATE として拒否されたまま残る:

• rfsTst および tstVd unsigned プロパティ（検証レポート / タイムスタンプ検証データ）。
• sigD detached ペイロード参照。
• JWS Compact Serialization。
• 複数の arcTst チェーン（単一の arcTst トークンのみ消費される; アーカイブタイムスタンプのチェーンはサポートされない）。

8.12 実験的機能: LTV-JWS（draft-miyachi-ltv-jws-00）

draft-miyachi-ltv-jws-00 は、JWS にトップレベルの ltv オブジェクトを追加し、SIG-B から SIG-LTA までの4つの累進的なレベルで検証エビデンスを運ぶ拡張を定義する。pverify は同じ pverify-jades 抽出器と verify_with カーネル経路を使い、4つのレベル全てに対して実験的なサポートを実装している（新クレート・新パイプラインなし）。

ltv ヘッダーマップは crates/pverify-jades/src/parse.rs でパースされる。4つのレベルは SignatureFormat 値 LTV-JWS-SIG-B・LTV-JWS-SIG-T・LTV-JWS-SIG-LTV・LTV-JWS-SIG-LTA にマップされる。ltv キーを持ちながら分類できない形（不正または未認識の構造）は LTV-JWS-unsupported / INDETERMINATE / jades_unsupported_profile として報告される。

レベル判定規則（classify_ltv_level、parse.rs に実装）：

各 ltv.* 値は Base64URL エンコードされた JSON（インライン JSON でなく）であるため、抽出器は各フィールドを decode して再パースする。ltv.signing オブジェクトは署名者証明書チェーンを運び、既存のパス検証パイプラインへの橋渡しとなる：署名者リーフと中間証明書の DER バイトが x5c 相当のチェーン候補として validate_path へ供給される。ltv.signing または ltv.timestamp に埋め込まれた失効材料は、PAdES-LT が使用するのと同じ embedded_crls／embedded_ocsp_responses チャネルを通じて apply_revocations／apply_tsa_chain_revocation_for_token へ投入される。これは既存インフラの追加的な再利用であり、新たな失効ロジックは導入されていない。

docs/research/ltv-jws-compatibility-notes.md に記録されたinteropの知見には：ltv.timestamp/ltv.signing の BASE64URL ラッピング（素のインライン JSON に対して）；ltv.archive の {"timestamp": BASE64URL} dict 形状；SIG-LTV/T の判別子としての validations キー；などがある。これらはドラフト著者へのフィードバック候補である。

スコープと状態. これは draft-miyachi-ltv-jws-00 を追跡する実験的な実装である。ドラフトの進化に伴い形式が変わる可能性がある。4つの LTV-JWS-* SignatureFormat 値は既存のクローズド列挙への追加的追加であり後方互換。憲法改正は不要。crates/pverify-cli/tests/ltv_jws_fixtures.rs の18の統合テストが4つのレベル全てと unsupported-profile フォールバックをカバーする。

9. X.509 証明書パス検証

リリース: v1.3.0 · レポートスキーマ: 1.9.0

9.1 スコープとパイプライン上の位置づけ

本章では、pverify-core の X.509 証明書パスエンジン、すなわち、リーフ（エンドエンティティまたはCA）証明書、候補となる中間証明書のプール、トラストアンカーの集合、および検証時刻が与えられたときに、証明書パスを構築し、その上で 構造的な RFC 5280 §6 の不変条件を評価するサブシステムを規定する。本エンジンは、あらゆる AdES 形式の判定が依拠する基盤である。すなわち、CAdES、PAdES、XAdES、JAdES、および ASiC が委譲する内部署名のすべてが、同一の validate_path エントリポイントへ収束する（形式ディスパッチの概要については第4章を参照）。

本エンジンは全面的に crates/pverify-core/src/path/ に存在する:

もう一つの関心事、すなわち、各非アンカーステップの signature をその親の SubjectPublicKeyInfo に対して検証する処理は、意図的に path/mod.rs には 含めていない。これはオーケストレータ（crates/pverify-core/src/verify.rs、wire_chain_step_signatures、verify.rs:1944）に配線されており、これにより RustCrypto ディスパッチが依存グラフへ厳密に一度だけ取り込まれ、CMS署名者署名検証と共有される。この分離については §9.8 で説明する。

本エンジンは 純粋な計算 を行う。すなわち、すでにパース済みの Certificate プロジェクションと TrustAnchor バイト構造（ホストが、第3章で説明した 憲章 §V/§VI の境界に従って、すべての DER 取り込みとトラストアンカー読み込みを済ませている）を受け取り、ChainOutcome を返す。ソケットを開かず、ファイルを読まず、Clock::now を一切参照しない。唯一の時刻入力は、呼び出し側が供給する verification_time 引数であり、これは第12章（タイムスタンプ / VRT）で説明する手順で導出された、オブジェクトごとの検証基準時刻（VRT）である。これこそが、同一のエンジンをネイティブと wasm32-unknown-unknown ターゲットの双方でバイト単位で同一に実行できる理由である。

本章は、仕様 specs/003-v03-rfc5280-path/（v0.3 — 名前制約、ポリシー処理、アンカー駆動の初期化）および specs/008-v06-bridge-acceptance/（v0.6 — DFS+バックトラックのパス構築、複数ブリッジ走査、サイクル検出）に基づいている。

9.1.1 RFC 5280 §6 の二つの側面と、誠実なスコープ記述

RFC 5280 §6 のパス検証には、明確に異なる二つの側面がある:

1. 構造的検証 — 名前連鎖（issuer↔︎subject）、有効期間、basicConstraints、keyUsage、名前制約、証明書ポリシー。この側面は path/mod.rs とその兄弟モジュールで実装されており、本章の主たる主題である。
2. 暗号的検証 — 各証明書の signatureValue が、発行者の subjectPublicKeyInfo に対応する秘密鍵によって生成されたことを検証する。この側面は verify.rs::wire_chain_step_signatures（§9.8）で実装されている。

本エンジンは、何を強制し何を強制しないかについて誠実である。とりわけ、extendedKeyUsage 拡張は、すべての ChainStep に パースおよび表出 されるが（ChainStep.extended_key_usages、path/mod.rs:334）、パスエンジンによって 強制はされない。すなわち、必要な EKU を欠くエンドエンティティ証明書の拒否は行われず、また監査者にとって特筆すべきこととして、パスエンジン内で TSA 証明書に対する id-kp-timeStamping（OID 1.3.6.1.5.5.7.3.8）要件は課されない（path/ と timestamp.rs を grep しても EKU 比較は見つからない）。EKU は、憲章 §I の事実報告の規律に整合して、観測した事実として報告される。EKU の強制を必要とする検証者（信頼当事者）は、表出された extended_key_usages フィールドを読む。本スコープ記述は、埋もれさせるのではなく、関連する箇所で以下に再掲する。

9.2 エントリポイントと結果の形状

唯一のエントリポイントは次のとおりである:

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

（path/mod.rs:103）。その入力と各々に対する契約は次のとおりである:

戻り値:

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

chain_result は、レポートシリアライザが消費する ChainResult であり、終端アンカーを含む各証明書につき一つの ChainStep、加えて terminating_anchor_fingerprint と bridge_attempts ベクタからなる。structural_indication は、パス検証が構造的な異議を生じなかった場合は None であり（TOTAL_PASSED に至る前には、依然として下流の CMS / 失効 / ダイジェスト層が実行されなければならない）、構造的な所見が生じた場合は、aggregate_etsi（§9.9）が署名ごとの ETSI 判定へ畳み込む Indication + SubIndication + locus（step[N] または anchor/chain）を保持する Some(StructuralFinding) である。

StructuralFinding は常に locus を保持しており（path/mod.rs:81）、これによってすべての判定が問題のある特定の証明書を指し示す。これは、レポートが裸の真偽値ではなく failing_locus を伴う事実インベントリであるべきという 憲章 §I の要件に沿うものである。

9.3 パス構築（DFS + バックトラック）

パス構築は、construct_chain（path/mod.rs:477）によって実装される、バックトラックを伴う深さ優先探索である。これは、ブランチ 008（FR-601/FR-602）において v0.5 の単一パス「最初に一致する中間証明書」を辿る方式を置き換えたもので、複数ブリッジのチェーンや行き止まりの中間証明書を正しく扱えるようにしつつ、単一パス方式が既に生成していた単一アンカーの直線チェーン（V1–V23）についてはバイト単位で同一の出力を維持する。各深さにおいて、ウォーカは依然として 最初に 一致する候補を優先するため、直線チェーンではバックトラックを行う必要が決して生じない。

9.3.1 探索

construct_chain の鍵となる不変条件:

• アンカー優先（FR-025）。 各ステップにおいて、ウォーカはまず、サブジェクトDNが現在の証明書の issuer DN に一致するトラストアンカーを探す。一致するアンカーのうち、以下の4優先度戦略で選択する（path/mod.rs:536-572）：
  1. AKID一致 + 有効期間カバー：AKID keyid がアンカーの SKID と一致 かつ 有効期間が検証時刻をカバーする。同一 DN を持つ複数世代の CA が混在する場合に正しい世代を選ぶタイブレーカーである。典型例は GPKI OfficialStatusCA 2019 対 2024 鍵更新であり、同一のサブジェクト DN を持ちながら SKID が異なる。TrustAnchor.subject_key_identifier に SKID バイトを、Certificate.authority_key_identifier に子証明書の AKID keyid を保持し、子証明書が実際に署名を受けたアンカーの公開鍵を選択する。
  2. 有効期間のみ：有効期間が検証時刻をカバー（AKID なし/不一致）。
  3. AKIDのみ：AKID は一致するが有効期間が外れている（期限切れまたは未発効）。
  4. 先着（レガシーフォールバック）：AKID なし、有効期間のオーバーラップもなし。 AKID優先（優先度1）がなければ、DN のみの照合は鍵更新期間中に誤った CA 世代を選択し、チェーンステップの signature_verification: Failed を引き起こす。署名者の証明書は世代 A に発行されたにもかかわらず、ストアに A と B の両方が含まれており DN のみの照合が B を先に選んでしまうためである。これが、有効期限切れだが一致するアンカーでもチェーンを終端できる理由である（その後フラグが立てられる、§9.4）。
• DN照合。 すべての issuer↔︎subject の連結は、.linkage を介して match_dn（rfc4518-minimal 比較器、§9.10）を用いる。ウォーカは連結の判断のために生の DER バイト列を比較することは決してない。
• 深さごとの試行インデックス。 tried_indices[i] は、チェーン深さ i+1 で試行すべき次のプールインデックスを記録する。ウォーカが中間証明書 i を選択すると、スロットを i+1 へ進める（path/mod.rs:614）ため、バックトラック時には同じ中間証明書を再選択するのではなく、次の 兄弟 が試行される。これは、旧来の単一パス不変条件を明示的インデックス指定で復元したものである。
• 深さ上限。 MAX_CHAIN_DEPTH = 10（path/mod.rs:62）。これは v0.6 において最悪ケースの複数ブリッジチェーン（leaf → ApCA-foreign → Foreign-Bridge → Domestic-Bridge → DomesticRoot、5ステップ）に対して再評価され、10 のまま維持された。上限に到達してもパニックしない。ウォーカはバックトラックへ落ち、最終的にチェーン不完全の INDETERMINATE を表出する（§9.6）。

9.3.2 サイクル検出

相互認証グラフ（とりわけ GPKI BridgeCA ↔︎ ピアブリッジ）はサイクルを含みうる。素朴な探索は無限ループに陥りうる。construct_chain は、完全な DER エンコード済み証明書の SHA-256 フィンガープリント（cert.fingerprint、path/mod.rs:496-497）でキー付けされた、パスローカルな BTreeSet<[u8; 32]>（cycle_set）を保持する。現在のパス上に既に存在する候補の中間証明書はスキップされる（path/mod.rs:580）。この集合は push 時に投入され、バックトラック時にクリアされる（backtrack、path/mod.rs:667）。

同一性キーとして、SubjectPublicKeyInfo のフィンガープリントや (Subject DN, SPKI) タプルではなく 完全な証明書 DER のフィンガープリント を選択したことは意図的であり、specs/008-v06-bridge-acceptance/spec.md（Clarification Q7、FR-602）に文書化されている。GPKI / FBCA の相互認証証明書のローテーション期間中、トラストストアは正当に、同一の (Subject DN, SPKI) を持ちながら署名と有効期間ウィンドウが異なる二つのブリッジCA証明書を保持する。SPKI ないしタプルでキー付けしたサイクル検出は、これらを一つの論理ノードとして扱い、二つ目の有効なクロッシングを誤って拒否してしまう。完全な DER フィンガープリントはこれらを正しく区別する。RFC 5280 §6 はサイクル検出アルゴリズムを規定していない（事前構築済みのパスを前提としている）ため、これは RFC が義務付ける同一性ではなく、pverify 独自の停止保証である。

9.3.3 構築の出力

construct_chain は (chain, bridge_pairs, terminating_anchor) を返す:

• chain — リーフ先頭の証明書パス（chain[0] = リーフ、chain[len-1] = アンカーに最も近い中間証明書）。
• bridge_pairs — 観測されたすべての相互認証証明書のクロッシングを [child_fp, attached_fp] ペアとして表したもの（§9.7）。直線チェーンでは空。
• terminating_anchor — アンカーへのパスが見つかった場合は Some(anchor)、そうでなければ None。

9.4 有効性、BasicConstraints および KeyUsage のチェック

構築後、validate_path は chain をリーフ先頭で辿り（path/mod.rs:144）、ステップごとに構造的事実と所見を記録する。

9.4.1 時刻における有効性（FR-008 / FR-025）

各証明書について、本エンジンは cert.validity.covers(verification_time)（path/mod.rs:159）を評価する。ウィンドウが当該時刻をカバー しない 場合、サブインディケーションを誠実にするため、本エンジンは「まだ有効でない」と「期限切れ」を区別する（path/mod.rs:163）:

トラストアンカーは anchor_chain_step（path/mod.rs:700）によって別途扱われる。これはホストが算出した validity_window_covers_request_time フラグを用い、期限切れのアンカーは TOTAL_FAILED ではなく INDETERMINATE / AnchorExpiredAtTime（path/mod.rs:715）を生じる。この非対称性は意図的である。ウィンドウ外のリーフ/中間証明書はパスの厳格な有効性失敗であるのに対し、ウィンドウ外の アンカー は検証者（信頼当事者）が異なる方法で解決しうる構成上の問題であるため、pverify は偽造を主張するのではなく、INDETERMINATE で事実を報告する（憲章 §I「断言できないことは断言しない」）。

アンカー終端ステップは、アンカー DER を一度再パースし（path/mod.rs:709）、リーフ/中間ステップと同じフィールド形状 — サブジェクトのテキスト、有効期間ウィンドウ、鍵用途、基本制約、署名アルゴリズム — を保持できるようにする。DER のデコードに失敗した場合（ホストが読み込み時に検証済みであるため、本来は起こり得ない）でも、レポートをシリアライズできるよう、プレースホルダフィールドを伴ってステップが発行される（<unparseable anchor>、path/mod.rs:742）。これは 憲章 §I のノーパニック姿勢である。

9.4.2 BasicConstraints（RFC 5280 §4.2.1.9）

すべての 非リーフ ステップ（idx > 0）において、basicConstraints.cA は true でなければならない（path/mod.rs:182）。拡張が存在しないか cA == false の場合、本エンジンは INDETERMINATE / KeyUsageMissingRequiredBit を発行する。これは、コードのコメントにあるとおり、cA ビットの欠如が「keyCertSign 欠如の構造的な双子」であり、v0.3 が独自の missing-cA サブインディケーションを新設しないことを選択したため、より広い KeyUsageMissingRequiredBit サブインディケーションを再利用するものである（path/mod.rs:187-194）。

数値の pathLenConstraint はレポートへ 表出される（ReportBasicConstraints.path_len_constraint）が、数値的には強制されない（path/mod.rs:179-181 のコメント:「v0.1 は path_len_constraint を数値的に無視する」）。監査者はこの点に留意すべきである。すなわち、ある中間証明書が宣言した pathLenConstraint を超過するパスは、当該制約を可視化したうえで報告されるが、それのみを根拠に拒否されることはない。§9.3.1 の厳格な深さ上限（MAX_CHAIN_DEPTH = 10）が、実際に強制される唯一の深さ制限である。

9.4.3 KeyUsage（RFC 5280 §4.2.1.3）

（path/mod.rs:202-225。）リーフ規則は RFC 5280 が厳密に要求するよりも厳しい。RFC 5280 は、拡張が不在の場合に要求するかスキップするかを実装に委ねているが、pverify v0.1+ は、署名意図を明示するため、リーフが署名ビットを伴う keyUsage を保持することを 要求する（path/mod.rs:208-209）。digitalSignature と並んで nonRepudiation（別名 contentCommitment）を受容することは、否認防止証明書が一般的な GPKI/JNSA プロファイルに整合する。

9.5 名前制約（RFC 5280 §4.2.1.10 / §6.1.4(g)）

名前制約処理はアンカー先頭であるのに対し、チェーン探索はリーフ先頭であるため、本エンジンは、リーフ先頭のステップループがそれを参照する前に、各チェーン深さにおける累積状態を構築する 事前パス（compute_name_constraints_states、path/mod.rs:822）を実行する。事前パスは次を行う:

1. アンカー自身の nameConstraints（initialise_from_anchor、name_constraints.rs:83）から深さ 0 の状態を初期化する — これは FR-046a/Q3 が義務付ける RFC 5937 のアンカー駆動の規律である。これは、国内ルートが PKI 全体の制約を宣言する GPKI ブリッジCAにとって運用上重要なケースである。
2. アンカーに最も近い証明書 → リーフへと辿り、各 CA の制約を吸収するために apply_intermediate（name_constraints.rs:97）を呼び出し、各吸収の後に状態を記録し、その後ベクタを反転して、リーフ先頭のステップループがそれを直接インデックスできるようにする（path/mod.rs:859-873）。

9.5.1 状態の合成

状態（NameConstraintsState、name_constraints.rs:54）は、RFC 5280 §6.1.4(g) の「各名前形式について維持される制約」を反映して、形式ごとに独立したリストを保持する:

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

RFC 5280 に従い、permittedSubtrees（許可サブツリー）は 積（intersection） によって、excludedSubtrees（除外サブツリー）は 和（union） によって合成される。実装は、形式ごとに各深さの許可エントリの和を保持し、チェック時 に積のロジックを実行する。これはサポートされる形式集合について深さごとの積と等価であり、その旨が文書化されている（name_constraints.rs:109-117）。

サポートされる GeneralName 形式 は directoryName、dNSName、rfc822Name および uniformResourceIdentifier である（name_constraints.rs:34、FR-043）。制約中に現れるそれ以外の形式（x400Address、ediPartyName、registeredID、otherName）は unsupported_forms_pending に記録され、§9.5.4 の保守的な拒否を発火させる（FR-614）。

9.5.2 形式ごとの照合（check_subject）

check_subject（name_constraints.rs:165）は、サブジェクトおよび SAN エントリを累積状態に対して評価し、厳格な形式ごとの規律を適用する（Q1）。形式をまたいだ照合は禁じられている:

• directoryName は証明書の subject（および任意の directoryName SAN エントリ）に照合される。照合規則は RFC 5280 の「制約された DN が名前の（DIT の観点での）接頭辞である」である。RFC 4514 は RDN を最も具体的なものを先頭としてレンダリングするため、実装は rfc4518-minimal 正規化（小文字化、RDN 区切り周辺の空白除去、canonical_dn、name_constraints.rs:446）のもとで、カンマ境界チェックを伴う大文字小文字非依存の 接尾辞 比較を行う（dn_under、name_constraints.rs:468）。この制限はコード中で開示されている（name_constraints.rs:289-295）。すなわち、ASN.1 レベルの RDN 順序や属性ごとの照合に依存する制約は、v0.3 の規則の範囲外である。
• dNSName — 大文字小文字非依存。先頭の . は「の厳密なサブドメイン」を意味する（.example.jp は host.example.jp に照合するが example.jp には照合しない）。ドットが無い場合、制約は厳密なホストまたは任意のサブドメインに照合する（matches_dns、name_constraints.rs:388）。
• rfc822Name — @ を含む制約は特定のメールボックスである。先頭ドットの制約は厳密なサブドメインに照合する。裸ドメインの制約は、ドメインがちょうどそのドメインであるアドレスに照合する（matches_rfc822、name_constraints.rs:400）。RFC 5280 §6.1.4(g) の注記に従い、rfc822Name 制約は、rfc822Name SAN が存在 しない場合に限り、subject 内の emailAddress AVA にも 追加で 照合する（name_constraints.rs:224-249）。
• uniformResourceIdentifier — 制約は URI オーソリティの ホスト成分のみ に適用され（uri_host がスキーム、ユーザ情報、ポートを剥がして抽出する）、その後 dNSName として照合される（matches_uri_host、name_constraints.rs:418）。

9.5.3 自己発行の適用除外（Q2）

RFC 5280 §6.1.4(g) の注記に従い、名前制約は、自己発行の非リーフ 証明書のサブジェクトには 適用されない。その場合 check_subject は NameConstraintsOutcome::SkippedSelfIssued を返す（name_constraints.rs:171-176）。リーフは自己発行であっても常にチェックされる。ステップごとのレポートは name_constraints_check.skipped_self_issued = true を設定し、適用除外が監査可能となる。自己発行の判定は match_dn(issuer, subject).linkage である（path/mod.rs:230）。

9.5.4 結果 → インディケーションのマッピング

check_subject の結果は構造的所見スタックへ畳み込まれる（path/mod.rs:258-284）。v0.6 の再ルーティング（T626、FR-632、Clarification Q3）は、v0.3 の挙動からクローズドな列挙の表面を変更したため、監査者にとって重要である:

その論拠（path/mod.rs:241-257）は、まさに 憲章 §I に立脚する。すなわち、制約 失敗 は、「検証者（信頼当事者）は、チェーンのステートマシンが結論づけたものとは異なる名前制約ポリシーを持ちうる」ため、v0.3 の TOTAL_FAILED/ChainConstraintsFailure タグから INDETERMINATE/IndeterminateNamedConstraint へ再ルーティングされる。pverify は、チェーンが偽造であると主張することなく、「制約ステートマシンによって拒否された」ことを表出する。サポートされない形式 は、保守的に同じ INDETERMINATE タグへ拒否される（FR-614）。構造的に 不正形式（malformed） の拡張のみが、それ自身の NameConstraintsMalformed タグを保持する。なぜなら、不正形式 DER は「制約がチェーンを能動的に拒否した」とは区別される構造的健全性のシグナルだからである。

9.6 証明書ポリシー（RFC 5280 §6.1）

ポリシー処理は、同じアンカー先頭の事前パスの規律を用いる（compute_policy_states、path/mod.rs:884）。状態（PolicyState、policy.rs:56）は、valid_policy_tree（nodes: Vec<PolicyTreeNode>）に加えて、三つの §6.1.4 カウントダウン explicit_policy_pending、policy_mapping_pending、inhibit_any_policy_pending、および malformed スロットをモデル化する。

9.6.1 処理される拡張（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 初期化と状態の探索

initialise（policy.rs:111）は、アンカーの certificatePolicies が存在する場合はそれから（RFC 5937 アンカー駆動、FR-046a）、そうでなければ {anyPolicy} から、ツリーをシードし、その後 user_initial_policy_set（空 = {anyPolicy}、RFC 5280 §6.1.1(c)）を通してフィルタする。アンカーの policyConstraints / inhibitAnyPolicy がカウントダウンをシードする。

apply_intermediate（policy.rs:153）は、§6.1.3(d)（証明書が宣言したポリシーとツリーの積、intersect_with_cert_policies、policy.rs:206）および §6.1.4(a)/(b)/(c)（カウントダウン。次の証明書が減算後の値を見るよう、各証明書の後にゼロで飽和させて減算される、policy.rs:186-191）を実装する。ポリシーマッピングは issuerDomainPolicy ノードを subjectDomainPolicy で置き換え（apply_mappings、policy.rs:266）、policy_mapping_pending == 0 を尊重する（マッピング予算が枯渇した場合、マッピングは §6.1.4(b) に従って黙って破棄される）。

v0.3 の簡略化は policy.rs:33-39 に開示されている。すなわち、expected_policy_set はすべてのノードについて [valid_policy] として投入される（v0.3 はそれらを分岐させる複数マッピングのケースを行使しない）。ポリシーマッピングのサイクル検出は、チェーン探索がチェーン終端後に停止する（自己制限的である）ため、別途実装されていない。

9.6.3 リーフでの締め処理（§6.1.5）と GPKI 空ツリー修正

compute_outcome（policy.rs:304）は §6.1.5 の締め処理をリーフでのみ行う。回帰テストを伴う、根幹に関わる機微は、空ツリーのケースである:

RFC 5280 §6.1.5 に従い、パス処理は explicit_policy > 0 または valid_policy_tree が非 NULL のときに成功する。したがって、空ツリーが拒否となるのは requireExplicitPolicy が発火した場合（explicit_policy_pending == Some(0) としてモデル化される）に限られる。

（policy.rs:316-326。）これが重要なのは、実際の GPKI / 官報（Kanpō）チェーンが、policyMappings を持たず、リーフのポリシー OID が発行者のものと異なるという形態を一般的に取るからである。すなわち、ツリーはリーフで正当に空になるが、いずれの証明書も requireExplicitPolicy をアサートしないため、チェーンは 受容される。空ツリーを無条件に拒否していた以前のバグは、それらの実際のチェーンを誤って INDETERMINATE にしていた。ガードテスト compute_outcome_empty_tree_at_leaf_without_explicit_policy_is_verified とその with_explicit_policy 対応版（policy.rs:413-443）が、修正後の挙動を固定している。

その他の §6.1.5 拒否: ツリーに anyPolicy のみがある状態での inhibitAnyPolicy == 0（InhibitAnyPolicyViolatedAtLeaf）、特定のポリシーが無い状態での requireExplicitPolicy 発火（ExplicitPolicyViolated）、およびツリーに一致する特定のポリシーが無い非空の user-initial-policy-set（EmptyTree）（policy.rs:342-366）。

9.6.4 結果 → インディケーションのマッピング

（path/mod.rs:300-323。）名前制約と同様に、v0.6 の再ルーティングは、能動的に拒否されたポリシーパスを新しい IndeterminatePolicyRejected タグへ反転させ、構造的健全性（不正形式 DER）のシグナルには PolicyMappingsMalformed を保持する。すべてのポリシー判定は INDETERMINATE であり、TOTAL_FAILED には決してならない。ポリシー不一致は「チェーンが この ポリシー集合を満たさない」ことであって、偽造の証明ではない。

9.7 ブリッジCA / 複数アンカーの相互認証証明書走査

pverify は、相互認証証明書を通じたドメイン間の信頼をサポートする。これは、ブリッジCAが複数のドメインルートと相互認証される GPKI BridgeCA モデルである。二つの機構が協調する。

9.7.1 クロッシング検出

bridge::detect_crossing（path/bridge.rs:56）は、候補の中間証明書の issuer/subject DN をアンカー集合に対して比較することで、二つの典型的な相互認証証明書の形態を認識する:

1. 国外が国内を署名する — 中間証明書の subject は我々のアンカーの一つだが、その issuer は我々が保持しない CA である（!issuer_in_anchors && subject_in_anchors）。
2. 国内が国外を署名する — 中間証明書の issuer は我々のアンカーの一つだが、その subject は我々の信頼集合の外にある（issuer_in_anchors && !subject_in_anchors）。

いずれも、BridgeAttempt.crossing_pair フィールド向けにクロッシングペア [intermediate_fp, anchor_side_fp] を返す。

9.7.2 DFS ウォーカ内の走査（FR-601）

v0.6 では、ウォーカはブリッジを拒否するのではなく能動的に走査する。リーフより上のすべてのホップはクロッシングペアとして記録される（path/mod.rs:618-643）:

• 別の中間証明書の上に 中間証明書を接続するホップ（チェーン深さ ≥ 2）は、常にクロッシング [current_fp, intermediate_fp] として記録される — これが、中間証明書から中間証明書へのブリッジホップ（V24 複数ブリッジ形態）が捕捉される仕組みである。
• リーフ→最初の中間証明書の境界（深さ 1）では、v0.3 の bridge::detect_crossing ヒューリスティックが参照される。V9 単一ブリッジ形態はこの分岐に当たる。

バックトラック時には、一致する bridge_pairs エントリ（その二つ目のフィンガープリントが pop された証明書に等しいもの）も pop される（backtrack、path/mod.rs:682-690）ため、記録されたクロッシングは常に最終的なチェーンを反映する。

9.7.3 ブリッジ試行の判定（事後）

チェーンが構築され、ステップごとの所見が収集された後、各クロッシングは BridgeAttempt へ変換される（path/mod.rs:397-445）:

複数ブリッジチェーンについては、v0.6 実装は（あれば）最初の失敗をすべてのクロッシングに適用する。ブリッジごと・所見ごとの相関は将来の改善として記されている（path/mod.rs:386-393）。各 BridgeAttempt はさらに name_constraints_evaluated を保持する。これは、ブリッジ側の証明書が nameConstraints 拡張を保持し かつ ブリッジ側の制約失敗が記録されなかった場合に true となり（path/mod.rs:424-437、FR-633/US3-AS1）、当該クロッシングの制約がチェックされたという積極的な証拠を監査者に与える。

9.7.4 廃止された bridge_ca_required_unsupported

v0.1/v0.2 では、相互認証証明書を必要とするチェーンは INDETERMINATE / bridge_ca_required_unsupported を生成していた。FR-048 はその発行を 削除した。当該サブインディケーションはクローズドな列挙に残っている（追加的スキーマの規律に従い、保存済みレポートのデシリアライズのために保持される）が、もはや発行されない（verify.rs:2670-2673）。v0.3+ は代わりに chain_result.bridge_attempts[*].result/detail を通じてブリッジCAの結果を報告し、v0.5（FR-510）は旧来の単一フィールドを bridge_attempts ベクタへ改称した。

チェーンが真にいずれのアンカーにも到達せず かつ クロッシングが記録されなかった（bridge_pairs が空）場合、本エンジンは locus = "chain" でサブインディケーションを持たない汎用の構造的 INDETERMINATE を表出する（path/mod.rs:372-378） — これは誠実な「このパスは不完全である」というシグナルである。

9.8 暗号的ステップ検証（path/ の外側に配線）

validate_path は、各非アンカー ChainStep.signature_verification をプレースホルダ ChainStepSignature::Failed { reason: "cert signature verification deferred to T034" } で投入する（path/mod.rs:340）。このプレースホルダは、構造的所見スタックによって chain_signature_failed 所見へ 決してマッピングされない（path/mod.rs:22-24）ため、レポートを汚染し得ない。validate_path は構造的サブインディケーションのみを表出する。

その後オーケストレータは wire_chain_step_signatures（verify.rs:1944。CAdES 署名者チェーンについては verify.rs:568、オブジェクトごとの VRT 再検証については verify.rs:783、TSA チェーンについては verify.rs:1585 で呼び出される）を呼び出して、プレースホルダを実際の結果で置き換える。各非ルートステップについて、それは次を行う:

1. 親 SPKI を特定する — 次のステップの証明書、または終端ステップについてはアンカーの SPKI（parent_spki_for_step、verify.rs:2037）。
2. 子証明書を (tbsCertificate DER, signatureValue) に分割する（split_certificate_for_verification、verify.rs:2063）。
3. crate::crypto::verify_with_alg(sig_alg_oid, parent_spki, tbs, sig) へディスパッチする。これは OID + SPKI ファミリによって RSA PKCS#1 v1.5、RSA-PSS、ECDSA P-256/P-384、Ed25519 および ML-DSA をルーティングする（RustCrypto のみ — WASM クリーンな暗号制約については第3章を参照）。

結果のマッピング（verify.rs:1994-2011）:

パス構造の検証と暗号ステップの検証を分離したのは、RSA / ECDSA / Ed25519 / ML-DSA の依存を path/ の内側で重複させるのではなく、コアグラフへ厳密に一度だけ取り込み、CMS 署名者署名パスと共有するためである。

9.9 パス所見が ETSI 判定になる仕組み

署名ごとの ETSI インディケーションは aggregate_etsi（verify.rs:2343。全体のレイヤリングについては第5章 §5.7 を参照）によって算出される。パス検証の所見は、その優先順位の梯子の 最上位 に入る:

1. 構造的 TOTAL_FAILED — chain.structural_indication が TOTAL_FAILED 所見（期限切れ/まだ有効でない証明書、リーフの KeyUsage 失敗、非リーフの keyCertSign 失敗）である場合、他のすべての原因に先んじて直ちに返る（verify.rs:2375-2378）。pick_dominant_finding（path/mod.rs:819）が、この時点より前に最も重大な所見を選択する（TotalFailed > Indeterminate > TotalPassed、同点の場合は最初に push されたものが勝つ）。
2. アーカイブタイムスタンプのインプリント不一致、OCSP レスポンダ署名失敗、signedAttrs 失敗、コンテンツダイジェスト不一致、失効（RevokedOnCrl/RevokedOnOcsp） — これらは構造的 TF の後にレイヤリングされる CMS/失効の原因である（CMS、失効、タイムスタンプの各章を参照）。
3. チェーンステップにおけるサポートされないアルゴリズム / 不正形式の鍵 — verify.rs:2548-2576 で走査される。cert_signature_alg OID がサポート表に無いステップは INDETERMINATE / SignatureAlgorithmUnsupported を生じる。OID は認識されるが signature_verification の理由が "malformed public key:" で始まるステップは INDETERMINATE / PublicKeyMalformed を生じる。
4. 名前制約とポリシーの INDETERMINATE — IndeterminateNamedConstraint、NameConstraintsMalformed および IndeterminatePolicyRejected について、それ自身の優先順位スロットで発行される（verify.rs:2604-2668）（これらは通常すでに structural_indication 経由で到達するが、ステップごとの走査は防御的なものである）。

監査者に関連する留意点。 汎用の 暗号的な検証失敗を生じるチェーンステップ — verify_with_alg が UnsupportedSignatureAlgorithm でも MalformedPublicKey でもないエラー、すなわち中間証明書の証明書に対する真の不正署名 — を返す場合、それは aggregate_etsi において、現時点では専用の TOTAL_FAILED / ChainSignatureFailed インディケーションへは ルーティングされない。SubIndication::ChainSignatureFailed 値はクローズドな列挙に存在する（report/etsi.rs:41）が、コードベース内でのその唯一の構築はユニットテスト内にある（verify.rs:2971）。集約は、サポートされない OID および不正形式の鍵の形態については明示的に走査するが、正真正銘の偽造された中間証明書署名は、レポートツリー内の当該ステップの signature_verification = Failed { reason } という事実にのみ反映され、トップレベルの TOTAL_FAILED へは昇格されない。実務上、署名者自身の署名（CMS 層、梯子の §2 で検証される）と失効が支配的な攻撃面をカバーし、偽造された中間証明書は通常 DN/issuer 連鎖にも失敗するだろう。しかし、記録されたステップの事実と集約された判定との間のこのギャップは、糊塗するのではなく、レビューのためにここに文書化する。

9.10 DN 照合: rfc4518-minimal

すべての issuer↔︎subject 連結の判断 — パス構築、自己発行検出、ブリッジ検出、およびステップごとの dn_match_with_parent 証拠 — は、match_dn（crates/pverify-core/src/x509/name.rs）、すなわち rfc4518-minimal 比較器を通る。それは、意図的に縮小された stringprep プロファイルを適用する（name.rs:1-24）:

1. ASCII の大文字小文字畳み込み（A–Z → a–z）。
2. 空白の圧縮 — [\t\n\f\r ] の連なりを一つのスペースへ畳み込み、先頭/末尾をトリムする。
3. エンコーディングの統一 — UTF8String、PrintableString、BMPString、TeletexString および IA5String を Unicode 文字列へデコードしてから 1–2 を適用する。

それは意図的に、NFC 対 NFD の Unicode 合成の差異を 畳み込まない。開示（name.rs および v0.1 リサーチノート R-005）は、これまでに観測された実際の GPKI 不一致がエンコーディングタグと末尾空白の差異であり、そのいずれもこの最小プロファイルが捕捉することを記録している。手法文字列は、すべてのレポートで dn_match_method == "rfc4518-minimal-v0.1" として固定されており、FR-061 は v0.3 系統内でそれを変更することを禁じている（完全な stringprep は後のブランチとなる）。各 ChainStep は DnMatchEvidence（method、bytewise_equal、および適用された緩和）を保持しているため、監査者はバイト単位非等価の連結がどのように確立されたかを正確に確認できる（path/mod.rs:155-157、report/mod.rs:678）。

9.11 レポート表面（ChainStep）

パス内のすべての証明書 — リーフ、中間証明書、および終端アンカー — は、一つの ChainStep を生成する（crates/pverify-core/src/report/mod.rs:611）。パス検証監査に最も関連するフィールド:

パスエンジン自身が発行する revocation レコードは、常にプレースホルダ（placeholder_revocation、path/mod.rs:787、anchor_revocation_placeholder、path/mod.rs:804）であり、IndeterminateNoCrl と当該証明書の CDP URI を保持する — 誠実な「この層ではまだ評価されていない」という値である。実際の CRL/OCSP の結果は失効サブシステム（失効の章を参照）によって書き込まれる。これが、aggregate_etsi が失効所見を走査する際にアンカーのプレースホルダレコードが明示的にスキップされる理由である（verify.rs:2476-2489）。

name_constraints_check および policy_check フィールドが Option であり、自明な状態については不在となることは、再現性を保持する設計である（#[serde(skip_serializing_if = "Option::is_none")]、report/mod.rs:634、643）。すなわち、制約/ポリシーを持たないチェーンは v0.3 以前のレポート形状とバイト単位で同一にシリアライズされ、憲章 §II の追加機能のバイト同一性の不変条件を尊重する。

9.12 不変条件と失敗モードの要約

• 純粋、決定的、WASM クリーン。 I/O なし、クロックなし。唯一の時刻入力はオブジェクトごとの VRT 引数である。同一の入力 ⇒ ネイティブと wasm32 で同一の ChainOutcome。
• 停止は保証される。 パスローカルな完全 DER フィンガープリントのサイクル検出に加えて MAX_CHAIN_DEPTH = 10 上限が、敵対的な相互認証グラフ上で construct_chain を停止させる。
• 有効性は最も厳格な構造的失敗である。 ウィンドウ外のリーフ/中間証明書は TOTAL_FAILED。ウィンドウ外のアンカーは INDETERMINATE（偽造ではなく構成の問題）。
• 名前制約とポリシーの拒否は INDETERMINATE であり、決して TOTAL_FAILED ではない — pverify は、チェーンが偽造であると主張することなく、「このアンカー/ポリシー集合のもとでステートマシンによって拒否された」ことを報告する（憲章 §I）。
• EKU と pathLenConstraint は表出され、強制されない。 これには、パスエンジン内で TSA 証明書に対する id-kp-timeStamping 要件が無いことが含まれる。
• ブリッジCA走査はサポートされる。 各クロッシングは、Accepted / RejectedConstraintFailure / RejectedPolicyInconclusive の判定を保持する BridgeAttempt として記録される。レガシーの bridge_ca_required_unsupported の発行は廃止された。
• 汎用のチェーンステップ署名失敗 は、ステップごとの事実として記録されるが、現時点ではトップレベルの ChainSignatureFailed 判定へ集約されない（§9.9 の留意点）。

下流の層 — CMS 署名者署名検証、失効（CRL/OCSP、PAdES /DSS+/VRI 材料を含む）、タイムスタンプと VRT 導出、アルゴリズムポリシー、および ETSI 集約 — は、本エンジンが返す ChainOutcome の上に構築される。それぞれの章を参照されたい。

10. トラストアンカー管理

リリース: v1.3.0 · レポートスキーマ: 1.9.0

本章では、pverify のトラストアンカーがどこに由来するのか、候補となるルートがどのように認証され配布物へ受け入れられるのか、検証カーネルがそれらをどのように消費するのか、そして同等に重要なこととして、何が意図的にアンカーでないのかを説明する。トラストアンカーの選定は、署名検証器が下す決定のうち最も重大な単一の決定である。すなわち、それは公理的に、どの署名が TOTAL_PASSED に到達しうるかを決定する。したがって pverify は、アンカー管理を RFC 6024（Trust Anchor Management Requirements）に支配される*出所（プロビナンス）*の問題として扱い、暗号カーネルの厳格に外側に保ち、憲章 §I に沿って監査可能な事実として表出する。

本章の内容は、第3章で定義されたカーネル境界（crate::traits::TrustAnchorStore 能力トレイト）の上に位置し、第9章で説明されるパス検証エンジンへと供給される。ここで論じる取り込みクレート（pverify-eutl、pverify-aatl、pverify-anchor-inventory）は、ホスト専用の std ライブラリであり、cargo-tree ゲート（scripts/cargo-tree-gate.sh）が WASMクリーンなコアグラフから排除している。トポロジーについては第3章 §3.2 を参照。

10.1 アンカーモデル：カーネルは何も保持せず、ホストがすべてを供給する

検証カーネル pverify-core は、組み込みのトラストアンカーをゼロで出荷される。アンカー集合は、常に呼び出し側が単一の能力トレイトを通じて供給する。

// 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、AKID タイブレーク用
}

これは意図的なアーキテクチャ上のコミットメントであり、docs/trust-anchor-policy.md §10 に文書化されている。すなわち 「pverify-core はトラストアンカーを埋め込まない。アンカー集合は常に呼び出し側が供給する（CLI は --trust-anchors 経由、ブラウザはバンドルされた roots.json 経由）」。これは PKI 監査人に関係する三つの帰結を持つ。

1. カーネルは信頼を密輸できない。 pverify-core は no_std + alloc であり、I/O を行わず unsafe を禁止している（第3章 §3.1）ため、ルートをコンパイル時に埋め込んだり、取得したり、その他の手段でカーネル内部に実体化したりする経路は存在しない。パス検証に到達するすべてのアンカーは、運用者が検査可能なホストローダーを通過している。
2. 五つの同一性／ルーティングフィールドがアンカーの全表面である。 カーネルはアンカーをその出所に対して再パースしない。TrustAnchor のドキュメントコメントが述べるとおり、これらのフィールドは「ルーティングと同一性の表面のみ」である。der_bytes の構造的 DER パースはパスエンジン（x509::Certificate）内部で行われ、発行者→主体者のマッチングは RFC 4518 の最小 DN マッチャー（crate::x509::name::match_dn）を用いて生の subject_dn バイトで行われる。subject_key_identifier は SKID keyid バイトを保持し、同一 DN を持つ複数世代のアンカーが存在する場合の AKID ベースタイブレークに用いられる（第9章 §9.3 アンカー優先選択参照）。
3. アンカーの妥当性はホストの責任である（FR-025）。 validity_window_covers_request_time は、検証時刻 t に対してホストがロード時に計算する（crates/pverify-cli/src/trust.rs）。ストアは「意図的に不活性」である。すなわち、期限切れのものを含むすべてのアンカーを、供給された順序で表出し、重複排除もフィルタリングも決して行わない（InMemoryTrustAnchorStore、traits.rs）。パス構築は、その後、フラグが false であるアンカーをすべてスキップする。期限切れのアンカーを完全に除外してしまうと、運用者がそれを供給したという事実を覆い隠してしまう。それを表出することで、レポートが期限切れアンカーの所見を記録できる。

10.1.1 確立（establishment）と検証（verification）の区別（RFC 6024）

監査人から繰り返し寄せられる質問（docs/trust-anchor-policy.md §9 で詳述）は、アンカーの認可元の公表（例：kanpo.go.jp で告知される官報 SECOM ルート）が依然として有効か、あるいは配布ホストの TLS が依然として妥当かを、pverify が検証時に再確認すべきかどうかである。それは行ってはならず、意図的に行わない。 このポリシーは RFC 6024 の確立（一回限りの安全な帯域外認証であり、authority_url ＋ SHA-256 ピン ＋ retrieved_at として記録される）と検証（既に確立されたローカルのアンカー集合に対するパス検証）の分離に従う。ひとたびアンカーのフィンガープリントが台帳にピン留めされれば、それは自己認証的である。検証時にソースを再取得することは §II 再現性を破壊し、021 net-guard によって閉じられた SSRF 表面を再導入し、証明に何も加えない。これは、OS／ブラウザのルートストアが、TLS ハンドシェイクのたびに各 CA のウェブサイトに再接続したりしないのと正確に同じである。検証時にカーネルがアンカーに対して行う唯一の証明書チェックは妥当性ウィンドウであり、これはパス検証が既に t で評価している。公表の再アテステーションはガバナンス／ライフサイクルの活動（台帳更新またはリリースケイデンス）であって、ランタイムの振る舞いではない。

10.2 アンカーの出所チャネル

pverify は複数の配布チャネルからアンカーを認識し、それぞれに data_source 出所タグを付す。これらのチャネルは三つの信頼ティアに分かれており、docs/trust-anchor-policy.md §2 で列挙されている。

10.2.1 ピン留め台帳（web/roots/*.json）

主要なチャネルは機械可読な JSON 台帳（ルートごとに1ファイル）であり、それ自体がポインタ＋整合性ピンのトラステッドリストである。docs/trust-anchor-policy.md §4 のとおり、証明書バイトはコミットされない。各台帳エントリは、ソース URL（retrieved_from）、SHA-256 ピン、data_source、purpose、主体者 DN、妥当性ウィンドウ、採用根拠を記録し、web ビルド（build-roots.mjs）がビルド時にバイトをダウンロードし、ピンと一致しない場合は失敗する（改竄されたダウンロード、または発行者鍵のローテーションのいずれかを捕捉する）。四つの受け入れ条件（ポリシー §3）は次のとおりである。公式の authority_url を伴う認可された出所であること。SHA-256 ピンの一致。構造的妥当性（自己署名、BasicConstraints cA=TRUE、keyCertSign、未来日付）。そして完全な出所記録。

台帳に保持される確認済みの data_source トークンは次のとおりである。

10.2.2 LGPKI2 トラストアンカー（lgpki2-org-ca-r2.json）

web/roots/lgpki2-org-ca-r2.json は地方公共団体の公文書電子署名を担う J-LIS LGPKI2 Organization CA R2（シリアル 5b:87:8c:23）を記録する。

なぜ信頼できるか。 J-LIS 公式 CA 情報ページ（authority_url: https://www.lgpki.go.jp/CAInfo/install.htm、retrieved_from: https://www.lgpki.go.jp/CAInfo/ocar2ver2.cer）から取得し、SHA-256 フィンガープリント（ca137029…）を台帳にピン留めしている。ビルドはライブバイトとピンが不一致の場合に失敗する。CP/CPS および技術仕様書（C-6-4-5_LG_tech_LGPKI_spec）も同一ドメインで公開されている。

信頼スコープ。 GPKI ブリッジ CA と相互認証されているが、BCA 自体はいかなる公開ルートストア（OS・ブラウザ・Microsoft Trusted Root）にも含まれていないため、実質的に閉じた PKI である。主に都道府県・市区町村の公文書署名が対象。

失効確認。 加入者証明書の CDP は DirectoryName 形式（CN=CRL{N},OU=Organization CA R2,O=LGPKI2,C=JP）のみ; www.lgpki.go.jp:389 はインターネット到達可能（2026-06-26 確認）で dirname_to_ldap_url ヒントテーブル（§11.4）経由で取得。オフライン検証は /DSS 埋め込み CRL を使用。

10.2.3 PQC 相互運用ラボチャネル（隔離され、本番の信頼ではない）

別個の実験的ティアが FPKI BRAWL Dev FCPCA D1 ルートを保持する。これは pverify のポスト量子検証パス（010-ml-dsa-verify）を行使する ML-DSA-87（FIPS 204、OID 2.16.840.1.101.3.4.3.19） の自己署名ルートである。purpose: pqc-interop-lab でタグ付けされ、web UI は明示的な「experimental lab — not a production trust anchor」バッジを表示する。あらゆる表面で data_source／purpose によって隔離されており、本番の検証パスを暗黙のうちに終端させることは決してない。

10.2.4 ブートストラップ／リスト署名者の区別

二つの data_source トークン、eidas-lotl-signer と AATL の aatl-list-signer は、文書署名用アンカーではない。これらは取り込みソースを認証するために用いられるピン留め署名者である（EU LOTL XML、Adobe AATL PDF）。ポリシーは明示的である（§2）。これらは「文書署名用アンカーではない（purpose: …-signer、検証トラストストアには注入されない）」。LOTL を通じて受け入れられた国家 CA は purpose: eidas-qualified の下で隔離される。AATL 経由で受け入れられた政府ルートは data_source: adobe-aatl の下で隔離される。ブートストラップ署名者が --trust-anchors に入ることは決してない。

10.3 EU トラステッドリストの取り込み（pverify-eutl、スライス 014）

pverify-eutl は ETSI TS 119 612 の TrustServiceStatusList（TSL）を取り込み、取り込み出所でラップされた通常の pverify_core::traits::TrustAnchor 値を発行する。これはネイティブの std クレートであり、コア／WASM ランタイムグラフからゲート排除されており、それ自身ではネットワーク I/O を一切行わない。LOTL 探索中の各国リストの取得は、呼び出し側が供給する fetch クロージャ（crates/pverify-eutl/src/ingest.rs、ingest_lotl）であり、これによりクレートは決定論的で、捕捉したバイトからテスト可能なまま保たれる。

10.3.1 信頼モデル：署名者ピンであって RFC 5280 チェーンではない

決定的に重要なこととして、eutl はトラステッドリストを、自己署名アンカーへの RFC 5280 チェーンを構築し失効検証を実行することで認証するのではない。crates/pverify-eutl/src/verify.rs が文書化するとおり（リサーチ R-003）、「信頼はピン（OJEU ピン留めの LOTL 署名者、または LOTL が保証する国家署名者の同一性）によって確立される」。したがって authenticate() は次を行う。

1. pverify_xades::extract を介してエンベロープされた ds:Signature を抽出する（すべての XAdES 検証が用いるのと同じ Exclusive C14N エンジン bergshamra-c14n を再利用する — 第7章）。
2. 埋め込まれた署名者証明書が、ピン留めされた signer_certs のいずれかと DER 完全一致 することを要求する（signer_certs.iter().any(|pin| pin.as_slice() == signer_der)）。
3. すべての ds:Reference ダイジェストを検証する（コンテンツの整合性）。
4. pverify_core の RustCrypto プリミティブ（RSA-PSS、RSA PKCS#1 v1.5、xades_sig_alg_oid における OID 解決に従った ECDSA）を用いて、正規 SignedInfo 上の署名値を検証する。
5. 存在する場合、SigningCertificateV2/CertDigest のバインディングを強制する（証明書差し替え防御）。

サポートされない XAdES プロファイル、正規化、または署名アルゴリズムは、そのリストにとっての検証失敗であって、チェックの暗黙のスキップでは決してない（FR-004）。そして「ここで失敗したリストからはアンカーが一切読み取られない」（ingest_one は空のアンカーとともに signature_verified: false を返す）。

10.3.2 時刻 t におけるステータスフィルタ（セキュリティの中核）

eutl において最もセキュリティクリティカルな単一の決定は、crates/pverify-eutl/src/status.rs および verify.rs::authenticate に実装された granted-at-t フィルタである。TSL サービスは、二つの条件が成り立つ場合かつその場合に限りトラストアンカーを産出する（ingest.rs::anchor_services）。

• ServiceType が正確に …/Svctype/CA/QC であること（SVCTYPE_CA_QC、R-002、ServiceType のみ）。Qualifications は意図的に参照されない。TSA / OCSP / CRL サービスタイプは non_ca_qc_type で除外される。
• 検証時刻 t において有効なステータスが granted であること（STATUS_GRANTED、R-001）。

ステータスリゾルバ ServiceStatus::status_at(t)（status.rs）は時刻について精密である。現在のステータスに加え ServiceHistory から、時刻付きの (StatusStartingTime, ServiceStatus) の各インスタンスをすべて収集し、昇順にソートし、半開区間 [starting_time, next_starting_time) が t を含むインスタンスを選択する（最後の区間は右側が非有界である）。t ではなく「現在」で解決すると、文書が署名された後に取り下げられた CA を信頼するか、署名時には付与されていた CA を不信とするかのいずれかとなり、セキュリティ目標と §II 再現性の双方を破壊する。境界のセマンティクスは左端を含む（StatusStartingTime のちょうどその時点で新しいステータスが発効する）。これは boundary_at_exact_starting_time テストが表明するとおりである。

受け入れられる集合は granted のみである。eIDAS 以前の11個のレガシーステータス URI（undersupervision、accredited、supervisionincessation など、LEGACY_STATUS_URIS で列挙される）は認識されるため、過去の t での解決は正しい区間に着地するが、それらはすべて除外する。レガシーの「アクティブ」状態へ広げることは記録されたフォローアップであって、決して暗黙のうちに想定されない。認識されないステータス URI は「granted ではない」（除外）として解決され、暗黙のうちに受け入れられることは決してない。

検査されたがアンカー化されなかったすべてのサービスは、その理由とともに excluded[]（ExcludedService / ExclusionReason::{NonCaQcType, Status}）に記録されるため、§I の事実記録は、何が受け入れられ何が落とされたかの双方について誠実である。ServiceDigitalIdentity がパース可能な CA 証明書を一切伴わなかった granted な CA/QC サービスもまた、暗黙のうちに落とされるのではなく記録される（granted_but_no_parseable_ca_certificate）。

10.3.3 部分的成功を伴う LOTL 探索

ingest_lotl は完全な LOTL（List of Trusted Lists）探索を駆動する。

各国リストは、グローバルなアンカー集合に対してではなく、LOTL がそれに対して保証する署名者の同一性（TslPointer.expected_signer_identity、ポインタの ServiceDigitalIdentity 由来）に対して認証される（FR-012）。失敗した単一の国は、記録された理由とともに SkippedList となり、実行を中断することは決してない（FR-011、R-006 部分的成功）。これは誠実な「到達したが取り込まれなかった」シグナルである。アンカーは国をまたいで SHA-256 フィンガープリントによって重複排除され、seen_in がすべての (territory, service_name) の裏書きを蓄積し（dedup_and_sort）、決定性のためフィンガープリント順で発行される。

TSL は、C14N 層が既に信頼している同じ bergshamra-xml DOM 上でパースされる（crates/pverify-eutl/src/tsl.rs、リサーチ R-004）。これは単一の XML パーサであり、第2のパーサがもたらす署名ラッピング／パーサ差異のリスクを排除する。不正形式またはルートのない XML は致命的な EutlError であって、決して暗黙の空ではない。

10.3.4 アンカー構築と observed_status

受け入れられた各 CA 証明書は、pverify-cli/src/trust.rs がそれらを構築するのと正確に同じく、build_anchor によって TrustAnchor に変換される。CA 証明書（BasicConstraints.cA == true）のみがアンカー化され、リーフ形状の ServiceDigitalIdentity 証明書は記録されアンカー化されない。産出されるすべてのアンカーは purpose: "eidas-qualified" と observed_status: "granted" を保持する。憲章 §I はドキュメントコメントで補強されている。observed_status は「生の TS 119 612 ステータス文字列のみを記録する」のであり、purpose = "eidas-qualified" は「出所／隔離タグであって、決して判定ではない」。pverify は「適格（qualified）」も「法的有効性」も決して業務上の判定をしない。

10.4 Adobe Approved Trust List の取り込み（pverify-aatl、スライス 026）

pverify-aatl は pverify-eutl の AATL 版である。Adobe の AATL 配布物（https://trustlist.adobe.com/tl12.acrobatsecuritysettings）は CMS 署名された PDF 1.6（PAdES） であり、その署名チェーンは自己署名の Adobe Root CA G2 で終端し、単一の FlateDecode の text/xml /EmbeddedFile をラップする。これは名前空間のない <SecuritySettings><TrustedIdentities><Identity>… リスト（約294個の同一性）である。クレートは ingest(distribution_bytes, adobe_root_ca_g2_der, at) という、ネットワーク I/O のない純粋関数である。

10.4.1 実際の PAdES パイプラインによるピンベース認証

eutl と同様に、AATL 配布物はピンによって認証されるが、その機構は注目に値する。crates/pverify-aatl/src/pdf.rs::authenticate は、ピン留めされた Adobe Root CA G2 のみを含む単一アンカーストアに対して、VerificationMode::Offline で実際の pverify_core::pades::verify_pdf パイプライン（第6章）を実行する。受け入れ基準は構造的なピンベースの述語であって、ETSI Indication ではない。これは意図的である。オフラインでは、配布物の ETSI インディケーションは INDETERMINATE（失効検証ができない — §I の「断言できないことは断言しない」規律）であることが期待されるため、インディケーションを消費するとすべてのオフライン取り込みを拒否してしまう。代わりに entry_satisfies_pin は、産出されたいずれかの SignatureEntry に対して次を要求する。

1. chain_result.terminating_anchor_fingerprint == hex(SHA-256(pin)) — チェーンがピン留めされた Adobe Root CA G2 に到達した。
2. すべてのチェーンステップ署名が Verified（アンカーステップは NotApplicableForRoot）。
3. CMS 署名属性の署名が Verified かつ signed_attrs_digest_match == Some(true)。
4. content_digest_check.digest_match == true — 埋め込まれた XML ペイロードが無傷である。

信頼はピンであり、eutl が OJEU ピン留めの LOTL 署名者を信頼するのと正確に同じである。（verify_pdf 呼び出しは、034 の DSS/VRI 材料には &Default::default() を、032 のアルゴリズムポリシーには None を渡すため、認証は素朴なピン留めルートのチェーンチェックである。）

10.4.2 政府関連フィルタ（文書化されたヒューリスティックであって、決して判定ではない）

認証の後、extract_embedded_xml が展開された text/xml /EmbeddedFile を取り出し、parse_identities（crates/pverify-aatl/src/parse.rs）が各 <Identity> を同じ bergshamra-xml DOM 上でパースする。classify（ingest.rs）はその後、ある同一性をアンカーとして受け入れるのは、順に、次が成り立つ場合に限る。

1. その <Certificate> 本体が base64 デコードでき かつ X.509 としてパースできる（さもなくば certificate_parse_failed）。
2. <Trust><Root> が 1 である（さもなくば not_root）。
3. <Trust><CertifiedDocuments> が 1 である（さもなくば not_certified_documents）。
4. その主体者 DN が政府関連キーワードヒューリスティックに一致する（さもなくば not_government_affiliated）。

このヒューリスティック（crates/pverify-aatl/src/filter.rs::is_government_affiliated）は、主体者 DN を、クローズドで文書化された GOV_KEYWORDS 集合（government、gobierno、gouvernement、icp-brasil、cca india、bundesamt、ministry、federal、uae、dod など）に対して大文字小文字を区別しない部分文字列マッチで照合する。憲章 §I がこの表面を明示的に支配する。「ヒューリスティックは判定ではない…ヒューリスティックが見落とした真に政府由来の同一性は除外され記録されるのであって、決して暗黙のうちにアンカー化されることはなく、境界的な一致はレビューのために可視である」。一致したキーワードはアンカーの affiliation_match 出所フィールドに逐語的に記録されるため、人間がすべての受け入れを監査でき、キーワードリストは「監査表面である — 意図的に拡張せよ、決して暗黙のうちに拡張するな」。ユニットテストは両方向をピン留めする。政府の主体者（ICP-Brasil、Swiss Confederation、CCA India）は一致する。係争中の商用 CA（WoSign）および通常の商用ルート（DigiCert）は一致しない。

除外されたすべての同一性は、その ExclusionReason とともに ExcludedIdentity として記録されるため、和集合（受け入れアンカー ∪ 除外）は配布物の全同一性数に等しい — この不変条件は後にインベントリで表出される（§10.5）。

10.4.3 バンドルせず取得する方針と SECOM 類似名の注意点

AATL 配布物は取得され、コミットされない（docs/trust-anchor-policy.md §2）。Adobe のキュレートされた編纂物は再配布ライセンスが不明確である（潜在的な編集著作権／データベース権）ため、pverify は一般的な OSS の慣行（tl-create、PDF4QT、pyHanko）に従い、ユーザ／CI が Adobe から直接取得するようにしている。台帳に記録されるのは、ピン留めされた Adobe Root CA G2（Adobe 自身のルート）のみである。ポリシーはまた、監査人が留意すべき具体的な罠も指摘する。官報トラストルート（SECOM RSA Root CA 2023 / OfficialStatusCA 2024）は AATL に含まれず（DER-SHA256 で別物であることを確認済み）、AATL には紛らわしい名前の類似品 SECOM Document Signing RSA Root CA 2023 が含まれているが、これを官報アンカーと混同してはならない — 官報アンカーは個別にピン留めされたままである。

10.4.4 リスト署名者証明書を配布物自身からブートストラップする

AATL 台帳エントリの retrieved_from は、裸の証明書ではなく AATL 配布物（tl12.acrobatsecuritysettings、PAdES 署名された PDF）を指している — エントリがピン留めする Adobe Root CA G2 は、その PDF の CMS 署名の内側に存在する。以前はウェブビルド（build-roots.mjs）が取得バイトからピン留め証明書を直接読み取ろうとしており、台帳がキャッシュ済み DER ではなく配布物を指している場合に CLI へ誤ったバイトを渡していた — その結果 ingest-aatl は何も認証できず、本番のルート一覧ページは AATL アンカーをゼロ件しか取り込めていなかった。ビルドは現在、CLI 呼び出しの前に配布物からピン留め証明書を抽出する。すなわち PDF 内のすべての /Contents <hex…> CMS ブロブをデコードし（オペレータ提供の裸証明書のために生バイトスキャンへフォールバックし）、各々から X.509 DER の SEQUENCE をスキャンして、DER SHA-256 が台帳ピンに等しい最初のスライスを返す（extractPinnedCertByHash）。ピンにハッシュ一致するスライスのみを受理することで、スキャンはそれがバイト列のどこを指していても安全になる。ピンが唯一の完全性アンカーであり続ける（バンドルせず取得する方針は維持され、新たに何もコミットしない）。一致するスライスがなければ、ビルドは未認証の証明書を取り込むのではなく AATL レポートをスキップする。

10.5 アンカーインベントリ（pverify-anchor-inventory、スライス 028）

pverify-anchor-inventory は、pverify のリリースが配布するすべてのチャネルを読み取り、単一の正規 Inventory 成果物を発行するホスト専用の std 集約ライブラリである。これは二つの表面によってバイト単位で同一に消費される。CLI の pverify trust-anchors dump コマンドと、トラストアンカー可視化ページを支える web の web/site/trust-anchors.json である。その構築上の保証（aggregate はクロック読み取りもランダム性もない純粋関数であり、write_json は2スペースインデント／LF／末尾改行1個の JSON を発行する）により、同じリリース入力に対する2回の実行はバイト単位で同一となる — 憲章 §II 再現性であり、リリース間のアンカードリフト差分の基礎である。

10.5.1 チャネルと重複排除

クローズドな ChannelLabel 列挙型がチャネル集合とその表示順序を固定する。pinned-ledger、fpki-bundle、eutl、aatl-trusted、aatl-excluded、pqc-interop（crates/pverify-anchor-inventory/src/inventory.rs）。集約器は各チャネル（ピン留め台帳エントリ、捕捉した eutl の IngestReport、捕捉した AATL の IngestReport）を取り込み、その後 merge_and_sort がフィンガープリントによって重複排除しつつ帰属（attribution）をマージする。同じフィンガープリントが二つのチャネルに現れる場合（例：FCPCA G2 台帳ルートでもある FPKI 証明書）、複数の EntryAttribution を伴う1個の AnchorEntry が発行され、affiliation／country／key_algorithm については先勝ち（first-non-empty-wins）となる。FPKI ルート（data_source == "fpki"）は fpki-bundle へ振り分けられ、pqc-interop-lab purpose は pqc-interop へ振り分けられ、残りは pinned-ledger へ振り分けられる。

10.5.2 除外された同一性の §I 隔離

026 の取り込みが落とした AATL の同一性は、別個の型（ExcludedEntry）として別個の JSON 配列（excluded[]）で読み取り専用に表出されるため、「いかなるレンダリング／フィルタ／ソート／エクスポートの経路もそれらをトラストアンカーと衝突させ得ない」（FR-007/FR-010）。web UI はこれを独立したタブ（「AATL 除外（参考）」）として、永続的で消去不可能な「informational, not a trust anchor」バナーとともに実現する。各 not_government_affiliated の除外について、インベントリは主体者 DN の傍らに完全な GOV_KEYWORDS のスナップショットと固定された平易な監査ノート（GOV_KW_AUDIT_NOTE）を埋め込んだ GovKwAudit パネルを添付する — レビュアーが §10.4.2 のヒューリスティックを盲信することなく検査によって監査できるようにする（FR-009）。

10.5.3 自己検査の不変条件

check_invariants（crates/pverify-anchor-inventory/src/aggregate.rs）はインベントリが返される前に呼び出され、いかなる違反に対してもビルドを声高に失敗させる。監査上の関心事として次がある。

• INV-3: アンカーフィンガープリントが対ごとに相異なる（重複排除が実際に起きた）。
• INV-4 / INV-5: entries[] と excluded[] がそれぞれの決定論的ソート順序にある。
• INV-7: （AATL-trusted アンカー ∪ 除外された同一性）の数が、捕捉した AATL の IngestReport.total_identities に等しい — §10.4 の保存則であり、ビルド時チェックとして表出される。
• INV-6 / INV-8: すべての次ホップエッジがその親の寄与チャネル内にとどまり、is_inventory_anchor はフィンガープリントが真に entries[] に存在する場合にのみ設定される。

10.5.4 チェーン到達性：意図的に保守的な1ホップビュー

crate::chain_reach::derive_next_hop_issuers は「このルートの向こう側に何があるか」（US3）に、レンダリング時の単一ホップで答える。各ルートについて、その自身の各寄与チャネル内で、発行者 DN がそのルートの主体者 DN に等しい配布済みエントリを列挙する（トリム後の RFC 4514 テキスト等価性であり、OID エンコードのマッチングよりこちらを選んだのは「人間がデータを読む方法」を反映するためである、R-4）。二つの性質が荷重を担い、監査人に関係する。

• チャネルをまたぐエッジはない（FR-014）。 pinned-ledger のルートは、DN が一致してもなお fpki-bundle から次ホップを拾わない。チャネルをまたぐエッジが表出するには、同じエントリが両方のチャネルに帰属を寄与しなければならない。cross_channel_edges_forbidden テストがこれをピン留めする。
• 誠実な空（FR-012）。 ルートのみの材料を出荷するチャネル（AATL trusted、PQC-interop、GPKI／官報のピン留めルート）は next_hop_issuers: [] を産出し、レンダラは空配列を手がかりに明示的な「no next-hop issuers recorded in the distributed material」メッセージを印字する — 決して暗黙の空パネルではなく、決して捏造されたエッジではない（§I）。

これはパス検証ではなく、いかなる信頼の主張もしない。既に配布されたバイトに対する検査の補助である。

10.5.5 レンダリング：出所別グルーピングと大規模チャネルの折りたたみ

ウェブのトラストアンカ画面（web/site/roots.js）はインベントリを出所（data_source）別にまとめ、各カードになぜそのルートが同梱されているか — どの PKI／プログラム由来か — を表示する。これにより読者はカードを展開せずとも一目でアンカーを判断できる。各カードはローカライズされた data_source タグ（SOURCE_KEYS：GPKI、GPKI 相互認証の認定認証局、商業登記、官報、FPKI、EU 信頼リスト、Adobe AATL、PQC 相互運用ラボ）と、そのエントリの国タグを表示する。未知の出所は生キーへフォールバックする（決して隠さない、§I）。ページの残りを埋もれさせるほど大きいチャネル — 実際には数百の各国リストアンカーを抱える EU LOTL／各国信頼リスト — は、既定でチャネルバナーをサマリとする <details> の背後に折りたたまれる（COLLAPSED_BY_DEFAULT）。これにより国内のピン留め台帳ルートは見えたまま、EU チャネルは意図的なクリックで開く。ピン留め台帳チャネルは「個別ピン登録のルート（手動台帳）」と表示し、取り込まれたリストではなく手動でキュレートされ個別にピン留めされた集合であることを伝える。

10.6 フラット N（トラステッドリスト）対 ブリッジ／階層の信頼モデル

pverify のアンカーチャネルは、構造的に異なる二つの PKI 信頼トポロジーを体現しており、その区別は、アンカー集合において何が畳めて何が畳めないかにとって重要である。

ブリッジ／階層モデル（米国 FBCA、CertiPath、日本の GPKI BridgeCA フェデレーション）は還元可能である。すなわち、単一のアンカーに相互認証証明書のプールを加えたものが、多くのドメインにおける信頼を表現できる。なぜならブリッジがドメインルートを相互認証するからである。pverify のパスエンジンは、ブリッジのクロッシングを crates/pverify-core/src/path/bridge.rs（第9章）で明示的に扱う — detect_crossing が「外国が国内を署名する」および「国内が外国を署名する」相互認証証明書の形を認識する。

トラステッドリストモデル（eIDAS LOTL/TSL、Adobe AATL）は還元できない。これは N 個の相互に独立した自己署名ルートのフラットな集合であり、各々が列挙によって個別に信頼される。それらすべてが相互認証する単一のブリッジは存在しない。プロジェクトメモリノート「トラスト組み込み非対称性」に記録され（eutl/aatl 設計によって確認されているとおり）、ブリッジ／階層のルートは「1アンカー + 相互認証証明書プール」に畳めるが、トラステッドリストは畳めない — web/roots 集合は、構成上、独立した自己署名ルートのリストであるため、「ブリッジ CA 以外をすべて落とす」は妥当な還元ではない。これこそが、eutl と aatl が単一の取り込み「スーパーアンカー」ではなく、受け入れられたルートごとに1個の通常の TrustAnchor を発行する理由である。フラット N モデルはフラット N 個のアンカーを要求し、各々が自身の出所を保持する。

10.7 アンカーでないもの

三つのクラスの証明書がアンカー集合から意図的に除外される。監査人はこれらの境界が保たれていることを検証すべきである。なぜなら、各々が設計によって閉ざされた現実の攻撃または混同を表すからである。

10.7.1 PAdES /DSS の /Certs は決してアンカーではない

034 PAdES DSS/VRI 機能（第6章）は、PDF の文書レベルの /DSS /Certs プールを消費して署名者の証明書チェーンを構築する。これらの証明書は、中間／リーフのパス構築候補としてのみ受け入れられ、決してトラストアンカーとしてではない（crates/pverify-core/src/pades/mod.rs、Q7/FR-005）。コードは使用箇所で明示的である。解決された /Certs は intermediates 候補集合に追加される —

// 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());
    }
}

これは本質的に重要である。/DSS は検証対象の文書の一部であり、攻撃者が制御可能である。もし /Certs エントリがトラストアンカーになりうるなら、敵対者は自己署名ルートを埋め込み、自身の署名チェーンをそこで「終端」させることができてしまう。チェーンは依然として運用者が供給したアンカーに到達しなければならない。同じ規則が Adobe revocationInfoArchival 材料にも適用される（それは失効の証拠を供給し、signature_embedded でタグ付けされ、決してアンカーではない）。

10.7.2 合成フィクスチャルート

fixtures/bundles/*/trust-anchors/ 配下の28個の合成ルートは、テストスイートのためにのみ存在する。それらはポリシーの受け入れ条件1〜3（docs/trust-anchor-policy.md §5）を満たさず、実際の文書署名用アンカーとして配布されることは決してない。

10.7.3 取り込みブートストラップ署名者

§10.2.4 で述べたとおり、EU LOTL 署名者（eidas-lotl-signer）と Adobe Root CA G2（aatl-list-signer）は取り込みソースを認証する。それらが検証トラストストアに注入されることは決してない。OS／ブラウザのトラストストアへの所属だけでも、同様に受け入れの理由とはならない — 四つのポリシー条件が決定する（docs/trust-anchor-policy.md §5）。

10.8 取り込んだアンカーの再投入と CLI 表面

統一的な設計上の選択が本章全体を結びつける。すなわち、取り込みはカーネルが既に理解していないものを何も生み出さない。 すべての取り込みクレートは、pverify-cli/src/trust.rs が --trust-anchors のために生み出すのと同一の (der_bytes, SHA-256 フィンガープリント, subject_dn, validity-covers-t) の形でアンカーを構築する。したがって CLI の取り込みコマンドは、受け入れられたアンカーを PEM ファイル（アンカーごとに1個の <fingerprint>.pem、決定論的なファイル名。crates/pverify-cli/src/ingest.rs::materialize と der_to_pem）として実体化し、運用者はそれを通常の verify --trust-anchors <DIR> ウォーカーにそのまま再投入できる。CLI は ingest-trust-list（eutl、完全な探索のための --lotl と、リスト署名失敗のための終了コード 4 を伴う）、ingest-aatl（aatl）、および trust-anchors dump（インベントリ）を公開する。

これは 憲章 §I と §10.1 のアンカーモデルにおいてループを閉じる。pverify-core はいかなる取り込みクレートからも何も得ない — レポート列挙型と schema_version は凍結されたままである — なぜなら取り込みは通常の TrustAnchor 群とそれ自身の出所レポート型を発行し、カーネルが目にする唯一の信頼は、唯一の能力トレイトを通じて再投入された、フラットで、運用者が供給し、フィンガープリントでピン留めされたアンカー集合だからである。

11. 失効検証

リリース: v1.3.0 · レポートスキーマ: 1.9.0

本章では、pverify が署名の証明書パス（certification path）上の各証明書について、その失効状態をどのように確定するかを述べる。本章が扱うのは、pverify が理解する2つの失効チャネル — CRL（RFC 5280）と OCSP（RFC 6960）—、配布点からの取得・署名に埋め込まれた失効情報・ステープルされたレスポンスの間を裁定する優先順位規則、日本の認定CAエコシステムのために追加された LDAP-CRL トランスポート、鮮度／陳腐化のウィンドウ、オフラインの誠実性の規律、そして検証器が最終的に報告するクローズドな RevocationOutcome の語彙である。

失効評価は、no_std で I/O を行わない検証カーネルの内部に完全に存在する。計算の全体は crates/pverify-core/src/revocation/（mod.rs がオーケストレーション、crl.rs が CRL のパースと検証、ocsp.rs が OCSP 処理、indirect.rs が間接CRL検出）にある。カーネルはそれ自身ではネットワーク I/O を一切行わない。カーネルが消費するバイト列は RevocationFetcher トレイト（crates/pverify-core/src/traits.rs）経由で到着し、その具体的な実装は CLI のオンライン（ureq）・オフライン・from-bundle のフェッチャ（crates/pverify-cli/src/modes/）である。この分離は、失効に即して言い直した §V/§VI の境界である。すなわち、カーネルはどの URI が取得に値するか、そして返却されたバイト列をどのように解釈するかを決定し、ホストはそれらをどのように取得するかを決定する。全体アーキテクチャについては第3章を、ここで失効検証されるチェーンのステップを生成するパス検証については第9章を参照されたい。

全体を貫く統治原則は、憲章 §I「断定回避」である。すなわち、あらゆる失効結果は検証器が観測した事実である — good on CRL、revoked on OCSP、no CRL pointer、responder unreachable、not checked because offline。状態を確定できない場合、検証器は合格や失敗を捏造するのではなく、精確なサブインディケーションを伴って INDETERMINATE に縮退する。

11.1 パイプラインにおける失効検証の位置づけ

失効検証は、証明書パスが構築されチェーン内部の署名が検証された後に適用され、かつ各オブジェクトについてそのオブジェクト自身の検証基準時刻（VRT — 第12章）において適用される。署名者チェーンは apply_revocations（crates/pverify-core/src/verify.rs:2075）を介して失効検証され、各タイムスタンプの TSA チェーンは apply_tsa_chain_revocation_for_token（verify.rs:1552）を介して失効検証される。後者はブランチ 033 で導入され、TSA証明書の失効検証を全形式にわたり一貫させたものである。両エントリポイントは単一の失効オーケストレータ check_revocation_ctx（crates/pverify-core/src/revocation/mod.rs:184）に収束する。

apply_revocations はチェーンの非アンカーのステップを反復する（verify.rs:2111）— トラストアンカーそのものはア・プリオリに信頼されるため決して失効検証されない — そして各子証明書について RevocationContext（revocation/mod.rs:76）を構築する。このコンテキストは、親CAの SPKI と主体者DN、フェッチャ、検証時刻（オブジェクトごとのVRT）、トラストアンカー、OCSPレスポンダ／発行者の参照に用いる証明書プール、埋め込みの OCSP／CRL 情報、そして検証モードを保持する。

apply_revocations の2つの細部は、監査者にとって重要である。

• 埋め込み OCSP レスポンスはリーフのみが対象である。 埋め込みの ocspVals を受け取るのはステップインデックス0（署名者または TSA のリーフ）のみであり、中間証明書には空の埋め込みOCSPリストが渡される（verify.rs:2126）。これは、ステープルされた OCSP レスポンスが特定のリーフ＋発行者のペアに CertID で束縛されているためである。
• 埋め込み CRL はすべてのステップを対象とする。 OCSP と異なり、埋め込みの CRLValues エントリはパス上の任意の証明書に適用されうるため、埋め込みCRLのスライス全体が各ステップのコンテキストへ織り込まれる（verify.rs:2142）。

11.2 優先順位チャネル: CDP優先・OCSPフォールバック・埋め込みは不定時のみ

pverify は、厳格で監査可能な順序で、最大3つの失効情報のソースを参照する。その規約は、確定的な事実を最初に生み出したチャネルが勝つというものであり、後続のチャネルは先行チャネルが不定であった場合にのみ参照される。この順序付けが、バイト単位の同一性の不変条件（憲章 §II）を保つものである。すなわち、CDP の CRL チャネルが成功した署名は、埋め込み情報の有無に関わらず、まったく同一のレポートを生成する。

check_revocation_ctx（revocation/mod.rs:184）はこのはしごを実装する。

1. CDP／直接CRL のパイプライン（run_cdp_pipeline、revocation/mod.rs:284）。証明書に記載された CRL 配布点が分類され、取得可能であれば取得・消費される。結果が確定的 — GoodOnCrl または RevokedOnCrl — であれば、それはそのまま返却され、それ以降のチャネルは参照されない（revocation/mod.rs:208）。

2. 埋め込み CRL（try_embedded_crls、revocation/mod.rs:252）。CDP の結果が Indeterminate* の CRL バリアントのいずれかである場合にのみ到達する。各署名内CRL（CAdES/PAdES の revocation-values.crlVals、XAdES の RevocationValues/CRLValues）は、取得されたものと同じ consume_crl 検証 — 発行者DNのリンク、間接CRLの拒否、署名検証、鮮度ウィンドウ、シリアル検索 — を通る。GoodOnCrl／RevokedOnCrl を生む最初の埋め込みCRLが勝つ（revocation/mod.rs:274）。適用されないCRL（発行者が異なる、陳腐化している、間接である）はスキップされ、後続の埋め込みCRLがなお一致しうるようにする。これは LT レベルの署名にそのパスをオフラインで検証させる 019-xades-bt-blt の機構である。

3. OCSP パイプライン（run_ocsp_pipeline、revocation/mod.rs:620）。CDP チャネルが不定であり、埋め込みCRLが判定を生まず、かつリーフが OCSP 情報（AIA の id-ad-ocsp URI または埋め込みの ocspVals — revocation/mod.rs:228）を持つ場合にのみ到達する。OCSP パイプライン内のソース順序も再び優先順位付けされており、埋め込みの ocspVals が任意の AIA 取得より先に試される（revocation/mod.rs:637）。

フォールスルーのトリガーは明示的である。すなわち、CDP の結果が IndeterminateNoCrl、IndeterminateStaleCrl、IndeterminateIndirectCrl、IndeterminateUnsupportedProtocol、またはレガシーの IndeterminateOcspOnly（revocation/mod.rs:199）のいずれかでなければならない。確定的なCRL結果はいずれもはしごの残りをショートサーキットする。