標準の全体像

Spec Spec: ISO 32000-2 ISO 32000-2 Spec Spec: ETSI EN 319 142-1 ETSI EN 319 142-1 Spec Spec: RFC 3161 RFC 3161 Spec Spec: WCAG 2.2 WCAG 2.2 Evidence § Standard-backed Evidence: Standard-backed

概要

PDF エンジンが応えるのは、ひとつのドキュメントに対してではありません。応える相手は、異なる団体が作成し、互いに参照し合う小さな標準の連合体です。このページは、NextPDF が追跡するその連合体の地図です。同時に、ひとつの条項が「標準にはそう書かれている」から「エンジンがそのように振る舞い、テストがそれを証明している」へ至る道筋でもあります。

このページは、ある挙動をどのドキュメントが規定しているのかを把握し、NextPDF による解釈が擁護できるものかどうかを判断したい上級エンジニア向けです。

これが重要な理由

「PDF サポート」という主張は、ひとつの問いを覆い隠します。正確には、何をサポートしているのか、という問いです。中核となる構文は ISO 32000-2 が定めます。署名は ETSI を経由します。タイムスタンプは IETF のプロトコルです。エンジンがレンダリングする HTML と CSS は W3C の領域です。その下層の暗号は NIST です。出力のアクセシビリティは、再び W3C です。

ライブラリがこれらを区別のない一塊として扱うと、障害を筋道立てて考えられません。バリデーターが署名済みの請求書を拒否したとき、最初に立てるべき有用な問いは「PDF が壊れているのか」ではありません。「どの標準のどの条項が満たされず、それをどちらの側が引き起こしたのか」です。その問いを立てるには、各団体を名指しする地図と、条項がどのように挙動へ変わるのかについての誠実な説明が必要です。

要点

• NextPDF は 5 つの標準化団体を追跡しています。ISO はフォーマットを管轄します。ETSI は欧州の署名プロファイルを管轄します。IETF はワイヤープロトコル（タイムスタンプ、参照による暗号プリミティブ）を管轄します。W3C は HTML、CSS、およびアクセシビリティ基準を管轄します。NIST は承認された暗号アルゴリズムを管轄します。
• これらのドキュメントは単なるリストではなく、**経路（trail）**を形成します。つまり、ひとつの署名済み PDF 機能は ISO → ETSI → IETF → NIST をたどり、各層が次の層を規範的に参照します。
• 条項は、読まれただけで挙動になるわけではありません。挙動になるのは、言い換えて引用され、要件にマッピングされ、実装され、テストで固定されることによってです。その挙動を説明するページは、自らのエビデンスレベルとともに、そのことを明示します。
• ある条項が必須である場合、それには規範的キーワード（shall や must）が伴います。NextPDF はそれらのキーワードを契約として扱います。should は推奨事項であり、保証ではなく推奨としてそのまま文書化します。

NextPDF の取り組み方

一塊ではなく連合体

ISO 32000-2 が中心です。ISO 32000-2 は、適合ファイルとは何かを定義します。適合ファイルはドキュメントのすべての要件を満たさなければならない一方で、ドキュメントが明示的に求めていない機能は省略して構いません Spec Spec: ISO 32000-2, §6 ISO 32000-2 §6 。また、書き手に対する義務も定めています。すなわち、NextPDF がファイル内で作成または修正するものは、フォーマットに適合し、既存の要素との整合性を保たなければなりません Spec Spec: ISO 32000-2, §6 ISO 32000-2 §6 。このひとつの条項こそが、エンジンが構造的に整合しない増分更新の出力を拒む理由です。これは NextPDF の好みではなく、フォーマット自身の規則です。

その中心から、ISO 32000-2 は外側を指し示します。PDF 署名処理は、PAdES については ETSI EN 319 142 シリーズへの「参照によって」定義されます。ETSI はさらに、タイムスタンプトークンについては IETF RFC 3161 を、ハッシュおよび署名アルゴリズムについては NIST FIPS シリーズを参照します。したがって、ひとつの機能は複数のドキュメントを貫く経路であり、各ドキュメントがそれぞれの層について規範的です。

1. Step 1 of 5: ISO 32000-2 §12.8 signatures ISO 32000-2 §12.8 signatures
2. Step 2 of 5: ETSI EN 319 142-1 PAdES baseline ETSI EN 319 142-1 PAdES baseline
3. Step 3 of 5: RFC 3161 timestamp token RFC 3161 timestamp token
4. Step 4 of 5: NIST FIPS 180-4 hash strength NIST FIPS 180-4 hash strength
5. Step 5 of 5: WCAG 2.2 tagged output WCAG 2.2 tagged output

ひとつの長期検証可能な署名済み PDF がたどる標準の経路です。ISO がコンテナを定義し署名プロファイルについて ETSI を指し示します。ETSI は IETF のタイムスタンプを要求します。暗号プリミティブは NIST 承認のものです。レンダリングされた出力は W3C のアクセシビリティに照らされます。各矢印は規範的参照であり、緩やかな関連付けではありません。

条項はどのように挙動になるのか

標準への危険な取り組み方は、条項を読んで、その記憶を頼りにコードを書くことです。NextPDF の道筋は意図的に長くしてあります。長い道筋こそ、監査できる道筋だからです。

1. Retrieve The clause is read from the standard, not from memory.
2. Cite It is paraphrased and pinned with a chunk digest, never quoted.
3. Classify Its keyword (shall / should / may) sets whether it is a contract or a recommendation.
4. Map The obligation becomes a concrete engine requirement.
5. Implement The requirement is built into the pipeline.
6. Pin A test holds the behaviour against drift.
7. Tag The page that describes it declares its evidence level.

規範的な条項からテスト済みのエンジン挙動へと至る道筋です。条項を取得して引用し、その規範的キーワードによって義務を分類し、エンジン要件へとマッピングし、実装し、テストで固定し、文書化するページにそのエビデンス基盤をタグ付けします。テストの手前で止まる条項は挙動ではなく主張です。

「分類」のステップは、曖昧さの大半が解消される場所です。仕様は要件レベルをキーワードに符号化します。よく知られた MUST、SHALL、SHOULD、MAY の系列です。これらのキーワードの意味は IETF の要件キーワード規約によって固定され、規範的効力を持つのは大文字形として現れる場合だけであると明確化する更新を経たうえで、各仕様の説明的な散文に重ねられます Spec Spec: RFC 2119 RFC 2119 Spec Spec: RFC 8174 RFC 8174 。 NextPDF は shall を、エンジンが越えない厳格な境界として読み、 should は従いつつも推奨事項として文書化するものとして読みます。 決して約束としてではありません。その区別こそが、誠実な機能の言明と過大な主張を分けます。

適合は二者択一ではなく段階的

「適合」が 1 ビットで表せることはまれです。署名標準には段階があります。たとえば、欧州のアーカイブ付き長期プロファイルは、作成後長い時間が経っても署名を検証可能に保つため、タイムスタンプトークンを追加する目的で存在します Spec Spec: ETSI EN 319 122-1, §6 ETSI EN 319 122-1 §6 。これは、素のベースライン署名よりも明確に強い主張です。アクセシビリティ標準も同じ構造です。つまり、適合レベルは、そのレベルのすべての達成基準を満たすことによってのみ到達され、主張には実際に到達したレベルを明示します Spec Spec: WCAG 2.2, §5.2.1 WCAG 2.2 §5.2.1 。したがって NextPDF は、無条件の「準拠」ではなく、プロファイルとレベルを明示します。

Human-factors note: Human-factors note

標準の経路は装飾的なグラフィックではなく、順序付けられ、 キャプション付きの図として描かれます。読み手が参照を順序どおりにたどれ、スクリーンリーダーがそれと同じ順序で読み上げられる必要があるからです。 仕様間の矢印は装飾です。 意味はすべて仕様名と、経路のテキスト等価物であるキャプションが担います。 これは Insider_ のあらゆる図を律するのと同じ理屈です。すなわち、順序と意味は色やコネクタではなく、マークアップに宿ります。

エビデンスが示すこと

このページは Evidence § Standard-backed Evidence: Standard-backed です。各主張は条項にひもづけられ、言い換えられ、ダイジェスト付きで引用されているため、次のレビュアーは出典に照らして再検証できます。

層	団体	ひもづけ条項（言い換え）	NextPDF で規定する対象
フォーマット	ISO	書き手が作成または修正した要素は、適合し整合性を保つ必要 Spec Spec: ISO 32000-2, §6 ISO 32000-2 §6	エンジンが出力する PDF
適合性	ISO	適合ファイルはすべての要件を満たす。追加機能は任意 Spec Spec: ISO 32000-2, §6 ISO 32000-2 §6	「有効な出力」の意味
署名プロファイル	ETSI	後日の検証のため、長期＋アーカイブレベルはタイムスタンプを追加 Spec Spec: ETSI EN 319 122-1, §6 ETSI EN 319 122-1 §6	署名対象の PAdES プロファイル
信頼できる時刻	IETF	タイムスタンプサービスは、ある時刻以前にデータが存在したことを証明 Spec Spec: RFC 3161, §2 RFC 3161 §2	ドキュメントタイムスタンプトークン
暗号	NIST	承認済みハッシュは付与する安全強度が異なる Spec Spec: NIST FIPS 180-4, §1 NIST FIPS 180-4 §1	署名を支えるダイジェストアルゴリズム
出力アクセス	W3C	適合レベルには、そのレベルのすべての基準が必要 Spec Spec: WCAG 2.2, §5.2.1 WCAG 2.2 §5.2.1	レンダリングされた PDF へのアクセシビリティ主張

引用されたダイジェストは、このページの citations フロントマターに記録されています。標準のテキストはここには一切再現していません。その選択を律する規則は、それ自体がひとつのページになっています。引用の規律 を参照してください。

実践例

標準の全体像は実行するものではありません。それを読み、エンジンに何を求めるかを決めるものです。具体的には、長期検証可能な署名呼び出しは、経路上のどの地点を必要とするかについての言明です。

examples/36-sign-pades-b-b-and-b-t.php

<?php

declare(strict_types=1);

use NextPDF\Core\Document;
use NextPDF\Security\Signature\CertificateInfo;
use NextPDF\Security\Signature\DigitalSigner;
use NextPDF\Security\Signature\SignatureLevel;

// The signature level is a coordinate on the ISO -> ETSI -> RFC trail.
// PAdES B-B is the ETSI baseline CMS SignedData the Core engine produces;
// B-T adds an RFC 3161 timestamp, and B-LT/B-LTA add the DSS and document
// timestamps that keep a signature validatable after the certificate
// expires. The level you name is the point on the trail you are asking for.
$certInfo = CertificateInfo::fromFiles(
    certPath: 'signer-cert.pem',
    keyPath: 'signer-key.pem',
);

// The functional signing path is the direct two-phase signing engine.
// (Document::setSignature() records intent but its writer seam is not yet
// wired and fail-fasts on output — see the PadesOrchestrator docblock.)
$signer = new DigitalSigner(
    certInfo: $certInfo,
    level: SignatureLevel::PAdES_B_B,
);

$result = $signer->sign(file_get_contents('agreement.pdf'));

printf(
    "PAdES %s CMS: %d bytes, timestamp=%s\n",
    SignatureLevel::PAdES_B_B->value,
    $result->getSize(),
    $result->hasTimestamp() ? 'yes' : 'no',
);

素のベースラインではなく PAdES_B_LTA を指定するのは、パフォーマンスのつまみを変えることではありません。それは、義務が標準の経路をどこまで深くたどるかについての決定です。B-LT と B-LTA は DSS とアーカイブタイムスタンプの層を引き込み、実行時にエンタープライズ LTV パッケージを必要とします。エンジンは静かに劣化するのではなく、低いレベルがより高いレベルを提供しているかのように装うことを拒みます。

よくある誤解

罠は、「NextPDF は標準準拠である」という文を、単一の全面的な保証として読むことです。そうではありませんし、誠実なエンジンであればどれもそうではありません。準拠は標準ごと、条項ごと、そしてレベルごとです。NextPDF は PDF 2.0 ベースライン、名前付きの PAdES プロファイル、そして明示されたアクセシビリティレベルを対象とします。それぞれがスコープを持ち、それぞれが引用されています。条項とレベルを背後に持たない主張はマーケティングであり、Insider_ はそれを掲載しません。

第二の、より微妙な罠は、規範的な should を約束だと思い込むことです。それは推奨です。NextPDF は推奨事項を推奨事項として文書化します。エンジンの保証は shall 条項から組み立てられており、この違いは load-bearing（要となるもの）です。

制限と境界

このページは地図であって、領土ではありません。NextPDF が実装するすべての条項を列挙するものではなく、適合証明書でもありません。挙動ごとの証明は、その挙動を扱うトピックページに、そのページ自身のエビデンスレベルとともに置かれます。たとえば、フォーマットの差分については PDF 2.0：何が変わったか です。

標準の全体像もまた変化します。新しい版が出荷されます。参照は別の先を指すようになります。ここで引用される条項は、このページの citations に記録されたコーパススナップショットに固定されています。上流の標準が改訂されたとき、引用は新しい条項に照らして再検証され、そのまま引き継げるものとは見なされません。このページが Premium ティアの機能を名指す場合、それはどの標準に応えるかのレベルで行われ、内部メカニズムのレベルで行われることは決してありません。

関連ドキュメント

• PDF 2.0：何が変わったか — この地図のフォーマット層が指し示す、具体的な ISO 32000-2 の差分。
• 製品としてのドキュメント — 条項を挙動へマッピングする規律を、エンジニアリングとして扱う理由。
• 引用の規律 — ここで条項をどのように引用するかを決める規則と、エビデンスレベルの意味。

用語集

• 標準化団体 — 仕様を発行する組織（ISO、ETSI、IETF、W3C、NIST）。それぞれが PDF スタックの異なる層を管轄します。
• 規範的条項 — 標準内の要件。そのキーワード（必須は shall/must、推奨は should、任意は may）によって識別されます。
• 標準の経路 — ひとつの機能がたどる、順序付けられた仕様の連鎖。各ドキュメントが次のドキュメントを規範的に参照します。
• 適合レベル — 準拠の段階的なティア（ETSI ベースラインプロファイル、WCAG レベル）。主張は無条件の「準拠」ではなく、実際に到達したレベルを明示します。
• PAdES — PDF Advanced Electronic Signatures。ISO 32000-2 が PDF 署名のために参照する、ETSI EN 319 142 ファミリーの署名プロファイル。