仕組み
pverify は公的な PKI（GPKI／JPKI／LGPKI、台湾 GRCA、韓国 GPKI、シンガポール NCA、EU eIDAS、米国 FPKI など）の電子署名を
検証するためのツールです。PDF（PAdES）、CMS（CAdES）、
XML（XAdES）、JSON（JAdES、JWS）、これらを ZIP に
包んだ ASiC コンテナについて、署名・コンテンツ照合・信頼パス・
有効期間・失効状態を確認し、ETSI の判定区分（TOTAL_PASSED /
TOTAL_FAILED / INDETERMINATE）で結果を返します。
CAdES・PAdES・XAdES・JAdES はいずれも、基本署名（B-B／BES）に加え、署名タイムスタンプ付き（B-T）・
長期保存データ埋め込み（B-LT）・アーカイブタイムスタンプ（B-LTA）まで検証します。
署名アルゴリズムは RSA（PKCS#1 v1.5・RSA-PSS）、ECDSA（P-256／P-384）、
Ed25519、耐量子計算機暗号（PQC）の ML-DSA（FIPS 204）、および中国国家標準の SM2（SM3 ハッシュ使用、GM/T 0003-2012）に対応します。
Ed448 など未対応の方式は signature_algorithm_unsupported として
INDETERMINATE で返します。
参照した検証材料（再現性の土台）
検証結果には、判定が依拠した生バイトの一覧（validation_objects）が含まれます。
証明書・CRL・OCSP レスポンス・タイムスタンプトークン・署名対象コンテンツのそれぞれを、
内容の SHA-256 と、どこから来たか（署名内蔵／バンドル供給／オンライン取得／
信頼アンカ／入力供給）・どう使われたか（署名者／CA／信頼アンカ、失効確認対象、
各種タイムスタンプ）とともに列挙します。EU の eIDAS リファレンス実装 DSS の
「Diagnostic Data」に相当する出力で、同じ SHA-256 のバイト列を揃えれば
同じ判定を再現できます。
プライバシー
暗号検証はすべてお使いのブラウザ内（WebAssembly）で完結し、 署名・証明書・文書ファイルがサーバへ送信されることはありません。
例外は失効確認のための CRL／OCSP 取得です。検証時に 失効情報配布点の URL が
当サイトの中継（プロキシ）を経由します。これは配布点の多くが
http:// 配信かつ CORS 未許可で、ブラウザから直接取得できない
ためです。ldap:// 配信の CRL（後述）も同じ中継がサーバ側で取得します
（ブラウザは LDAP も生 TCP ソケットも扱えないため）。
中継を経由するのは失効情報を取得する URL だけで、
署名や文書そのものは送信されません。
耐量子計算機暗号（PQC）への対応
NIST が 2024 年に FIPS 204 として標準化した格子ベースの署名方式
ML-DSA（旧称 CRYSTALS-Dilithium）の 3 つのパラメータセット
（ML-DSA-44／65／87、NIST セキュリティカテゴリ 2／3／5）に対応します
（OID 2.16.840.1.101.3.4.3.17〜.19）。
PAdES／CAdES／XAdES のいずれの署名でも、証明書チェーンの各リンクや署名本体が
ML-DSA であればそのまま検証されます。検証も純 Rust 実装でブラウザ内（WASM）に完結します
（Web Crypto の SubtleCrypto は ML-DSA を未提供のため、内部実装で検証）。
実装は NIST ACVP の既知解テスト（KAT）と、公開されている PQC 多段チェーンの
経路検証（米連邦 PKI の PQC 相互運用ラボ FPKI BRAWL の ML-DSA-87 ルート、および
GlobalSign 公開の ML-DSA-87→65→44 三段チェーン）で確認しています。
これらは本番の信頼アンカではなく、ブラウザ版では pqc-interop-lab 区分で
実験収録しています。詳細は収録ルート一覧を参照してください。
失効確認（CRL / OCSP）
証明書が失効していないかは、まず CRL（証明書失効リスト）で確認し、確認できない場合は OCSP も試みます。中継が取得するのは、同梱ルートに対応する許可済みの配布元のみです （許可リスト方式）。自己署名のルート証明書は失効確認の対象外です。
電子署名法の認定認証事業者の一部（AOSign／帝国データバンク／TOiNX／DIACERT／
e-Probatio など）は CRL を ldap:// でのみ配布します。
ブラウザ自身は LDAP を扱えないため、当サイトの中継が匿名 LDAP（RFC 4511／4516、
ポート 389）で CRL を取得し、http(s) 配信と同じく Good／Revoked の
判定に進みます。ネイティブ CLI は中継を介さず直接 LDAP から取得します。
取得できなかった範囲は IndeterminateNoCrl（許可リスト外・配布元停止など）、
ネットワークを使わない検証では revocation_not_checked_offline、
ftp:// など pverify が取得手段を持たない方式は
IndeterminateUnsupportedProtocol として区別して報告します。
いずれも失効・エラーではなく「未確認」を意味します。
同梱ルート証明書（信頼の起点）
日本政府系 PKI（GPKI／JPKI／LGPKI）に加え、台湾（GRCA1/2/3）・韓国（GPKIRootCA1）・ シンガポール（NCA B1）・EU（eIDAS LOTL）・米国（FPKI）・Adobe AATL（政府系）の 信頼アンカ（ルート証明書）を同梱しているため、別途用意しなくても検証できます。 自前の自己署名証明書をファイルとして追加すれば、それも併用されます。 収録した認証局の出自（データソース・根拠 URL・取得日・fingerprint・鍵アルゴリズム）は 収録ルート一覧で確認できます。
検証時刻は既定で現在時刻（端末のタイムゾーン）です。過去時点の 有効性を確認したい場合に変更してください。入力時刻は併せて選択できるタイムゾーン （現地時間／JST／UTC）で解釈します。
機能諸元
pverify が検証できる署名形式・レベル・アルゴリズム・失効確認方式の一覧です。 未対応の項目はそのまま「未対応」と表示します。
署名形式とレベル
ここでの「レベル」は署名に含まれる構造（タイムスタンプ・失効情報・アーカイブ TS）から判定するもので、 JNSA デジタル署名検証ガイドライン第 1.1 版が各レベルに要求する Mandatory 項目すべてを満たすことを意味するものではありません。
| 形式 | 説明 | 対応レベル |
|---|---|---|
| CAdES | CMS／PKCS#7 署名（添付・分離） | BES ／ T（署名 TS）／ LT（長期保存データ）／ LTA（アーカイブ TS） |
| PAdES | PDF 署名。差分更新（incremental update）と /DocTimeStamp に対応 |
B ／ B-T ／ B-LT ／ B-LTA |
| XAdES | XML 署名。enveloped ＋ Exclusive C14N。分離（detached）型は ASiC コンテナ内で対応 | B-B ／ B-T ／ B-LT ／ B-LTA |
| JAdES | JSON Web Signature（JWS、RFC 7515）ベースの ETSI TS 119 182-1。JSON Serialization（general／flattened）の enveloping 形式。sigD による分離と JWS Compact Serialization は未対応 |
B-B ／ B-T ／ B-LT ／ B-LTA |
| ASiC | CAdES／XAdES 署名を包む ZIP コンテナ（ETSI EN 319 162）。中の署名を上記パイプラインで検証 | ASiC-S ／ ASiC-E |
署名・ハッシュアルゴリズム
| 種別 | 対応 | 備考 |
|---|---|---|
| RSA | PKCS#1 v1.5 ／ RSA-PSS | RSA-PSS は XAdES でも対応（MGF1・salt 長を解釈）。JAdES は JWS の RS256/384/512・PS256/384/512（RFC 7518）に相当 |
| ECDSA | P-256 ／ P-384 | JAdES は ES256・ES384。ES512（P-521）は未対応 |
| EdDSA | Ed25519（RFC 8410／8032 pure） | Ed448（1.3.101.113）は未対応。JAdES でも JWS の EdDSA（Ed25519）に対応 |
| ML-DSA（PQC） | ML-DSA-44 ／ 65 ／ 87（FIPS 204） | NIST セキュリティカテゴリ 2／3／5。OID …3.4.3.17〜.19 |
| SM2（中国標準） | SM2 with SM3（GM/T 0003-2012） | 中国国家標準。256-bit EC 曲線、SM3 ハッシュ（OID 1.2.156.10197.1.501）。台湾 GRCA・中国 CFCA 等の検証に使用 |
| ハッシュ | SHA-256 ／ SHA-384 ／ SHA-512 ／ SM3 | SHA-1 は受理し weak として表示（SM3 は SM2 署名の付随ハッシュとして使用） |
失効確認・実行環境
| 項目 | 対応 |
|---|---|
| 失効確認 | CRL（http(s) ／ ldap://、ブラウザ版は中継経由）・OCSP（RFC 6960）。取得不能時は IndeterminateNoCrl 等の未確認区分で報告 |
| パス検証 | RFC 5280 §6（名前制約・ポリシー処理）。GPKI／FPKI のブリッジ CA を辿る多段経路探索に対応 |
| 検証時刻 | 任意の時点（--at）を指定でき、過去時点の有効性を再現的に検証 |
| 実行環境 | ネイティブ CLI とブラウザ（WASM）で同一の検証コア・同一の判定結果。暗号は RustCrypto 系 pure Rust のみ（ネイティブ依存なし） |
サプライチェーン（CBOM・SBOM）
pverify は検証専用のツールであり、署名鍵を一切持ちません。 この性質を機械可読な形で公開するため、2 種類の部品表（BOM）を提供します。 内容はサプライチェーン・ビューアで 一覧表示できます（生の JSON も下記から取得できます）。
-
CBOM（暗号部品表）：
cbom.json ―
pverify が検証時に扱える暗号アルゴリズムの一覧（CycloneDX 1.6 形式）。
全項目が
cryptoFunctions: ["verify"]のみで署名機能は持ちません。 SHA-1 など弱いアルゴリズムはpverify:weak=trueとして明示し、 コードと CBOM の食い違いは CI で機械的に検出します。 -
SBOM（ソフトウェア部品表）：
sbom.json ―
ビルドに使用している依存クレートの一覧（
Cargo.lockからcargo cyclonedxで生成）。
リリース版では各成果物（バイナリ・ソース・WASM・CBOM・SBOM）に SLSA v1.0 の 来歴（provenance）を付与し、第三者が SHA-256 で照合できます。
詳細設計仕様書
pverify の検証ロジック・アーキテクチャ・標準準拠を章ごとに記した詳細設計仕様書を公開しています（全 18 章、各記述はソースコードに対応づけ）。HTML 版（日本語） ／ HTML 版（英語） で閲覧できます。
ソースコード
ネイティブ CLI とブラウザ版は同一の検証コアを共有しており、判定結果は同じです。 オープンソースとして整備中です。