要約

  • 有効な RSC が示すのは、発行 CA を操作できるだけの支配を持つ者が、証明書内の資源の一部と、任意のデジタルオブジェクトのダイジェストを署名したという事実である。実世界の身元や取引権限は含まれない。
  • 受入側は、CMS・証明書・資源範囲・ファイル照合の結果と、外部の本人確認・会社権限・必要提出物の定義を分離しなければならない。前者が成功しても後者は自動的に成立しない。

ネットワーク資産の取得審査を考える。これは実在の事件ではなく、判断境界を確認するための例である。相手方はアドレス一覧の表計算ファイル、機器台帳の圧縮ファイル、そして .sig ファイルを提出した。検証ソフトは緑を表示する。二つのファイルは RSC 内のダイジェストと一致し、宣言された AS 番号と IP 資源は EE 証明書の範囲内にあり、証明書パスと失効確認も通った。

ただし RSC には三つ目の項目があるのに、そのファイルは届いていない。RFC 9323 では、提示された二つのオブジェクトが正しく照合できるなら、未使用項目があること自体はエラーではない。実装は警告すべきだが、審査担当者は緑の表示だけを見て「所有者本人が署名した」「譲渡権限がある」「提出物は完全だ」と記録した。

暗号は失敗していない。失敗したのは、狭い証拠に広い権限を与えた受入判断である。

RSC の内部にある三つの境界

RSC は CMS で保護された RPKI 署名オブジェクトである。eContentType は id-ct-signedChecklist、OID は 1.2.840.113549.1.9.16.1.48。IANA の RPKI 登録簿には Signed Checklist と .sig が登録され、メディアタイプは application/rpki-checklist である。

第一の境界は資源である。RSC は AS 識別子、IP アドレスブロック、または両方を含まなければならない。その値は、組み込まれた EE 証明書の RFC 3779 資源拡張の部分集合でなければならず、inherit は許されない。証明書が持たない資源を RSC が広げて主張することはできない。

第二はアルゴリズムである。RSC はファイルのダイジェスト計算に使う方式を一つ示す。第三はチェックリストで、各項目に必須のハッシュと任意の可搬ファイル名が入る。名前付き項目では名前が一意、名前なし項目ではハッシュが一意でなければならない。

この構造は、どの資源範囲について、どのバイト列を対象にした主張かを明確にする。会社名、担当者名、契約目的、所有権は構造に存在しない。後から証明書の Subject を読んで補うこともできない。RFC 6487 は、Issuer 名と Subject 名を実体の記述的な身元として意図していない。

「署名が正しい」から「使ってよい」まで

RFC 6488 の共通検証は、DER の CMS SignedData、許可された signedAttrs、SignerInfo と対応する一枚の EE 証明書、署名検証、RPKI トラストアンカーまでの有効なパスを要求する。同 RFC は、この検査だけでは不十分で、オブジェクト種類ごとの追加検証が必要だと明記する。

RSC では RFC 9323 の構文、資源部分集合、チェックリスト制約をさらに検証する。EE 証明書に SIA があってはならない。証明書は検証時点で有効で、CRL 上で失効していない必要がある。一度有効だったオブジェクトでも、EE 証明書が満了または失効すれば有効性を失う。

次にファイルを照合する。入力にファイル名が伴うなら filename-aware モードを使い、計算したダイジェストが一致するだけでなく、同じ名前を持つ項目がちょうど一つ必要になる。名前を使わない入力では filename-unaware モードを選び、名前のない一致項目がちょうど一つ必要だ。運用者がモードを上書きできる実装では、その選択自体を監査記録に残す必要がある。

ここまで成功して初めて「提示されたこのバイト列が、この資源範囲の署名チェックリスト内で一致した」と言える。ファイルの記述内容が正しい、全関連ファイルが含まれる、署名操作を行った者が会社を代表する、という命題はまだ検証されていない。

ダイジェストは意味を読まない

RSC のハッシュ対象は任意のオクテット列である。表計算のセルが真実か、契約条項が有効か、台帳の機器を売主が所有するかを解釈しない。正確に同じ虚偽の文書は正確に一致する。

逆に、人間には同じ内容に見えるテキストでも、改行、文字コード、空白が変われば照合に失敗し得る。RFC 9323 がプレーンテキストを可逆圧縮容器に入れることを推奨するのは、中間処理による意図しない正規化を避けるためである。これはファイル整合性の問題であり、内容審査ではない。

ファイル名も意味の保証ではない。指定された名前の取り違えを検出する助けにはなるが、inventory と名付けたファイルが完全な在庫を含むことまでは証明しない。

未提示項目の警告を、完全性の判定に変える

RSC は一回の検証で全項目を使うことを要求しない。ある受領者は設定ファイルだけ、別の受領者は圧縮アーカイブだけを確認するかもしれない。プロトコルは利用目的を知らないため、未提示項目を直ちに失敗にせず、警告を求める。

その警告を無視すると、チェックリストの完全性と取引資料の完全性が混同される。前者は「RSC に何項目あるか」という構造、後者は「この判断に何が必要か」という外部要件である。取得審査なら、資源登録、顧客割当、担保、未解決紛争、機器権原、セキュリティ事故、アクセス権限などの必要カテゴリを別に定義しなければならない。

受入記録は、提示・一致した項目、提示されたが不一致の項目、RSC にあるが提示されない項目、業務上必要なのに RSC にさえない項目を別々に示すべきだ。緑の比率を一つ出すだけでは、どの空白を誰が引き受けたか分からない。

身元と権限は外から持ってくる

RFC 9323 は RSC のデータを self-asserted と呼ぶ。依存者が確実に推定できるのは、署名者がそのオブジェクトを作れる程度に発行 CA を操作できたことだけである。親 CA はチェックリストの内容を検証していない。

RFC 9255 は、RPKI の I が Identity ではなく Infrastructure だと説明する。RPKI はインターネット番号資源について発言する権限を扱うが、現実の保有者や商取引の本人認証を提供しない。

ホスト型 RPKI では、資源利用者が秘密鍵を直接持たず、CA アカウントへの認証で署名処理を依頼する場合がある。その認証情報を使う者は、経営者かもしれず、ネットワーク業務だけを任された従業員、委託先、侵入者かもしれない。正規のネットワーク管理者であっても、会社資産を譲渡する権限があるとは限らない。

したがって、実世界の主体との対応付けには外部の権威が必要になる。会社登記、取締役会決議、契約上の委任、裁判所命令、顧客認証など、目的に応じた情報源を使う。問うべきは「名前が一致するか」だけでなく、「この人物が現在、この組織を、この目的について拘束できるか」である。

公開リポジトリにないことの意味

RSC は RPKI リポジトリシステムで配布されない。当事者間の経路で渡されるため、コピーを持たない第三者は存在を知らないことがある。公開された EE 証明書の serial に隙間があっても、CRL に対応不明の serial があっても、RSC の存在を確定できない。未公開、発行後すぐの失効、別種類のオブジェクトなど他の説明がある。

配布経路は別の証拠になる。認証済みポータル、既知のメール交換、匿名リンクで同じ RSC バイトを得ても、誰がどの目的で渡したかの証拠価値は異なる。ただし経路が確かでも RSC 検証は省略できず、RSC が有効でも経路と取引文脈は自動的に確定しない。

通常の一回限り EE 証明書は、一つの署名オブジェクトと一対一になるため、証明書失効で対象オブジェクトを失効させられる。CA が同じ鍵で複数 RSC を署名することは技術上可能だが、個別失効できなくなる。効率化が複数の判断を一つの失効スイッチに結び付ける。

RFC 9589 により CMS signing-time は必須になったが、その値の正しさは要求されず、署名時刻の信頼できる証拠ではない。検証時刻、証明書の有効期間、CRL 状態、外部の契約時系列を別に保持する必要がある。

何を証明しなかったかも保存する

最終記録には、RSC の取得経路とハッシュ、CMS と OID、EE 証明書とパス、CRL、検証時刻、資源の包含関係、各ファイルのバイト列と名前、照合モード、未使用項目の警告、外部の身元情報、権限根拠、判断目的、承認者、再審査条件を残す。

同時に否定範囲を書く。RSC は所有権を証明しない。内容を真実にしない。資料の完全性を保証しない。署名操作をした者が法人を拘束できるとは限らない。signing-time は信頼できる取引日ではない。資源ブロックは ROA ではなく、経路起点を許可しない。

RSC を弱く見積もる必要はない。狭い事実を再現可能に証明するから価値がある。受入側がその狭さを守れば、暗号の成功は現実の権限確認を助ける。狭さを消せば、最もきれいな証拠が最も危険な誤認を生む。

参照資料