要約

  • LAMPSのOne Signature Certificates草案は、signedDocumentBindingによって証明書を一つの署名入力に結び付ける。一方、通常の暗号署名はこの結び付きを確認しなくても成功し得る。署名が正しいという判定と、dataTbsHashが一致したという判定は別の受領証である。
  • 証明書は、秘密鍵がその文書専用に生成され、一度だけ使われ、直後に破棄されたとも主張する。しかし、それは認証局の手続きについての表明であり、拡張機能による観測ではない。有効期限と失効経路をなくす設計は管理負担を減らす代わりに、長期的な信頼をCAの方針、保存証拠、将来の信頼設定へ移す。

証明書のnotAfterは9999年の最終秒を示す。noRevAvailは失効情報が存在しないことを示す。signedDocumentBindingは一つの文書向けのハッシュを格納する。そして通常の署名検証は成功した。

では、検証者が文書バインディングを確認したと証明するのはどれか。どれでもない。

One Signature Certificates revision 02は、この切り分けを明記している。署名時に新しい鍵を生成し、一回のデジタル署名にだけ使い、直後に破棄する証明書を定義する。証明書は署名内容に結び付けられ、実質的な有効期限を持たず、失効サービスも持たない。再利用可能な鍵と継続的な失効状態を減らし、長期検証を単純にすることが狙いだ。

これはIETF streamのLAMPS作業部会Internet-Draftで、Proposed Standardを目指す。revision 02は2026年7月1日付、2027年1月2日失効で、Datatracker上のIESG状態はI-D Existsである。RFCではなく、CAが実際に発行していること、鍵が破棄されたこと、ソフトウェアが結び付きを確認すること、保存署名が将来も有効であることの証拠ではない。

一枚の証明書に異なる種類の主張がある

新しい拡張はsignedDocumentBindingと呼ばれ、ASN.1値にdataTbsHash、hashAlg、任意のbindingTypeを持つ。ハッシュは署名対象データを特定し、バインディング種別は周辺の文書形式からそのバイト列をどう作ったかを示す。

ここには二種類の証拠が混在する。ハッシュ比較は、検証者が同じ入力を再構成すれば確認できる。一方、秘密鍵を専用に新規生成し、二回目の利用を防ぎ、すべてのコピーを消去したかは、dataTbsHashから観測できない。証明書は、その運用手続きについてのCAの認証済み表明にすぎない。草案自身も、手続きと破棄保証をCertificate Policyに記述すべきだとしている。

将来の監査に耐える記録は、拡張値、正確なバインディング入力、ダイジェスト比較、CP/CPSの版、発行トランザクション、鍵生成イベント、一回の署名承認、破棄の証拠を分けて保存する必要がある。「ワンタイム証明書は有効だった」という一行に潰すと、どの主張が崩れたかを後から判定できない。

署名が通っても結び付きは未確認かもしれない

セキュリティ考慮事項は、signedDocumentBindingの検証が暗号署名の成功条件ではないと明記する。署名形式と公開鍵を処理したライブラリが正しく成功を返しても、アプリケーションが追加の比較を呼ばないことがある。草案は依拠当事者が署名内容をdataTbsHashと比較すべきだとする。この確認が証明書の意図した範囲を強制し、証明書の差し替えや意図しない再利用を抑える。

したがって判定画面には最低でも二つの状態が要る。signature_validは署名アルゴリズムと形式の結果、document_binding_matchはバインディング種別、再構成バイト、ハッシュ方式、期待値、比較結果を記録する。二番目を実施していないなら状態はnot_checkedであり、passedでも、一番目に含まれる暗黙の成功でもない。

SHOULDをローカル運用で必須にするかはプロファイルの判断である。しかし一文書限定に依存する組織は、保存後の再検証、バッチ処理、モバイルクライアント、外部検証サービスを含め、全経路が同じ規則を適用することを証拠付きで確認しなければならない。

バインディング種別が「同じ文書」のバイトを決める

bindingTypeがない場合の既定方式は署名アルゴリズムへの正確な入力、たとえばXMLのSignedInfoやCMSのDER符号化SignedAttributesをハッシュする。ただし署名入力が証明書自体、または証明書のハッシュを含むと、証明書内のdataTbsHashと循環依存になる。revision 02はその場合の既定方式を禁じ、形式別の除外規則を定める。

CAdESではSigningCertificateとSigningCertificateV2属性を取り除いたDER SignerInfoが対象になる。XAdESではSignedProperties型の参照を除いた後の正規化SignedInfoで、その他の文字、空白、改行を維持する。JWSとCOSEはpayloadのみを対象にし、protected/unprotected headerを除外する。

同じ人間可読文書でも方式が違えばdataTbsHashは変わる。JWS payloadの一致は、protected header、鍵ID、アルゴリズム、証明書参照が同じことを証明しない。それらは通常のJWS検証とアプリケーション方針の領域である。形式、識別子、正規化・除外規則、実装版、再構成したバイトのハッシュまで記録すべきだ。

失効情報なしは、鍵破棄の証明ではない

草案はnotAfterに99991231235959Zを推奨し、RFC 9608のid-ce-noRevAvailで失効情報が利用できないことを示す。これはCRLやOCSPを探すべきでないという信号であって、なぜ失効が不要なのかを証明するものではない。

成立条件は運用モデルにある。鍵が短時間だけ存在し、一回だけ署名し、確実に破棄されたなら、後の失効イベントが既に作成済みの署名を変える必要は小さい。しかしリスクは消えず、作成時記録の正しさへ移る。鍵は本当に新しかったか。署名要求は一件だけか。バックアップ、ログ、クラッシュダンプ、HSM複製、再試行経路にコピーは残らなかったか。破棄は侵害前に完了したか。

noRevAvailはそれらに答えない。検証者は「設計上の失効機構なし」「失効サービスに到達できない」「プロファイルを認識できない」を別状態として扱わなければならない。

発行時刻はCAにタイムスタンプの役割も持たせる

長期署名検証には、署名が存在した最初の信頼可能な時刻が要る。RFC 3161は独立したTime-Stamp Authorityによる方式を定める。revision 02は、証明書が署名時に作られるため発行時刻が署名時刻を確立し、CAがタイムスタンプに似た役割を担うと説明する。

効率的だが、CAの証拠範囲は広がる。CAは身元と公開鍵だけでなく、一回の署名がいつ起きたか、どの入力に属するか、鍵が新規生成されたか、直後に破棄されたかまで表明する。運用者はbest-signature-timeの由来を明示し、証明書発行、RFC 3161タイムスタンプ、検証トークン、アーカイブ証拠などを区別して保存すべきだ。構文上正しいnotBeforeを独立した時刻証明とみなしてはならない。

9999年はCAを不死身にしない

草案は非失効のend-entity証明書にも境界を置く。検証は発行CAを信頼できる期間と仕組みに依存する。初回検証はCA証明書の有効期間内を前提とし、後の再検証ではCA鍵をローカルtrust anchorとして保持する、cross-certificationを使う、更新CA証明書を取得するなどの信頼設定が必要になり得る。その詳細は草案の範囲外である。

従って9999年のnotAfterは一つの期限確認を除くだけで、信頼経路全体を9999年まで保存しない。アルゴリズムは老朽化し、trust storeは変わり、CAは交代・終了し、アーカイブは移行される。原文バイト、証明書経路、方針文書、時刻証拠、検証記録、trust-anchor履歴を回収可能な形で維持する必要がある。

完全なバインディング一致が証明する範囲も狭い。この証明書が、この方式で再構成した入力向けに発行されたという関係であり、署名者が内容を理解したこと、取引権限を持つこと、最終表示を確認したこと、外部の支払いや公開が実行されたことまでは証明しない。証明書構文、経路信頼、署名数学、文書バインディング、CA手続き、鍵ライフサイクル、信頼時刻、権限、アプリ判断、外部結果を型の違う証拠として保つべきである。