タイムスタンプと信頼できる時刻

Spec Spec: RFC 3161 RFC 3161 Spec Spec: RFC 5816 RFC 5816 Spec Spec: ISO 32000-2, §12.8.5 ISO 32000-2 §12.8.5 Evidence § Standard-backed Evidence: Standard-backed

概要

タイムスタンプは、「これがいつ署名されたか」を記録するものではありません。証明するのは、より限定的で、より強い事実です。つまり、特定のデータが特定の時点より前に存在していたことを、署名者ではない第三者による証明として示します。この区別こそが信頼できる時刻の価値そのものであり、しばしば誤解されています。

これが重要な理由

署名の中にある署名時刻は、署名者のコンピューターが主張したものにすぎません。時計は、偶然にも意図的にもずれることがあります。いつの証拠が署名者自身の主張だけであれば、署名者は文書の日付を意のままに前倒しにも後ろ倒しにもできます。昨日失効した証明書を使った署名を、あたかも昨年作成されたもののように見せかけることもできます。「いつ」は些細な詳細ではありません。現在は期限切れまたは失効している証明書で作成された署名が、なお有効とみなされるかどうかを左右します。そして信頼できる時刻が誤っていれば、その上に構築されたあらゆる長期的な有効性の論拠は崩壊します。

要点

• 署名者自身の署名時刻は主張であって、証明ではありません。容易に偽造できます。
• RFC 3161 タイムスタンプとは、タイムスタンプ局（TSA）が発行する署名済みトークンであり、データのハッシュをTSA の時刻に結びつけるものです。
• それが証明する内容は厳密です。すなわち、データは TSA が示した時刻より前に存在していたということです。正確な作成時点ではなく、上限です。
• トークンは送信したナンスとメッセージインプリントを反映するため、リプレイでも、別のデータに関するものでもあり得ません。
• 文書タイムスタンプは同じ仕組みをPDF 全体に適用し、その下にあるすべて、つまり署名と埋め込まれた検証証跡を、信頼できる時点に固定します。

NextPDF のアプローチ

NextPDF は、タイムスタンプを単に取得すればよいものではなく、検証するものとして扱います。トークンを要求することは、作業の半分、それも重要度の低い半分にすぎません。エンジンは、検証されていないトークンを証拠とはみなしません。

エンジンが署名にタイムスタンプを付与するとき、TSA へはデータのハッシュと新しいランダムなナンスを送信し、データそのものは決して送信しません。返されたトークンは、証拠として意味を持つために必要な性質すべてに照らして検証されます。すなわち、局のステータスが「granted」であったこと、トークン内のナンスが送信したものと一致すること、トークン内のメッセージインプリントが送信したハッシュと一致すること、トークン自身の暗号署名が検証できること、トークンのコンテンツタイプがタイムスタンプ型であること、そして示された時刻が許容範囲内に収まることです。いかなる相違も、型付けされた理由を伴うハードな失敗となります。「十分に近いように見える」という経路はありません。文書タイムスタンプも同じルールに従い、1 つの署名の値ではなくファイル全体に適用されます。

1. Hash the data Only a digest of the signature value (or the whole PDF, for a document timestamp) is computed — never the data itself.
2. Send hash + nonce The digest and a fresh random nonce go to the Time-Stamp Authority.
3. TSA returns a token A signed token binds the digest to the TSA’s genTime and echoes the nonce.
4. Verify the token Status granted, nonce matches, message imprint matches, token signature verifies, time within tolerance.
5. Conclude an upper bound The data provably existed before the TSA’s stated time — attested by a party that is not the signer.

信頼できるタイムスタンプがどのように取得され、何を証明するか。ハッシュとナンスが TSA へ送信され、TSA はそのハッシュを自身の時刻に結びつける署名済みトークンを返し、検証者はその結びつきを確認したうえで、データがその時刻より前に存在していた証拠として扱います。

証跡が示すこと

Evidence § Standard-backed Evidence: Standard-backed 定義は厳密です。 Spec Spec: ISO/IEC 18014-2, §3 ISO/IEC 18014-2 §3 はタイムスタンプサービスを、あるデータ項目が特定の時点より前に存在していた証拠を提供するものと定義しています。これは上限であって、作成の瞬間ではありません。 Spec Spec: ISO/IEC 18014-2, §7 ISO/IEC 18014-2 §7 はトークンの TSTInfo の内容、すなわちメッセージインプリント（データのハッシュ）、生成時刻、シリアル番号、および任意のナンスを定義しています。 Spec Spec: ISO/IEC 18014-2, §6 ISO/IEC 18014-2 §6 は、成功時に検証者が導き出してよい結論を述べています。すなわち、そのデータ項目がトークン内の時刻より前に存在していたという結論であり、それ以上でもそれ以下でもありません。

PDF については、 Spec Spec: ISO 32000-2, §12.8.5 ISO 32000-2 §12.8.5 が文書タイムスタンプを規定しています。バイト範囲は Contents の値を除いたファイル全体を対象とし、そのハッシュがタイムスタンプ局へ送信され、返された RFC 3161 トークン（ Spec Spec: RFC 5816 RFC 5816 により更新済み）は Contents に配置されます。署名と同じバイト範囲の規律を、識別情報ではなく時刻に適用する仕組みです。そして Spec Spec: RFC 6960, §4.4.4 RFC 6960 §4.4.4 は、 これが長期保存にとって重要である理由を示しています。信頼できる時刻こそが、証明書が期限切れになった後であっても、署名が作成された当日には信頼できるものであったことを、検証者が証明できるようにするものだからです。

NextPDF のエンジンはハッシュとナンスを送信し、データは決して送信しません。返されたトークンは、ステータス、ナンス、メッセージインプリント、トークン署名、コンテンツタイプ、および時刻の許容範囲に照らして検証したうえで、証拠として扱います。

Human-factors note: Human-factors note

このページは正確な主張から始まります。すなわち、タイムスタンプはデータがある時刻より前に存在していたことを第三者によって証明する、というものです。なぜなら、ここで最も一般的かつ最も高くつく誤りは、これを「正確な署名時点の証明」と誇張することだからです。 真実でより狭い主張を先に述べることが、誤用を防ぐ警告となり 、仕組みの説明より前に置かれています。

実践例

タイムスタンプトークンを手作業で組み立てることはありません。重要なのは信頼の境界です。TSA は構成し保護する対象です。その時刻があなたの証拠になるからです。

<?php

declare(strict_types=1);

use NextPDF\Security\Signature\SignatureLevel;

// Asking for any level at or above B-T requires a TSA.
$level = SignatureLevel::PAdES_B_T;
$level->requiresTimestamp(); // true → a Time-Stamp Authority must be supplied

// The TSA endpoint, its transport security, and its trust anchor are
// deployment-supplied. The engine sends a hash plus a fresh nonce — never the
// document — and verifies the returned token before the signature is accepted.
// A token that fails any check (status, nonce, imprint, signature, time)
// is a hard error, not a warning.

注目すべき境界は、エンジンが文書ではなくハッシュを送信するため、TSA があなたのコンテンツを目にすることは決してない、という点です。そしてエンジンは応答を検証します。認証できない TSA は、信頼できる時刻ではありません。それは単なる別の時計にすぎません。

よくある誤解

落とし穴は、タイムスタンプを「これはこの日付の 14:32 ちょうどに署名された」と読み取ってしまうことです。それは署名イベントを計るストップウォッチではありません。それが証明するのは、データが TSA の時刻より後ではなく存在していたということであり、第三者が設定する上限です。作成はそれより前のどの時点であった可能性もあります。2 つ目の落とし穴は、どのタイムスタンプサーバーでも信頼できる時刻が得られると思い込むことです。署名を検証できないトークン、あるいは局を信頼していないトークンは、何も証明しません。それは信じる理由のない時計です。信頼できる時刻は、認証できる TSA と検証済みのトークンから得られるものであって、サーバーに数値を尋ねるという行為から得られるものではありません。

限界と境界

NextPDF はリクエストを構築し、ハッシュのみを送信し、返されたトークンを検証します。その背後にある局を保証することはありません。TSA の正確さ、その証明書の有効性、そして信頼性は、サービスおよびあなたのデプロイメントの構成の性質であって、エンジンの性質ではありません。タイムスタンプはハッシュを時刻に結びつけます。データの意味、署名者の識別情報、あるいは署名者の証明書が有効であったかどうかについては、何も語りません。それらは別個のチェックであり、署名を正しく検証するで扱っています。エンジンは、信頼できない TSA を信頼できるものにすることはできません。このページはまた、タイムスタンプに特定の法的効力があるとも主張しません。それは TSA のステータスと法域に依存します。信頼できる時刻を再利用して署名を数十年にわたり検証可能に保つ方法は、長期検証で扱っています。

タイムスタンプ機能のティア別提供状況：

RFC 3161 timestamping (signature timestamp and document timestamp) — edition availability

Edition	Availability
Core	○ Not in this edition
Pro	○ PAdES B-T — 署名値に対する、検証済みの RFC 3161 タイムスタンプ。対象はデプロイメントが提供する TSA です。
Enterprise	○ B-LT および B-LTA が使用する文書タイムスタンプを追加し、埋め込まれた検証証跡を固定し、アーカイブ更新ループを駆動します。

関連ドキュメント

• 長期検証 — 文書タイムスタンプが埋め込まれた証跡をどのように封印し、時間の経過に応じて更新されるか。
• PAdES ベースラインプロファイル — 署名タイムスタンプ（B-T）と文書タイムスタンプ（B-LTA）がレベル階層のどこに位置するか。
• 適格署名の解説 — 適格タイムスタンプが eIDAS の信頼モデル全体のどこに位置づけられるか。

用語集

• タイムスタンプ（RFC 3161） — TSA が発行する署名済みトークンで、データのハッシュを TSA の時刻に結びつけ、データがその時刻より前に存在していたことを証明するもの。
• タイムスタンプ局（TSA） — タイムスタンプトークンを発行する信頼できるサービス。
• TSTInfo — トークンのコンテンツ構造。メッセージインプリント、生成時刻、シリアル番号、および任意のナンス。
• メッセージインプリント — タイムスタンプを付与される対象データのハッシュで、トークン内に反映されるもの。
• ナンス — リクエストとともに送信され、トークン内に反映される新しいランダムな値で、応答がリプレイになり得ないようにするもの。
• 文書タイムスタンプ — PDF 全体に対する RFC 3161 タイムスタンプ（RFC 5816 により更新済み）で、署名とその証跡を信頼できる時点に固定するもの。