要約

  • RFC 1991の標準的な流れでは、literal dataに署名を付け、その組を圧縮し、使い捨てsession keyで暗号化し、受信者ごとのpublic-key-encrypted packetを先頭に置く。処理順は、署名が何を対象にしたかを決める。
  • ASCII Armorは8-bit binaryをテキスト中心のメール経路に通す外装で、CTBはpacketの種類と長さを示す。CRCや正しい境界は運搬・構文の証拠であり、本人確認や権限の証拠ではない。
  • 署名が通っても、literal packetのfilename、mode、timeまで署名されたとは限らない。普通のsignature timestampにも信頼時刻の権限はない。

最後の緑色ランプから逆にたどる

画面に「署名は有効」と表示された時点で、利用者は処理全体が正しかったと考えやすい。しかし受信側では、その前に別々の判断が済んでいる。Armorの文字列はbinaryへ戻ったか。CRCは一致したか。CTBは次のpacketを説明できたか。候補の秘密鍵はsession keyを復元したか。key-checkは合ったか。復号結果は圧縮packetとして読めたか。展開後の署名は、どのbyte列に対して成立したか。

RFC 1991は、これらを一つの抽象的な「安全」へまとめなかった。PGP fileを一個以上のpacketの連結とし、packetを別のpacketに入れられるようにした。相互運用に必要なのは、各処理が次の入力を再現できることだったからだ。

したがって監査も同じ順序を保つ必要がある。最後の成功だけを保存すると、途中でどの境界を採用し、どのbyte列を選び、どの鍵候補を捨てたのかが消える。

署名は暗号化より内側にある

署名と秘匿を併用すると、送信側はまずmessageのhashを作り、signature packetをmessageの前に置く。通常はsignature packetとliteral data packetを一緒に圧縮する。そのcompressed data packetを一回限りのsession keyで暗号化し、session key自体を各受信者の公開鍵で暗号化したpacketを付ける。

この配置から、署名の権限範囲が分かる。Armorはbinary objectの外側なので、そのheaderは通常の文書署名の対象ではない。暗号化は署名後なので、復号成功は署名成功ではない。圧縮を戻せても、展開されたpacket列が署名対象と一致するかは別に確かめる必要がある。

さらにliteral data packetにはmode、filename、time、literal bytesが入るが、文書署名のdigestへ渡されるのはliteral bytesだけである。表示されたファイル名や時刻がもっともらしくても、署名者がそれを保証したとは言えない。受信アプリケーションがそれらを保存先や実行方法に使うなら、その権限はローカルのpolicyから与えなければならない。

detached signatureは同じ境界を意図的に利用する。packet headerを含まない外部ファイルへ計算するため、attachedと同じ署名を保持できる。複数人が独立に同じ文書へ署名する場合と、後の署名者が前の署名まで包む場合とでは、検証成功の意味が異なる。

CTBが示すのは住所ではなく間取り

packet structure fieldの最初のbyteがCTBである。type bitsはsignature、compressed data、conventional-key-encrypted data、literal dataなどを区別し、length bitsは後続の長さ欄が一、二、四byteか、明示されないかを示す。圧縮packetの不定長形式は、外側の構造の終端までという意味を持つ。

この小さなfieldによって、parserは連結されたobjectを歩ける。ところが、読める間取りは居住者の身元証明ではない。合法なCTBはtypeの構文を、整合したlengthは宣言されたbody境界を示すだけで、bodyの由来、鍵の管理、algorithm実装の安全性、上位処理の完了を示さない。

不定長形式では、外側の境界を先に信頼できなければ内側の終端も決まらない。局所的なparse結果には、必ずそれを成立させたenclosing contextがある。

ASCII Armorは封印ではなく通行票だった

当時の電子メール経路には任意の8-bit byte列をそのまま運べないものがあった。そこでradix-64は三byteを四つの印字可能文字へ写し、メールで変形しやすい文字を避けた。Armorにはheaderline、任意のheader、空行、encoded data、24-bit CRC、tailが並ぶ。

見た目は厳重だが、RFCはArmor headerをmessageの一部ではないと明記する。輸送中に変更され得るため、重要情報を置いてはならない。未知のkeyでもRFC 822型の書式が正しければ、警告しつつ処理を続ける。

CRC一致は、受信した印字可能表現から同じbinary列が復元された可能性を高める。故障検出として有用だが、秘密鍵も信頼モデルも持たない。攻撃者がobject全体を置換しCRCを計算し直すこともできる。Armorの成功は、作者、宛先、署名、承認、到達を証明しない。

鍵を開けた者と鍵の名義人は別の命題

conventional ciphertextの先頭にはrandom prefixと16-bitのkey-checkがあり、復号後に対応するbyteが一致すればsession keyが正しいと仮定する。暗号化されたDEKにもchecksumがある。これは誤った鍵を早く捨てるための局所検査である。

復号できたという事実から分かるのは、ある秘密鍵経路と状態でciphertextを開けたことだ。誰が秘密鍵を操作したか、その操作が許可されていたか、endpointが侵害されていないか、全messageをアプリケーションが受理したかは残る。

64-bitのkey IDにも同じ限界がある。RFC 1991自身が、偶然または悪意により二つの鍵が同じIDを持ち得ると警告する。IDは候補探索に便利でも、鍵や自然人を一意にするものではない。

署名の分類と時刻を分離する

signature packetにはbinary document、canonical text、複数段階のkey/user ID certification、revocation、timestampingなどのclassificationがある。番号をparseできても、全部が同じ主張をするわけではない。一部はPGP 2.6.2で未実装または出力されない。

署名timeは通常、packet作成時刻に近いが、必須ではなく利用者が選べるとRFCは述べる。信頼できる時刻が必要なら、time notaryがsignature packetへ別の署名を加える。普通の署名が有効でも、freshnessや非replay、法的な署名時刻は確定しない。

User IDも印字可能な文字列である。認証署名が成立しても、どの認証者を、どの強度で、どの時点まで信頼するかはrelying systemの判断だ。秘密鍵を使えたこと、現実の人物であること、組織上の役職を持つこと、特定の行為を承認できることは、それぞれ別に記録されるべきである。

古い仕様から残る最小の原則

RFC Editorの記録はRFC 1991をInformationalとし、後にRFC 4880で置き換えられたことを示す。IETFの文書記録、HTML、TXTは1996年の仕様内容を保存する。これは出版と系譜の証拠であって、普及率や現行製品の安全性ではない。

リンクしたIETFのディレクトリ項目は組織へのナビゲーションであり、IETFが本稿の解釈を承認した証拠ではない。

Heng LuのRunning-Code Primacy、最小初期仕様とローカルな将来判断、現実層と象徴層を編集上の方法として用いると、境界は明瞭になる。共通形式はlocalに再現できる最小事実を決める。身元、時刻、権限、実行、結果は、それを観測する主体が別のreceiptで証明する。これらの論考はPGP普及の資料ではなく、証拠を越権させないための公開された分析方法である。

RFC 1991が作った複合packetは、成功を一つに束ねる道具ではない。成功を分解して再現できるようにする道具だった。