署名検証: AdES / PAdES の暗号検証側

概要

NextPDF Enterprise はデジタル署名を暗号的に検証します。検証側は PDF から CMS SignedData または RFC 3161 タイムスタンプトークンを読み取り、ダイジェストを再計算し、署名を検査し、各署名を署名証明書に結び付けます。そのうえで、証明書ポリシー処理を含む証明書チェーンを、呼び出し側が提供するトラストアンカーストアに対して検証します。このページでは挙動レベルで、何が検証され、何がフェイルクローズで拒否され、どのアルゴリズムがサポートされ、信頼境界がどこにあるかを説明します。

これは Validation とは別のものです。Validation は読み取り専用の構造的ポリシーチェックを実行し、暗号処理は意図的に一切行いません。また、これは Signature producer に対する検証側でもあります。Signature producer は PAdES B-LT / B-LTA 構造を書き込みます。

インストール

composer require nextpdf/enterprise:^3

概念の概要

検証はエビデンスベースかつフェイルクローズです。肯定的に確立できないチェックは、肯定的な結果を生みません。以下の各要素が組み合わさり、ValidationReport が保持する単一の結果になります。

CMS / タイムスタンプトークンの暗号検証。 自己完結型の厳格な確定長 DER スタックが、CMS SignedData と RFC 3161 タイムスタンプトークンを解析します。トークンが受理されるのは、ちょうど 1 つの SignerInfo を持ち、その署名属性が厳格に解析でき、署名者証明書が解決され、message-digest 属性が再計算したダイジェストと一致し、必須の署名証明書（ESS signing-certificate-v2）バインディングが成立し、かつ再タグ付けした署名属性に対して SignerInfo 署名が検証された場合のみです。このダイジェスト照合の規則は、RFC 5652 §5.6 / §5.4 の検証モデルです。受信者がコンテンツのメッセージダイジェストを再計算し、その値が messageDigest 署名属性と等しい場合にのみ、署名は有効です。検証側は、生成側が提供したダイジェストを決して信頼しません。

genTime 時点での TSA 証明書検証。 タイムスタンプの genTime は、トークンが作成された UTC の時点です（RFC 3161 §2.4.2）。TSA 署名証明書は「現在」ではなく、その時点で検証されます。拡張鍵用途は単一かつクリティカルな id-kp-timeStamping でなければならず（RFC 3161 §2.3）、その有効期間、チェーン、トラストアンカーの由来、失効はすべて genTime を基準に評価されます。構造的には整っていても、構成済みのトラストアンカーに到達しないチェーンは、決して肯定的な結果を支えられません。

分離型 PAdES 基本ドキュメント署名。 専用の抽出器が、分離型ドキュメント署名に対して実際の AdES / PAdES 基本検証を実行します。署名対象のバイト範囲についてメッセージダイジェストが再計算されて比較され、署名が検証され、署名証明書バインディングが必須になります。これは、構造のみを確認する以前のフォールバックを置き換えるものです。タイムスタンプ検証器とドキュメント署名抽出器は単一の ESS issuer-and-serial 検証器を共有するため、証明書バインディングの解析で不整合が生じることはありません。

アーカイブ DocTimeStamp カバレッジチェーン。 validateArchivalTimestampChain() は、PDF のバイト範囲にわたる信頼された DocTimeStamp トークンのチェーンを、B-LTA アーカイブエビデンスとして検証します。各トークンのインプリントは、対象となる実際の ByteRange バイトに結び付けられ、チェーンは ETSI の厳格な順序付けに従います。さらに、すべてのトークンの TSA チェーンはトラストアンカーに裏付けられ、チェーンはファイルの end-of-file マーカーまでカバーしなければなりません。完全で、トラストアンカーに裏付けられ、EOF までカバーするチェーンに対してのみ、完全合格の結果に到達します。

証明書ポリシー処理（RFC 5280 §6.1.4）。 パス検証は完全な証明書ポリシー処理を適用します。ノード構造のポリシーツリー、anyPolicy フォールバックを伴うポリシーマッピング、および policyConstraints / inhibitAnyPolicy の畳み込みは、フェイルクローズなポリシー拡張 DER リーダーによって裏付けられます。パス処理の状態変数 explicit_policy と inhibit_anyPolicy（RFC 5280 §6.1.2）は、空でない valid-policy ツリーが必要かどうかを左右します。最終ステップで、valid-policy ツリーと user-initial-policy-set を交差させます（RFC 5280 §6.1.4）。必須ポリシーがなく anyPolicy が受理される場合、処理は制約なしになります。これがデフォルトであり、以前の挙動から変わりません。

サポートされるアルゴリズム

検証側は以下のアルゴリズム集合を受理し、それ以外のものに対してはフェイルクローズします。サポートされないアルゴリズムは検証拒否の理由であり、決して暗黙の合格にはなりません。

ファミリー	サポート状況	備考
RSA（PKCS#1 v1.5）	`rsaEncryption`（SHA-2 併用）と `sha*WithRSAEncryption` OID	受理
ECDSA	曲線 P-256、P-384、P-521	受理
RSASSA-PSS	—	サポート対象外 → フェイルクローズ
EdDSA	—	サポート対象外 → フェイルクローズ
SHA-3 ダイジェスト	—	サポート対象外 → フェイルクローズ
SHA-1	—	脆弱：SHA-1 で検証される基本署名は、合格ではなく暗号制約違反に格下げされます

API サーフェス

検証側は、公開エンジンおよび Core / Pki のコントラクトを通じて利用します。具体的なストラテジークラスは内部用です。

型	種別	役割
`AdESValidationEngine`	クラス	検証側のエントリーポイント：署名およびアーカイブチェーンの検証
`AdESValidationEngine::validateArchivalTimestampChain()`	メソッド	PDF のバイト範囲にわたる、信頼された DocTimeStamp カバレッジチェーンの検証
`ValidationReport`	結果	構造化された結果：全体ステータスとチェックごとの所見
`PathValidatorInterface`	インターフェース（`NextPDF\…\Pki`）	エンジンが依存する証明書パス検証の SPI
`PathValidationOptions`	値オブジェクト	ポリシー処理の制御：`requireExplicitPolicy`、`inhibitAnyPolicy`、`inhibitPolicyMapping`、`maxPolicyFanout`
`TrustAnchorStoreInterface`	インターフェース	チェーンの評価対象となる、呼び出し側提供の信頼されたアンカー集合

アーカイブチェーンメソッドのシグネチャは次のとおりです。

public function validateArchivalTimestampChain(
    string $pdfBytes,
    array $dssData = [],
    ?TrustAnchorStoreInterface $anchors = null,
): ValidationReport;

完全合格の結果に到達するのは、DocTimeStamp チェーンが完全に検証され、トラストアンカーに裏付けられ、ファイルの EOF マーカーまでカバーする場合のみです。

CertificateChainValidator::validate() は初期ポリシー集合（RFC 5280 の user-initial-policy-set）を受け取ります。デフォルトは anyPolicy、つまり制約なしなので、通常のチェーンは影響を受けません。明示的な集合を渡すか、requireExplicitPolicy を設定して、空でない valid-policy ツリーを要求してください。

コードサンプル — クイックスタート

use NextPDF\Enterprise\Security\Validation\AdESValidationEngine;

$report = $engine->validateArchivalTimestampChain($pdfBytes, [], $trustAnchors);

if ($report->isTotalPassed()) {
    // A complete, trust-anchored, EOF-covering DocTimeStamp chain.
}

コードサンプル — 本番

use NextPDF\Enterprise\Security\Validation\AdESValidationEngine;
use Psr\Log\LoggerInterface;

final readonly class ArchivalEvidenceCheck
{
    public function __construct(
        private AdESValidationEngine $engine,
        private LoggerInterface $logger,
    ) {}

    public function check(string $pdfBytes, TrustAnchorStoreInterface $anchors): bool
    {
        $report = $this->engine->validateArchivalTimestampChain($pdfBytes, [], $anchors);

        foreach ($report->findings as $finding) {
            $this->logger->info('archival.finding', [
                'check'  => $finding->checkId,
                'status' => $finding->status->value,
            ]);
        }

        // A positive result proves byte-range coverage by a trusted timestamp
        // chain — it is one input to your decision, not a legal conclusion.
        return $report->isTotalPassed();
    }
}

挙動の変更とアップグレードに関する注意

検証側は、構造的 / 時間的な受理から、完全な暗号検証へ移行しました。以前の、より緩やかな挙動に依存している場合は、これらの変更を確認してください。

認識可能だが検証不能なタイムスタンプはフェイルクローズ。 以前は構造的・時間的な根拠で合格していた DocTimeStamp またはアーカイブトークンは、現在では完全な暗号検証、つまり署名、message-digest、署名証明書バインディングを要求します。検証されないトークンは、もはや肯定的な存在証明を生まず、不確定または失敗の結果にマッピングされます。
SHA-1 基本署名は格下げされ、合格しません。 検証はされても SHA-1 を使用する基本ドキュメント署名は、完全合格ではなく暗号制約違反として報告されます。
RFC 5280 §6.1.4 証明書ポリシー処理が強制されます。 explicit_policy がゼロに達し、valid-policy ツリーが空になるチェーンは、現在では失敗します。チェーン内部の policyConstraints requireExplicitPolicy がそれを引き起こす場合も含みます。デフォルトの制約なしチェーン（必須ポリシーなし、anyPolicy 受理）は影響を受けません。
コンストラクターのシグネチャ変更（BC ブレーク）。 AdESValidationEngine::__construct() は、その $chainValidator パラメーターを Pki\PathValidatorInterface SPI として型付けし、遅延して Pki\CertificateChainValidator::withDefaults() にデフォルト設定するようになりました。以前は具体的な Ltv\CertificateChainValidator でした。具体的な LTV 検証器を注入していた呼び出し側は、代わりに Pki SPI 実装を注入する必要があります。Pki 検証器は同じ構造的パスエンジンをラップし、名前制約とポリシー処理を追加します。準拠したデフォルト入力に対しては no-op です。

エッジケースと落とし穴

サポート対象外のアルゴリズム ≠ 結論不能。 RSASSA-PSS、EdDSA、SHA-3 はフェイルクローズで拒否され、保留されません。署名者がこれらを使用している場合、この検証側はそれらに対して肯定的な結果を返しません。
信頼はアンカー相対です。 検証は常に、提供されたトラストアンカーストアに対して相対的です。空または誤ったアンカー集合は、暗号的な正しさにかかわらず、信頼されないという結果を生みます。
genTime であって現在ではない。 TSA 証明書は、トークンの genTime で判定されます。すでに失効した TSA 証明書でも、有効だった間に作成されたトークンを依然として支えられます。genTime 時点でまだ有効でない証明書は支えられません。
EOF カバレッジ。 アーカイブチェーンは、ドキュメントをその EOF マーカーまでカバーしなければなりません。ファイルの先頭部分のみをカバーするタイムスタンプは、ドキュメント全体のカバレッジを確立しません。
失効が証明されていないことは Good ではありません。 Valid という判定には、決定的に失効していないステータスが必要です。OCSP と CRL の両方が Unknown または Unavailable を返した場合、暗号的に健全でチェーンが有効でトラストアンカーに裏付けられた署名であっても、Indeterminate に解決されます。署名者証明書に対して埋め込みの OCSP/CRL Good 素材を提供し、Valid に到達させてください。

パフォーマンス

検証は、提供された PDF バイトと埋め込みの検証素材に対してインプロセスで行われます。コストはチェーン長とタイムスタンプの数に応じてスケールします。検証中にネットワークのラウンドトリップは行われません。失効情報と信頼素材は、呼び出し側が提供するもの、またはドキュメントに埋め込まれているものから取得されます。検証は決定的です。同じ入力と同じトラストアンカーは、同じレポートを生成します。

セキュリティに関する注意

フェイルクローズがデフォルトです。 すべての受理ステップは、肯定的に検証できない素材の受理を拒否します。これにより、エンジンが確立していない有効性をドキュメントが主張することを防ぎます。
タイムスタンプ後の追記は EOF カバレッジによって無効化されます。 各アーカイブタイムスタンプのインプリントは実際の ByteRange バイトに結び付けられ、チェーンは EOF に到達しなければなりません。そのため、タイムスタンプの後に追記されたコンテンツはその対象にならず、証拠的価値を獲得しません。
入力は敵対的なものとして扱います。 信頼できないソースからの PDF バイト、埋め込み CMS、タイムスタンプトークンは、不正な形式や不定長エンコーディングを拒否する厳格な確定長 DER リーダーによって解析されます。

データレジデンシーと PII の緩和策

検証はインプロセスかつローカルで行われ、ネットワーク I/O はありません。証明書と署名にはサブジェクトの識別情報が含まれます。レポートおよび抽出した証明書データには、ご自身の保持・最小化の管理策を適用してください。

安全なテレメトリとログのスクラビング

所見にはチェック識別子とステータスが含まれます。一部の診断情報は、証明書のサブジェクト名やシリアル番号を出力することがあります。ログを共有シンクへ転送する前に、それらのフィールドをスクラブまたは秘匿してください。

スコープの境界

肯定的な結果が過大に解釈されないよう、以下をユーザー向け出力に明記してください。

validateArchivalTimestampChain() はバイト範囲のカバレッジを証明するものであり、xref の到達可能性ではありません。 これは、信頼されたタイムスタンプチェーンがドキュメントのバイト範囲を EOF まで暗号的にカバーすることを確立します。xref レベルや startxref のオブジェクト到達可能性は分析しません。それは設計上スコープ外です。タイムスタンプ後の追記攻撃は、オブジェクトグラフの分析ではなく、EOF カバレッジ規則とトラストアンカーの組み合わせによって無効化されます。
設計上スコープ外。 Evidence Records（RFC 4998 / RFC 6283）、RSASSA-PSS、EdDSA、SHA-3 タイムスタンプトークンの検証、信頼リスト（TSL）および適格 TSA との統合、オンラインの TSA 失効情報取得は、この検証側では提供されません。失効情報は、検証側がすでに利用できる素材から評価されます。

準拠

挙動	参照	ステータス
署名値 / タイムスタンプトークンの DER エンコード済みデータの格納先は `/Contents`	ISO 32000-2 §12.8.1	解析・検証済み
ドキュメントタイムスタンプ辞書	ISO 32000-2 §12.8.5	アーカイブチェーン用に読み取り
受信者によるコンテンツダイジェストの再計算、および messageDigest 属性との一致	RFC 5652 §5.6 / §5.4	強制
TSA 証明書は単一かつクリティカルな `id-kp-timeStamping` EKU を持つ	RFC 3161 §2.3	genTime 時点でチェック
genTime は UTC の作成時点	RFC 3161 §2.4.2	検証の基準時刻として使用
ポリシー処理の状態変数（`explicit_policy`、`inhibit_anyPolicy`）	RFC 5280 §6.1.2	処理済み
最終処理における valid-policy ツリーと user-initial-policy-set の交差	RFC 5280 §6.1.4	強制
長期署名のための DSS エントリーとドキュメントタイムスタンプ	ETSI EN 319 142-2 §5.5	アーカイブエビデンスとして検証

すべての条項は言い換えです。NextPDF は規範テキストを複製しません。権威ある文言については公開された規格を参照してください。NextPDF は AdES / PAdES の認証主張を一切行いません。 検証側は引用された仕様が記述する暗号チェックを実装しますが、認証された検証サービスではなく、第三者による証明を生成しません。

FIPS モードの挙動

Enterprise FIPS プロファイルが有効な場合、その制約は検証側が受理するダイジェストアルゴリズムと署名アルゴリズムに適用されます。検証ロジック、すなわちダイジェスト再計算、署名検査、証明書バインディング、パス検証は変更されません。

脅威モデル

資産	攻撃者	リスク	緩和策
タイムスタンプトークン	偽造または改ざんされたトークン	偽の存在証明	完全な暗号検証。検証不能なものはすべてフェイルクローズ
TSA 証明書	信頼できない発行者	検証側が主張すべきでない見かけ上の信頼	呼び出し側提供アンカーに対する genTime 時点のチェーン検証。信頼されないチェーンは決して合格しない
ドキュメントバイト	タイムスタンプ後の追記	コンテンツがカバレッジなしでタイムスタンプの重みを獲得すること	インプリントと実際の ByteRange バイトの結び付け + EOF カバレッジ規則
脆弱なアルゴリズム	SHA-1 / サポート対象外スキームへのダウングレード	脆弱な署名が有効として読み取られること	SHA-1 は格下げ。RSASSA-PSS / EdDSA / SHA-3 はフェイルクローズ

エディションゲート

この検証側は Enterprise の機能であり、nextpdf/enterprise パッケージに同梱されます。NextPDF Core は署名の存在を検出し、B-B / B-T 署名を生成しますが、この暗号検証側は提供しません。ライセンスを取得してください。

ライセンス機能フラグ

検証側は Enterprise エディション（license_feature_flag: enterprise）によってゲートされます。これは Core と Pki のコントラクトを通じて解決されます。エディションのアップグレードで公開 API は変わりません。

挙動コントラクト

CMS またはタイムスタンプトークンが受理されるのは、ちょうど 1 つの SignerInfo、厳格に解析された署名属性、解決された署名者証明書、一致する message-digest、必須の署名証明書バインディング、および検証される SignerInfo 署名がそろっている場合のみです。
TSA 証明書は、トークンの genTime で検証されます。対象は、単一かつクリティカルな id-kp-timeStamping EKU、有効期間、トラストアンカーに裏付けられたチェーン、失効です。
Valid という判定には、さらに決定的に失効していないステータスが必要です。少なくとも 1 つの権威ある Good（検証済みで良好な OCSP レスポンス、または当該シリアルを失効リスト外に置く新鮮な CRL）です。単に失効が証明されていないだけで、OCSP と CRL の両方が Unknown または Unavailable であるステータスは、Indeterminate に解決され、決して Valid にはなりません（ETSI EN 319 102-1: 失効ステータス利用不可 → INDETERMINATE）。CRL フォールバックパスはリストの新鮮さのみを証明し、シリアルごとの非失効状態は証明しないため、Good な OCSP を伴わない CRL のみのチェーンは通常 Indeterminate です。
validateArchivalTimestampChain() が完全合格の結果に到達するのは、完全で、トラストアンカーに裏付けられ、EOF までカバーする DocTimeStamp チェーンに対してのみです。これはバイト範囲のカバレッジを証明するものであり、xref の到達可能性ではありません。
証明書ポリシー処理は RFC 5280 §6.1.4 に従います。デフォルトの制約なしチェーンは影響を受けません。
サポートされるアルゴリズムは RSA（PKCS#1 v1.5、SHA-2 併用）と ECDSA（P-256/384/521）です。RSASSA-PSS、EdDSA、SHA-3 はフェイルクローズ。SHA-1 は格下げされます。

NDA スキャン状況

この公開ページは、外部から観測可能な検証側の挙動のみを説明します。公開エンジン、Pki / トラストアンカーのコントラクト、および validateArchivalTimestampChain() メソッドを、サポート対象サーフェスとして示します。具体的な DER、CMS、ポリシープロセッサー、パス検証器の内部は、NDA の下にあるゲート付きの詳細リファレンスに含まれます。

Core フォールバック

NextPDF Core は署名の存在を検出し、B-B / B-T 署名を生成しますが、CMS やタイムスタンプトークンを暗号的に検証したり、アーカイブチェーンを検証したり、RFC 5280 §6.1.4 ポリシー処理を実行したりはしません。Core のみのデプロイには同等の検証側はありません。Security / Signing (Core) を参照してください。

Pro フォールバック

NextPDF Pro は署名ストラテジーと e-invoice 処理を追加しますが、この暗号検証側は提供しません。アーカイブチェーン検証と証明書ポリシー処理は、nextpdf/enterprise のみに同梱されます。

Enterprise 境界に関する注意

検証側は挙動レベルで説明されています。厳格な DER スタック、CMS パーサー、ポリシープロセッサー、パス検証器の内部は、公開サーフェスのスコープ外であり、ここでは再現しません。

デプロイ境界

検証は、呼び出し側が提供する、またはドキュメントに埋め込まれているトラストアンカーストアと失効素材に依存します。NextPDF Enterprise はその素材を評価します。信頼リスト、TSA、失効サービスを運用することはありません。アンカーの選択と、埋め込まれた失効素材の新鮮さは、運用者が責任を負います。

法令順守の境界

このページは export_control_class: legal-review-required とマークされており、暗号検証に関するものです。publish フラグを設定する前に、法務の承認が必要です。肯定的な検証結果は、ドキュメントの署名とタイムスタンプに関する暗号的な言明です。法的見解、eIDAS 適格性の判定、または認証ではありません。NextPDF は AdES / PAdES の認証主張を一切行いません。 規制上の義務については、ご自身のコンプライアンスおよび法務のアドバイザーにご相談ください。