要約

  • OpenPGPのKey IDは衝突し得る64ビットの検索用ヒントであり、一つの公開鍵パケットや人の身元を単独では確定しない。
  • 再現可能な検証記録には、全候補、選択したパケットと完全なフィンガープリント、取得経路、認証、有効状態、暗号結果、別個の権限判断が要る。

署名の確認画面には、たいてい一つの鍵しか現れない。利用者はその表示を見て、候補も一つだったと思う。しかし一件だけ見せることと、一件しか存在しないことは同じではない。OpenPGPの短いKey IDは、まさにこの差を残している。

短さには明確な利点がある。ログに収まり、口頭で伝えやすく、鍵束から候補を絞れる。ところがUIやAPIが候補集合を消すと、その利便性が身元証明に見え始める。さらに「署名できた」という事実まで、現職や承認権限へ拡張される。

Jon Callasは旧来のOpenPGP仕様に名を残す人物だ。IETF Datatrackerの記録にはRFC 2440とRFC 4880を含む5件のRFCがある。ACLUの人物紹介は暗号、ソフトウェア、製品設計にまたがる経歴を記すが、そこから現在の勤務先を推定すべきではない。RFC 4880を置き換えた現行RFC 9580の著者は別の4人である。

64ビットへの切り出し

RFC 4880はKey IDを8オクテットとし、実装に一意性の想定を認めていない。バージョン3のRSA鍵ではモジュラスの下位64ビット、バージョン4ではフィンガープリントの下位64ビットが使われる。

現行のRFC 9580も長さと警告を維持する。バージョン4ではSHA-1フィンガープリントの下位64ビット、バージョン6ではSHA-256フィンガープリントの上位64ビットだ。同じフィールド名でも、バージョンによって切り出し元と位置が違う。

大きな対象を64ビットへ射影すれば、異なる鍵が同じ値になる可能性は残る。それは公開鍵暗号そのものの破綻を意味しない。検索の曖昧さである。危険になるのは、鍵サーバーの先頭結果を無条件に採用したり、Key IDだけを一意制約にして別候補を上書きしたりしたときだ。

鍵のバージョンも証拠である。同じRSAの数学的材料でも、バージョン3、4、6のパケットとして表現すれば、フィンガープリントとKey IDは異なり得る。短い値だけでは、実際に検証した直列化パケットを後から復元できない。

完全な指紋にも出所が要る

完全なフィンガープリントは、特定の公開鍵パケットを示す証拠としてはるかに強い。取得したパケットからローカルに計算し、期待値と機械的に比較できる。衝突の可能性も64ビット片より大幅に低い。

ただしRFC 9580は、人が長いフィンガープリントを読み合わせる方法に疑問を呈する。必要なのは短縮ではなく、認証された経路で期待値を移し、自動比較することだ。設定管理、署名済みディレクトリ、独立に認証された連絡経路と、誰でも変更できるページでは出所の強さが違う。誤った参照値と正確に一致しても、正しい鍵を得たことにはならない。

人との結び付きはさらに別だ。User IDパケットは氏名やメールアドレスなどのUTF-8文字列を格納するが、記載内容の真偽を形式が保証するわけではない。認証署名には強度の違いがあり、genericは確認水準を述べず、personaは確認なし、casualとpositiveはより強い確認を表す。

したがって、期待した名前とフィンガープリントが並んでも、雇用、現在の役職、委任は自動ではない。どの認証者を何の目的で信頼するかを、依拠する側が決めなければならない。

数学的に正しいことと許可されたこと

署名のIssuer Key IDサブパケットも8バイトの手掛かりだ。RFC 9580ではバージョン4より新しい鍵への使用を認めず、Issuer Fingerprintの収録を推奨する。バージョン4で両方があるなら、Key IDはフィンガープリントの下位64ビットと一致しなければならない。この整合性は有用だが、公開鍵パケットの解決を不要にはしない。

暗号検証が答えるのは、「この鍵で、この署名が、この正確なバイト列に対して成立するか」である。鍵や署名の期限、失効、評価時点、許可アルゴリズム、key flagsは別に検査する必要がある。技術的に署名可能な鍵でも、その用途に有効とは限らない。

組織上の権限は暗号計算の外にある。リリース文書の署名が正しくても、鍵の管理者が現在のリリース責任者か、文書が正しい成果物を指すか、本番投入を許可されたかは分からない。鍵所持、認証された身元、現在の役割、具体的権限にはそれぞれ根拠が要る。

判断を再生できる記録

最初に署名対象と署名パケットの正確なバイト列を保存する。Issuer Key IDは検索ヒントとして残し、各取得元が返した候補をすべて記録する。選んだ候補については、公開鍵パケット、バージョン、ローカル計算した完全なフィンガープリント、取得元と時刻を保持する。

次に、評価したUser ID、認証連鎖または信頼規則、関連時点での失効・期限、key flags、アルゴリズム方針、暗号検証結果を個別に記す。最後に、行為を認める方針と根拠を独立した欄で決定する。

同じKey IDの候補が二つなら二つとも残す。期待値の経路が弱ければ弱いまま示す。身元や権限が分からなければ空欄にする。未知を消さない記録こそ、後の担当者に同じ判断を再現させる。

出典