Summary

  • RFC 2440は多数のOpenPGPパケットタグを定義した一方、恒久的な新規タグを通常追加する手順を設けなかった。新旧機能の相互作用が全体の安全性を下げ得るためだ。
  • ヘッダーに番号の余地があっても、利用許可を意味しない。60〜63は私用または実験用に残され、新しい値の要望はIESGのSecurity Area Directorか適切なIETFワーキンググループへ送ることとされた。
  • 署名サブパケットは通常、未知の型なら無視される。critical bitを立てれば、署名者は機能の意味を黙って失うよりエラーを選べる。認識と実装は別であり、未ハッシュの情報も決定的証拠ではない。
  • 後続仕様はレジストリと審査手続きを明確にした。番号の割り当て、解析成功、署名の有効性だけでは、安全な組み合わせや実運用を証明できない。

空き枠は結論ではない

開発者がOpenPGPパケットの未使用タグを見つけたとする。新しい二つのクライアントはその値を書き込み、読み戻し、テストに通った。バイト列は収まる。だが古い検証ソフトはどう扱うだろう。交渉で機能を弱められるのか。別のパケットが意味を変えないか。新しい意味が無視されても、署名は数学的には有効にならないか。ローカルの往復テストは、どれにも答えない。

1998年11月、RFC 2440のIESG注記はその懸念を明記した。多くのタグ値を定義しながら、新しい値を通常追加する仕組みは記述しなかった。新形式のヘッダーは63までのタグを表せるが、新旧機能の微妙な相互作用が全体の安全性を大幅に下げる可能性があると警告した。暗号アルゴリズムなど新しい値の要望は、IESGのSecurity Area Directorまたは適切なワーキンググループに送る。60〜63は私用・実験用に留める。番号空間があることと、安全な拡張手続きがあることは別だった。

OpenPGPは独立したアルゴリズムの寄せ集めではない。パケットは鍵、署名、暗号化メッセージを構成する。新機能は、旧ソフトが列を解析する方法、新しい実装が旧フィールドを解釈する方法、受信者が署名の対象範囲を理解する方法に影響し得る。構文上のタグが使えても、その相互作用は未検証かもしれない。RFC 2440は、符号化の能力とプロトコル上の許可を分けた。

署名が境界を見せた

署名サブパケットには同じ緊張が小さな形で現れる。未知のサブパケットを無視すれば前方互換性を保ちやすく、古い実装でも新しいメタデータ付きの署名を扱える。RFC 2440が未認識の型を無視するよう推奨したのはそのためだ。しかし、黙って無視すれば署名者が必要とする機能まで失われる。

サブパケット型のbit 7が選択肢を与えた。未知のサブパケットがcriticalとして印付けされていれば、評価側は署名をエラーとみなすべきだった。署名者は、意味を捨てたまま受理するより、目に見える失敗を選べる。ただし万能ではない。評価側が規則を理解する必要があり、型を認識していても実装しているとは限らない。仕様は両者を明確に区別した。

有効な署名の横にある認識済みデータも、その署名の権威を自動的には得ない。サブパケットはハッシュ対象にも対象外にも置けた。RFC 2440は、未ハッシュ情報は署名本体に含まれないため決定的とみなせないと警告した。読み取れること、解析できることは、暗号学的に保護されることとは異なる。存在、解析、認識、実装、被覆は別々の状態だ。

慎重さからレジストリへ

2007年にRFC 2440を置き換えたRFC 4880は、IANAレジストリを明示し、新しいパケット型を重要機能としてIETFコンセンサスに求めた。変更検出機能の拡張に伴うダウングレードやクロスグレードのリスクも指摘した。手続きは見えやすくなったが、相互運用、実装、安全性の分析が一つのチェック欄になったわけではない。

2024年のRFC 9580はRFC 4880を置き換え、異なる登録手続きを維持した。一部のOpenPGPレジストリはSpecification Required、パケット型や特定のバージョン・識別子空間にはより厳しいRFC Requiredを適用する。指定専門家は期待される安全性と既存実装との相互運用性を検討する。これは以前の空白への制度的回答であって、承認された拡張があらゆる環境で安全という証明ではない。

これらの文書は、すべての拡張が有害だったとも、実装者が一様に対応したとも述べていない。示すのはもっと限定された歴史的事実だ。暗号プロトコルに意味を加えると、既存経路の振る舞いまで変わり得る。空き整数は形式上の住所にすぎず、互換性、暗号学的被覆、利用者の理解、運用上の安全を証明しない。

出典