要約

  • 改訂02は単一の採点オブジェクトを結果配列に変更し、各項目で評価方式と発行者URIを必須にした。
  • URIは誰に帰属する結果かを示すが、本人が作成したこと、再配布で改変されていないこと、評価方式が信頼できることまでは証明しない。
  • 自動処理は点数だけでなく、対象、方式、発行者、配布者、時刻、状態、証拠を一体として扱う必要がある。

ディレクトリに赤や緑の数字が付けば、利用者は説明文より先に結論を見る。だからこそ、9月6日に提出された draft-bertoldi-regext-rdap-reliability-scoring-02 の本質は、数値を増やすことではなく、その数値が借りてよい権威の範囲を狭めることにある。

名称は reliabilityScoring から reliabilityAssessment へ変わった。単一オブジェクトは、複数の評価者や方式を格納する reliabilityAssessment_results 配列になった。各結果には scoreScheme と scoreIssuer が必須となり、期限、個別ID、active・under review・withdrawn の状態も加わった。既知の実装がないことも明記されている。

URIが答えるのは「誰と書いてあるか」

草案は、混同されやすい三つの性質を分ける。識別は、その結果が誰に帰属すると記載されているか。信頼は、受け手がその主体を頼る根拠を持つか。真正性は、主張が実際にその主体から出され、途中で変えられていないかである。

scoreIssuer は最初の問いに答える。世界で一意かつ安定したURIで、できれば発行者自身の管理下に置く。しかし、URIは評価内容への署名ではない。信頼は帯域外の設定に残り、署名付き主張は将来の作業とされた。

HTTPSも第三者の著者性までは保証しない。RFC 7481に従うTLSは応答サーバーを認証し、通信中のバイト列を守る。どのエンドポイントが応答したかは確認できても、その中で名指しされた外部評価者が元の作者かどうかは別問題だ。同RFCが輸送上の完全性とデータの正確さを分けるのと同じである。

同じ形式でも支配関係は三通り

第一の構成は、評価者が自らRDAP評価サービスを運営する形だ。第二はレジストリ、レジストラ、その他のサーバーによる再配布。第三は自己評価である。応答形式は同じでも、信頼経路は同じではない。

自営サービスでは、利用者が評価者とエンドポイントを一組として設定できる。再配布では評価者に加えて仲介者も信頼する必要があり、応答だけでは両者の役割を確定できない。自己評価では帰属が明瞭でも、良く見せたい動機が最も強い。

そのため、権威ある登録データサービスを見つけるRFC 9224のブートストラップに評価サービスは入らない。権威サーバーからの単純な関連リンクも、評価者への推奨と読まれかねないため採用されなかった。到達方法は信頼根拠ではない。

数字ではなく文脈の組を保存する

配列の先頭は、優先順位、権威、最新性のいずれも意味しない。方式が違えば同じ7点でも比較できない。validUntil は発行者が新鮮さを主張する期限であり、過去の結果を無効化する日ではない。状態がなければactiveと推定してはならず、withdrawnの結果はキャッシュ利用者に撤回を伝えるため残り得る。メンバー全体がないことも、未評価・合格・不合格のどれも示さない。

運用で保持すべき単位は、正しく結び付けた対象、方式ID、発行者URI、配布エンドポイント、評価ID、評価日時、期限、状態、保存された証拠の組である。

対象の結び付けにも差がある。ドメインは ldhName で既存の検索ができる。レジストラは評価サービス固有のhandleで検索し、IANA Registrar IDは取得後の publicIds で初めて分かる。IDだけを知るクライアントには検索先を組み立てる帯域内手段がない。RFC 8521のタグ利用は案にとどまり、ccTLD配下などの識別も未解決だ。

異議申立ての制度は方式側に残る

公開を意図する各方式は、開示の脅威モデル、事前通知、是正または異議申立ての期間、データ最小化、ドメイン単位で公開する理由を示さなければならない。低い評価が攻撃者の探索表になり得る以上、重要な追加である。

一方、期間の長さ、裁定者、ガバナンス、異議が認められた場合の効果は共通プロトコルが決めない。相互運用の器は紛争状態を運べるが、記録する行為から裁定権を生み出してはならない。

改訂02の強みは、結果を認証書や執行装置と呼ばず、高得点も脆弱性不在を保証せず、証拠URIも変化・消失し得ると明示した点にある。限界を残したまま使うことが、この拡張を有用にする条件だ。

出典

  1. IETF Datatracker文書記録
  2. RDAP評価草案・改訂02
  3. RDAP評価草案・改訂01
  4. RFC 7480
  5. RFC 7481
  6. RFC 8521
  7. RFC 9082
  8. RFC 9083
  9. RFC 9224
  10. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  11. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  12. Running-Code Primacy