要約
- Job Snijders、Tom Harrison、Ben Maddisonが執筆したRFC 9323は、特定のIPアドレスまたはAS番号の範囲を扱う権限を持つ鍵が、外部ファイルの正確なダイジェスト一覧に署名したことを検証可能にする。
- 有効なRSCは、自然人の本人性、会社を代表する権限、文書内容の正しさ、取引の適法性、受信者の実行義務を証明しない。本人確認、契約、業務判断、ネットワーク運用は別の証拠で判断する必要がある。
署名が合っても、依頼は未決である
顧客が自社のIPアドレスをクラウド事業者に持ち込むBYOIPでは、アドレスを広告してよいという資料や設定情報が受け渡される。事業者は、資料が途中で差し替えられていないか、対象プレフィックスと確かに関係するかを確認したい。
しかし、それだけでは本番投入を決められない。申請者は顧客の正しい担当者か。その人に会社を拘束する権限があるか。資料は現時点でも有効か。既存の経路と衝突しないか。署名の成否より広い問いが残る。
2022年11月にIETF Proposed StandardとなったRFC 9323は、最初の部分を狭く解く。Job Snijders、Tom Harrison、Ben Maddisonは、RPKI Signed Checklist、略してRSCというCMSオブジェクトを定義した。中には番号資源、ダイジェストアルゴリズム、外部ファイルのハッシュ一覧が入る。
ファイル自体はRSCに格納されない。受信者が手元のファイルをハッシュし、一覧と照合する。成功時に言えるのは、選択したRPKI信頼モデルの下で対象資源を扱える鍵が、これらのバイト列を指す一覧に署名したということだ。
「この文書は真実である」「署名者は会社の代表者である」「受信者は依頼を実行せよ」とは言えない。RSCの強さは、そこまで言わないことにある。
IETF DatatrackerにはSnijdersのルーティングセキュリティ分野での活動が記録されている。OpenBSDは、彼をrpki-clientの主要開発者の一人で、ポータブル版の保守担当として挙げる。検証可能な主張を小さく保つ姿勢は、このチェックリストにも表れている。
資源集合とファイル一覧
RSCは少なくとも一つのIPアドレスブロックまたはAS識別子を含む。さらに、ダイジェストアルゴリズムと一つ以上のチェックリスト要素を持つ。各要素にはダイジェストがあり、ファイル名を付けることもできる。
一覧に書かれた資源は、組み込まれたEE証明書がカバーする資源の部分集合でなければならない。あるプレフィックスだけに権限を持つ鍵が、無関係なASNや別のアドレスを一覧に書いて権限を広げることはできない。範囲外なら検証は失敗する。
ダイジェストは正確なバイト列を固定する。日付、句読点、添付、文字コードのどれかが変われば、通常は値も変わる。改変や取り違えを検出するには強い。一方、文章の意味を読み、記述が事実か、契約に十分かを判定する能力はない。
ファイル名は任意である。ファイル名を意識する検証では、名前とダイジェストの両方が一致しなければならない。名前を使わない検証では、対応する要素は名前を持たない。業務フローは「名前を含む一式」を証明するのか、「同一の中身」だけを見るのかを先に選ぶ。
authorization.pdfという名前は証拠らしく見えるが、名前だけで権限は生まれない。同じファイルは改名でき、同じ名前に別内容を入れることもできる。RSCは、見栄えのよいラベルとバイトの同一性を区別する。
一度限りの証明書は身分証ではない
RSCごとに新しい鍵ペアと一回限りのEE証明書を作成し、署名後は秘密鍵を破棄する。証明書にはSIA拡張を入れない。RSCを公開RPKIリポジトリから取得させる設計ではないからだ。
この方法は、同じ証明書を恒久的なログイン資格や社印として使い回す余地を狭める。目的は一つの署名オブジェクトと資源範囲を検証することであり、人物の永続的な身元を示すことではない。
RFC 6480は、資源証明書が公開鍵とIPアドレスまたはAS番号を結び付ける一方、主体の記述的な本人性を証明しないと明記する。RSCもこの境界の内側にある。
RFC 9255はさらに、RPKI資格情報を現実世界の文書や取引の認証に使ってはならないと警告する。資源管理アカウントを操作する人が、限定された技術担当者である場合がある。番号資源について発言できても、会社を法的に拘束できるとは限らない。
企業がROA管理をネットワーク部門や外部委託先に任せることはあり得る。その委任から、契約、購買、法務上の決裁権までは導けない。RPKIアカウントの制御を会社の全面的な同意へ変換すれば、精密な暗号処理が誤った業務判断を加速する。
検証結果を一つの緑色にしない
受信者はまず、CMS包、証明書経路、資源制約、RFC 9323固有の規則を確認する。その後、検証対象として選んだ各ファイルのハッシュを計算し、一覧内の要素と照合する。
名前ありの方式なら名前も一致させる。名前なしの方式なら、対応要素に名前がないことを求める。受信者は一覧の一部だけを検証してもよい。未使用の要素は即時エラーではないが、RFC 9323は添付漏れなどを調べられるよう警告を推奨する。
RFC 6488は、一般的な署名オブジェクトの確認だけでは十分でなく、各オブジェクト型の意味に沿った検証が必要だとする。RFC 6487は資源証明書プロファイルを定め、RFC 9286は検証アルゴリズムを更新した。
CMSが正しくても、文書の主張が正しいとは限らない。任意の署名時刻属性も、取引時刻を法的に確定する時計ではない。受領時刻が重要なら、その目的のための受領証明や監査ログが必要になる。
よい実装は結果を分けて保存する。署名、資源包含、ダイジェスト一致、本人確認、会社権限、規制確認、運用承認である。最初の三つが成功しても、残りは保留または否決になり得る。この分離が自動化の誤推論を防ぐ。
世界のRPKIリポジトリには置かない
RFC 9323は、RSCをグローバルRPKIリポジトリで配布することを禁じる。転送方法は仕様の外に置かれ、HTTPS、電子メール、可搬媒体など、当事者が選んだ経路を使う。
IANAのRPKIレジストリは、Signed ChecklistにOID 1.2.840.113549.1.9.16.1.48と拡張子.sigを割り当てる。実装が同じ種類のオブジェクトを認識するための共通座標であり、中央の受信箱や受理義務を作るものではない。
BYOIPや相互接続の資料は、特定の顧客関係に属することが多い。資源と申請書類の関連を世界に公開すれば、取引や計画が推測される恐れがある。経路起源の検証に必要のない情報まで公開する理由はない。
ただし、帯域外転送は自動的に安全ではない。Webアカウントは乗っ取られ、メールは転送され、媒体は紛失する。RSCはバイトの一致を示すが、通信の秘密、マルウェア検査、送信アカウントの本人性、全添付の到着までは保証しない。
各受信者は、認証付きアップロード、ファイル形式、容量、保存期間、審査手順を自ら設計できる。同じ検証形式を使いながら、顧客受入れの責任は手放さない。それが薄い標準化の利点である。
BYOIPで最後に決めるのは受信者
有効なRSCと一致する書類を受け取った事業者は、資源に結び付いた強い証拠を得る。しかし、申請者の身元、社内委任、契約、法令、既存広告との競合、導入時の安全性は別に確認しなければならない。
本人性は顧客アカウントで、会社権限は委任資料で、目的は契約で、現況は登録情報と経路観測で、運用安全はフィルタ、監視、試験、切戻しで確認する。どれか一つをRSCの成功で置き換えることはできない。
したがって、暗号学的に正しいRSCを業務上の理由で拒否しても矛盾ではない。逆に、信頼できる顧客だからといってRSC失敗を見逃すべきでもない。失敗した層を直すことが、正しい例外処理である。
安全な自動化は、判断をなくすのではなく、決定可能な部分を完全に自動化する。構文、証明書、資源、署名、ハッシュ、名前は機械で処理する。本人確認、権限、コンプライアンス、経路変更は、それぞれ明示した規則で判断する。
普及はロードマップでは測れない
RFCとIANA登録があっても、すべての環境で利用できるとは限らない。RIPE NCCのRPKI四半期計画は、コミュニティ要望を受けたRSC API対応を2026年第3四半期の予定として掲げる。UIは需要と余力があれば後に検討するという位置付けである。
これは実装への道筋を示すが、普及済みの証拠ではない。実際のAPI、バリデータのバージョン、対応アルゴリズム、警告表示、受信側の採用方針を個別に確かめる必要がある。
試験には、期限切れ、失効、資源移転、添付不足、改名、重複ハッシュ、部分検証、未対応アルゴリズムを含めるべきだ。さらに、RPKI担当者は正規だが商取引の決裁権を持たないという組織上の境界を必ず試す。
MENOGの紹介は、Snijdersをルーティングとピアリングの実務共同体に置く。異なる事業者が小さな証拠形式を共有し、受理の責任は各自に残すRSCは、その文化に適している。
限界が信頼をつくる
ダイジェストが知るのはバイトだけである。資源証明書が知るのは、信頼モデルの下での鍵と番号資源の関係だけである。両者を組み合わせれば、紙の自己申告より強く、現実の身分証明より狭い結論を得られる。
その結論は持ち運び、再計算できる。送信者は外部文書に資源の証拠を添え、受信者は独立して検証する。本人性、意図、妥当性、時点、運用リスクについては、適切な証拠で議論を続けられる。
Job Snijdersらは信頼を消したのではない。機械が責任を持って答えられる場所を定めた。真実ではなくバイト列に署名するという限界こそ、この仕組みを自動化に載せられる理由である。
出典
- https://www.rfc-editor.org/info/rfc9323/
- https://datatracker.ietf.org/doc/html/rfc9255
- https://www.rfc-editor.org/info/rfc6480/
- https://www.rfc-editor.org/info/rfc6487/
- https://www.rfc-editor.org/info/rfc6488/
- https://www.rfc-editor.org/info/rfc9286/
- https://www.iana.org/assignments/rpki/
- https://datatracker.ietf.org/person/Job%20Snijders
- https://www.openbsd.org/rpki-client/
- https://www.ripe.net/publications/documentation/quarterly-planning/rpki/
- https://www.menog.org/meetings/menog-19/agenda/job-snijders/
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
