NextPDF Connect で PAdES デジタル署名を適用する(Pro)
NextPDF Connect で PDF に PAdES ベースラインのデジタル署名を適用します。ツール名は sign_pdf で、Pro ツールプロバイダーに対して再検証済みです。このプロバイダーは new SignPdfTool() を登録し、そのプロトコル名は sign_pdf です。sign_pdf は Pro ティアのツールです。 サーバーは起動時に class_exists() でプローブし、Pro パッケージがインストールされている場合にのみ登録します。
デフォルトでは、このツールは PAdES B-B を生成します。PAdES B-T(B-B に 1 つの RFC 3161 signature-time-stamp を追加したもの)を生成できるのは、ホストがツールにタイムスタンププロバイダーを組み込んでいる場合に限られます。リクエストから TSA を指定することはできません。長期保存レベル(B-LT、B-LTA)とその検証材料(DSS、VRI、LTV)は、このツールの一部ではなく、ここでは対象外です。
U-1 の注意点。 NextPDF は、ETSI EN 319 142-1 PAdES B-T について独立した認証を受けているとは主張しません。EN 319 142-1 は検証コーパスに含まれていません。B-T の
signature-time-stamp要件は、 ETSI EN 319 122-1 §5.3(EN 319 142-1/-2 が参照によって取り込む CAdES 基盤)、ならびに RFC 3161、RFC 5652、RFC 5816、ISO 32000-2 §12.8 に照らして検証されます。B-T プロファイルのサポートは、適合性や法的有効性の認証ではありません。その判断は独立したバリデーターが行います。
インストール
「インストール」という見出しのセクションcomposer require nextpdf/servercomposer require nextpdf/proトランスポートをバインドします。diagnostic.capabilities で sign_pdf が存在することを確認します。B-T の場合、ホストはタイムスタンププロバイダーを指定してツールを構築する必要があります。プロバイダーがない場合、pades_b_t: true のリクエストは、暗黙的にダウングレードされず、型付きエラーで失敗します。
概念的な概要
「概念的な概要」という見出しのセクションsign_pdf は、署名値プレースホルダーを除外し、ファイル全体のバイトレンジダイジェストを計算します(ISO 32000-2 §12.8.1)。続いて、DER エンコードされた CMS SignedData を署名ディクショナリの Contents に書き込みます(ISO 32000-2 §12.8.1)。サポートされるアルゴリズム:RSA-SHA256(デフォルト)、RSA + SHA-3(256/384/512)、Ed25519。エンドツーエンドで機密性が確保されないトランスポートでは、オプションの AES-GCM エンベロープで受信する private_key ペイロードをラップできます。
B-T へのアップグレード。 pades_b_t: true かつ ホストが組み込んだタイムスタンププロバイダーがある場合、署名は PAdES B-T へアップグレードされます。バイトレンジハッシュが TSA へ送信され、TimeStampToken が埋め込まれます(ISO 32000-2 §12.8.5)。B-T は B-B に、CMS SignerInfo の署名なし属性として保持される 1 つの RFC 3161 signature-time-stamp を追加しただけのものです(RFC 5652 §5.3)。署名なし属性は署名の対象外であるため、B-B の署名済みダイジェストとその有効性は変わりません(RFC 5652 §5.3)。属性値は SignatureTimeStampToken です(ETSI EN 319 122-1 §5.3)。B-T は DSS ディクショナリ、VRI、検証材料、アーカイブタイムスタンプループのいずれも追加しません。これらは B-LT/B-LTA の Enterprise 差分であり、このツールの対象外です。
U-1 の注意点(B-T の主張箇所で再掲)。 ここでの B-T のサポートは EN 319 142-1 の適合性や法的有効性の認証ではありません。独立したバリデーターが判断します。EN 319 142-1 は検証コーパスに含まれていません。B-T は ETSI EN 319 122-1 §5.3、RFC 3161、RFC 5652、RFC 5816、ならびに ISO 32000-2 §12.8 に基づいています。
以下は、ツールのフローです(ホストでゲートされた TSA の接続点(リクエストから TSA を指定できない)と、フェイルクローズな B-T 分岐(暗黙のダウングレードは決して行わない)を含みます)。
API サーフェス
「API サーフェス」という見出しのセクション| ツール | ティア | 役割 | リスクティア |
|---|---|---|---|
create_pdf、add_text | Core | コンテンツの構築 | Safe / Caution |
sign_pdf | Pro | PAdES B-B(またはホストでゲートされた B-T)を適用 | Approval Required |
output_pdf | Core | PDF をレンダリングして返す | Approval Required / Review(base64) |
ツール名はレジストリのプロトコル名です。ツールカタログ が正式なカタログです。利用可能なツールはインストール済みティアによって異なり、長期保存レベルのツールは Pro には存在しません。
コードサンプル — クイックスタート
「コードサンプル — クイックスタート」という見出しのセクションcreate_pdf→add_textでコンテンツを構築します。certificate(PEM)、private_key(PKCS#8 PEM)、および任意のsigner_name、reason、algorithmを指定してsign_pdfを呼び出します。B-B の場合は、pades_b_tを省略します(またはfalseに設定します)。output_pdf。
このツールは次の結果エンベロープを返します。
{ "pdf": "<base64 of the signed PDF>", "signature_count": 1, "is_complete": true, "algorithm": "RSA_SHA256", "oid": "<algorithm OID>", "digest": "<digest algorithm>", "level": "PAdES-B-B", "timestamped": false}ホストでゲートされた B-T 署名の場合は、pades_b_t: true を送信します。level は "PAdES-B-T" になり、timestamped は true になります。
コードサンプル — 本番
「コードサンプル — 本番」という見出しのセクション署名は 最後 のコンテンツ操作として行います。sign_pdf の後に add_text/add_image を行うと、署名が無効になります。機密性が確保されないトランスポートでは、private_key を AES-GCM の transport_encryption エンベロープでラップします(12 バイトのノンス、16/24/32 バイトの鍵)。結果の level が、リクエストした内容と一致することを確認します。プロバイダーのないツールに対する pades_b_t: true のリクエストは、明示的に失敗します。そのエラーを処理し、暗黙的に B-B として再試行しないでください。
エッジケースと落とし穴
「エッジケースと落とし穴」という見出しのセクション- 証明書と鍵の不一致。 明確なエラーとして拒否されます。秘密鍵は証明書の公開鍵と一致している必要があります。
- 不正な PEM / 期限切れの証明書。 拒否されます。デフォルトでは、このツールは解析不能または期限切れの証明書で署名しません。
- 署名後のコンテンツ追加。 拒否されます。署名は最後に行ってください。
- B-T を要求、プロバイダーなし。 型付きエラーになります。署名は生成されず、暗黙的に B-B へダウングレードされることもありません。
- 自己署名証明書。 署名は適用されますが、リーダーには信頼が不明と表示されます。これは想定どおりであり、ツールの不具合ではありません。
- Pro が存在しない。 Core のみの場合、
sign_pdfは登録されません。
パフォーマンス
「パフォーマンス」という見出しのセクション署名により CMS の構築が加わり、B-T の場合はさらに 1 回の TSA ラウンドトリップが加わります。バジェットはこれを見込んでいます。プロファイルは semantic です。RFC 3161 トークンは本質的に再現不可能であり、§12.8.1 のバイトレンジダイジェストは署名値を除外するため、AST と署名メタデータの比較だけが妥当な評価方法です。
セキュリティに関する注意
「セキュリティに関する注意」という見出しのセクション署名は、署名鍵に基づく完全性と認証を提供します。署名はそれ自体で文書を「セキュア」や「法的に有効」にするものではなく、否認防止を保証するものでもありません。それらは証明書、そのトラストアンカー、鍵の保管、検証者のポリシーに依存し、いずれもこのツールの範囲外です。鍵ペイロードの暗号化(AES-GCM エンベロープ)は、転送中の機密性を保護するものであり、完全性を保護するものではありません。秘密鍵はシークレットとして扱い、機密性が確保されないチャネルでは transport-encryption エンベロープを優先してください。
| 記述 | 仕様 | 条項 | reference_id |
|---|---|---|---|
| ファイルを対象とし、署名値を除外するバイトレンジダイジェスト | ISO 32000-2 | §12.8.1 | |
DER エンコードされた CMS SignedData を保持する Contents | ISO 32000-2 | §12.8.1 | |
タイムスタンプ時に TSA へ送られ、Contents に配置されるバイトレンジハッシュとトークン | ISO 32000-2 | §12.8.5 | |
| SignerInfo 上の署名なし属性である B-T のタイムスタンプ | RFC 5652 | §5.3 | |
| B-B の署名済み digest/validity. を変更しない署名なし属性 | RFC 5652 | §5.3 | |
| SignatureTimeStampToken である signature-time-stamp の値 | ETSI EN 319 122-1 | §5.3 |
NextPDF は署名構造を生成します。生成された署名が適合的であることや法的に有効であることを主張するものではありません。判断は独立したバリデーターが行います。B-LT/B-LTA は、このツールでは生成されません。
商用コンテキスト
「商用コンテキスト」という見出しのセクションsign_pdf は Pro ティアのツールで、サーバー起動時に Pro パッケージが解決されたときにのみ登録されます。PAdES の長期保存レベル(B-LT、B-LTA)とその検証材料(DSS、VRI、LTV)は Enterprise 限定 であり、このツールやこのレシピでは公開されません。
データレジデンシーと PII の緩和策
「データレジデンシーと PII の緩和策」という見出しのセクション証明書と秘密鍵はリクエストを経由します。エンドツーエンドで機密性が確保されないチャネルでは、AES-GCM の transport_encryption エンベロープを使用してください。署名済み PDF と署名者の識別情報(signer_name、reason)は文書コンテンツであるため、データレジデンシーの境界内に保持してください。デプロイメントレベルのレジデンシーは、インテグレーターの責任です。
安全なテレメトリとログのスクラビング
「安全なテレメトリとログのスクラビング」という見出しのセクションprivate_key ペイロード、AES-GCM の key/nonce、確認トークンは、決してログに記録しないでください。記録するのは、アルゴリズム、得られた level、signature_count であり、鍵素材ではありません。このツールは、結果に鍵のバイト列を出力しません。
脅威モデル
「脅威モデル」という見出しのセクション考慮した脅威:転送中の鍵の漏えい(AES-GCM エンベロープと、ホストが注入しリクエストでは構成不可能な TSA プロバイダーによって緩和)、MCP 呼び出し元がタイムスタンプを任意のエンドポイントへ向ける行為(防止済み。プロバイダーはホストが注入し、リクエストでは構成不可能)、署名後の改ざん(バイトレンジダイジェストが変更を検出)。脅威モデルは、考慮した脅威と緩和策を文書化するものであり、脆弱性が存在しないことを主張するものではありません。
FIPS モードの動作
「FIPS モードの動作」という見出しのセクションアルゴリズムの選択(RSA-SHA256、RSA + SHA-3、Ed25519)はリクエスト駆動です。暗号プリミティブはホストの OpenSSL が提供します。FIPS 制約のあるデプロイメントでは、ポリシーレイヤーでアルゴリズムを制限し、ホストの検証済みモジュールに依存してください。このツール自体は、FIPS 検証を主張しません。
トランスポートの利用可否
「トランスポートの利用可否」という見出しのセクション| トランスポート | 利用可否 | 備考 |
|---|---|---|
| MCP(stdio) | あり(Pro) | stdio では AES-GCM の鍵エンベロープを使用。 |
| REST | あり(Pro) | TLS に鍵エンベロープを併用することを推奨。 |
| gRPC | あり(Pro) | TLS に鍵エンベロープを併用することを推奨。 |
HITL リスクティア
「HITL リスクティア」という見出しのセクションsign_pdf は Approval Required です(破壊的かつ不可逆な操作であり、ツールは破壊的ヒントを通知します)。確認ゲートは、すべての Approval Required ツールと同様に適用されます。ファイルへの output_pdf も Approval Required です。base64 モードは Review です(HITL リスクティア)。
確認ゲートの JSON エンベロープ
「確認ゲートの JSON エンベロープ」という見出しのセクション有効なトークンなしで sign_pdf を呼び出すと、チャレンジエンベロープが返されます。
{ "allowed": false, "challenge": "⚠️ CONFIRMATION REQUIRED\n\nOperation: sign_pdf\nDescription: <tool description>\n\nTo proceed, call sign_pdf again with parameter _confirmation_token: \"confirm_<single-use-hex>\"\nExpires in 300 seconds.", "token": "confirm_<single-use-hex>"}_confirmation_token にそのトークンを設定して再度呼び出すと → { "allowed": true } が返ります。完全なフロー:output-approval。