要約

  • RFC 9537のredactedメンバーは、サーバーが伏字にしたフィールドの論理名、方法、処理前または処理後の位置を示せる。これは届いた応答についてのサーバー側の主張であり、元の値の写しでも独立検証でもない。
  • 理由は任意で、具体的な方針はRFCの範囲外である。存在を認めること自体が漏えいになる場合はシグナルを省けるため、監査にはクエリ、権威サーバー、アクセス区分、時刻、生の応答、パス評価、方針版を別々に残す必要がある。

「見えない」を一つの状態にしない

ドメイン情報の監視画面に、登録者名が表示されないとする。利用者には空欄が一つ見えるだけだ。しかし背後では、値が登録されていない場合、匿名利用者には伏せた場合、エンティティ全体を除いた場合、別の連絡手段に置き換えた場合があり得る。画面がすべてを「なし」と数えれば、可視性の違いをデータの有無にすり替えてしまう。

2024年3月にIETFのStandards Trackとして公開されたRFC 9537は、この限定された問題を扱う。著者はJames Gould、David Smith、Jody Kolker、Roger Carneyである。2026年9月7日に確認したIETFプロフィールには、Gouldに関連するRFCが13件掲載されている。Registration Operations Workshopの委員紹介は、GouldをVerisignの技術サービス部門のfellowで、ドメイン登録サービスの技術的方向を担う人物と説明する。これは経歴と共同著者性の裏付けであって、単独発明や他社実装への支配を意味しない。

仕様が作ったのは、空白を万能な結論に変える仕組みではない。サーバーが自分の出力について、どの場所をどう伏せたと述べるための共通形式である。

redactedが結ぶ範囲

拡張を使う応答は、rdapConformanceにredactedを掲げる。伏字対象を含むオブジェクトには通常、説明の配列が置かれる。各要素には必須のnameがあり、登録済みtypeまたは自由記述のdescriptionで論理名を示す。

位置はパスで表す。prePathは処理前の構造を指すので、届いたJSONで解決しなくても当然である。postPathは空値、部分値、置換値として残った位置を指す。両者は同時に置けない。別フィールドが代替機能を持つならreplacementPathで示せる。既定の表現言語はRFC 9535のJSONPathだ。

この組合せは、サーバーが特定フィールドを特定方法で伏せたと述べたことを記録する。元の文字列は含まない。内部記録が正しかったか、想定された人物と一致したか、クライアントの権限判定が適切だったかも分からない。JSONの座標は、隠れた現実への証明書ではない。

IANAのRDAPレジストリは、拡張識別子や共通の伏字名、理由、式言語を管理する。登録値は相互運用を助けるが、個々の応答や方針を認定しない。

四つの方法は同じ跡を残さない

removalではフィールドやオブジェクトを応答から取り除く。methodが無い場合の既定値だが、配列の位置が意味を持つ箇所にはそのまま使えない。jCardのような固定位置の配列では、emptyValueにより位置を保って空文字やnullを置く。partialValueは書式付き値の一部を残し、replacementValueは匿名メールや連絡フォームなど別の値・フィールドを渡す。

表示層が四つを同じ「非公開」バッジにしても、観測結果は別物だ。削除されたオブジェクトと空のスロットは検査方法が違う。住所の一部は情報を残す。連絡フォームは到達手段だが、登録者の元メールではない。RFCは同じ文字を繰り返した埋め草も認めない。形式に合わない偽の値は、伏字の合図をかえって不確かにするからだ。

証拠として残すべきなのは画面の文言ではなく、受信したJSONの形、方法、パスである。

理由欄は方針の判決文ではない

各項目には任意のreasonを付けられる。登録済みtypeでも、人向けのdescriptionでもよい。ただしdescriptionをクライアント処理の依存先にしてはならない。「サーバー方針」という文章だけを条件に自動承認する実装は、仕様の境界を越える。

サーバーは伏字方針を公開できるが、その内容はRFC 9537の範囲外だ。仕様は同意の有効性、法域、開示請求者の権利、個別判断の妥当性を決めない。RFC 7481はローカル方針に基づく認証と段階的アクセスを可能にする。同じオブジェクトが匿名利用者と認証利用者に違って見えること自体は、矛盾ではない。

ICANNの2024年gTLD向けRDAP Response Profileは、特定の制度がこの共通機構に具体的ルールを重ねる例だ。対象フィールドをRFC 9537の名前と方法に対応させ、メールの置換などを定める。適用範囲内では重要な運用根拠だが、すべてのRDAP運用者に及ぶ普遍方針ではない。

さらに、あるフィールドが存在すると認めるだけで情報が漏れる場合がある。RFCは、その存在シグナルがプライバシー問題になるなら伏字項目を省くことを許す。したがってredactedが無い応答を「伏字なしで完全」とは読めない。拡張未実装や、存在を明かさない選択も残る。

小さな証明を支える受領記録

まず正確なURI、lookupかsearchか、権威サーバー、リダイレクト、取得時刻、TLS上の相手、認証方法、アクセス区分を残す。同じドメインでも匿名照会と権限付き照会は別の観測だ。

次に生の応答または検証可能なハッシュ、rdapConformance、オブジェクト識別子、各項目の名前、パス言語、パス、方法、理由を保存する。postPathが実際に解決したか、受信文書に無いprePathをどう扱ったか、RDAPパーサーとJSONPath実装の版も記録する。クライアント更新による評価差をサーバー変更と誤認しないためだ。

方針ページへのリンクがあれば、URLだけでなく観測時の版と時刻が要る。後日書き換わったページは、過去の応答に適用された方針を自動的には証明しない。二つの応答を比較するなら、それぞれのアクセス区分を保持する。

RFC 9082ではlookupとsearchが別の要求であり、searchの伏字説明は個々の結果オブジェクトに属する。結果集合全体の打ち切りと、オブジェクト内の一フィールドの伏字は同じではない。RFC 9083のnoticesやremarksも周辺事情を説明できるが、フィールド単位の構造化項目の代わりにはならない。

ここまで揃って初めて、「このサーバーが、この時刻とアクセス条件の応答で、この場所をこの方法で伏せたと説明した」と言える。元の値、方針の権限、開示の適否には別の受領記録が必要だ。

出典