コンテンツにスキップ

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 プロファイルのサポートは、適合性や法的有効性の認証ではありません。その判断は独立したバリデーターが行います。

Terminal window
composer require nextpdf/server
composer require nextpdf/pro

トランスポートをバインドします。diagnostic.capabilitiessign_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 分岐(暗黙のダウングレードは決して行わない)を含みます)。

Host-wired RFC 3161 TSAPro SignPdfToolNextPDF Connect serverHost-wired RFC 3161 TSAPro SignPdfToolNextPDF Connect serveralt[host wired a TSA provider][no provider wired]alt[pades_b_t == true]MCP callercreate_pdf then add_text — build content1sign_pdf — certificate, private_key, pades_b_t?2dispatch — Pro tool, class_exists-probed at boot3Byte-range digest, build CMS SignedData — B-B4byte-range hash — request-unconfigurable endpoint5TimeStampToken6Embed token in unsignedAttrs — B-T7Typed error — NOT downgraded to B-B8signed PDF — level B-B or B-T9output_pdf — Approval Required gate10result — pdf, level, timestamped11MCP caller
Diagram
ツールティア役割リスクティア
create_pdfadd_textCoreコンテンツの構築Safe / Caution
sign_pdfProPAdES B-B(またはホストでゲートされた B-T)を適用Approval Required
output_pdfCorePDF をレンダリングして返すApproval Required / Review(base64)

ツール名はレジストリのプロトコル名です。ツールカタログ が正式なカタログです。利用可能なツールはインストール済みティアによって異なり、長期保存レベルのツールは Pro には存在しません。

  1. create_pdfadd_text でコンテンツを構築します。
  2. certificate(PEM)、private_key(PKCS#8 PEM)、および任意の signer_namereasonalgorithm を指定して sign_pdf を呼び出します。B-B の場合は、pades_b_t を省略します(または false に設定します)。
  3. 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" になり、timestampedtrue になります。

署名は 最後 のコンテンツ操作として行います。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 を保持する ContentsISO 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 限定 であり、このツールやこのレシピでは公開されません。

証明書と秘密鍵はリクエストを経由します。エンドツーエンドで機密性が確保されないチャネルでは、AES-GCM の transport_encryption エンベロープを使用してください。署名済み PDF と署名者の識別情報(signer_namereason)は文書コンテンツであるため、データレジデンシーの境界内に保持してください。デプロイメントレベルのレジデンシーは、インテグレーターの責任です。

private_key ペイロード、AES-GCM の key/nonce、確認トークンは、決してログに記録しないでください。記録するのは、アルゴリズム、得られた levelsignature_count であり、鍵素材ではありません。このツールは、結果に鍵のバイト列を出力しません。

考慮した脅威:転送中の鍵の漏えい(AES-GCM エンベロープと、ホストが注入しリクエストでは構成不可能な TSA プロバイダーによって緩和)、MCP 呼び出し元がタイムスタンプを任意のエンドポイントへ向ける行為(防止済み。プロバイダーはホストが注入し、リクエストでは構成不可能)、署名後の改ざん(バイトレンジダイジェストが変更を検出)。脅威モデルは、考慮した脅威と緩和策を文書化するものであり、脆弱性が存在しないことを主張するものではありません。

アルゴリズムの選択(RSA-SHA256、RSA + SHA-3、Ed25519)はリクエスト駆動です。暗号プリミティブはホストの OpenSSL が提供します。FIPS 制約のあるデプロイメントでは、ポリシーレイヤーでアルゴリズムを制限し、ホストの検証済みモジュールに依存してください。このツール自体は、FIPS 検証を主張しません。

トランスポート利用可否備考
MCP(stdio)あり(Pro)stdio では AES-GCM の鍵エンベロープを使用。
RESTあり(Pro)TLS に鍵エンベロープを併用することを推奨。
gRPCあり(Pro)TLS に鍵エンベロープを併用することを推奨。

sign_pdf は Approval Required です(破壊的かつ不可逆な操作であり、ツールは破壊的ヒントを通知します)。確認ゲートは、すべての Approval Required ツールと同様に適用されます。ファイルへの output_pdf も Approval Required です。base64 モードは Review です(HITL リスクティア)。

有効なトークンなしで 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