Summary

  • 10月23日に公開された個人のInternet-Draftは、コンテンツ発信者の鍵と身分情報の失効状態をDNSで確かめる方式を提案する。
  • 発信者は自分のドメインに受け入れる中核プロフィールの発行者を記せる。DNSSECで確かめた名簿にない発行者の証明書は検証に通らない。

受付で見せられた身分証は本物だった。それでも、発行元がこの新聞社の代理を頼まれていたかは別の話だ。Shigeya Suzukiの草案が扱うのは、この地味で厄介な確認である。10月23日公開の文書は実験的な仕様を目指す。IETFの文書記録では個人提出の有効な草案とされ、IETFとして承認された標準ではない。

提案の対象はOriginator Profileという発信者情報だ。中核プロフィールには、記事や広告などに署名する発信者の公開鍵が載る。別の発行者は確認済みの属性を注釈として付けられる。署名を調べるだけでは、鍵が今も使えるか、プロフィールが取り消されていないか分からない。草案は_op以下に新しいOPKEYレコードを置き、鍵の要約と中核プロフィールの有効性を確認する。注釈の失効にはTXTレコードを使う。プロフィール本体をDNSに詰め込む方式ではない。

主導権が動くのは発信者自身のゾーンだ。_op.<originator>のSVCBレコードに、受け入れる中核プロフィール発行者を列挙できる。DNSSECで真正性を確認できれば、検証者は提示されたプロフィールの発行者をその名簿と照らす。制度内で認められた発行者でも、その発信者の名簿に載っていなければ入口で止まる。一方、この指定は任意である。利用規則が義務づけず、安全に確認できる指定もなければ、発信者は発行者を固定していない扱いになる。

DNSには「ない」と「答えが壊れた」の違いがある。OPKEYではDNSSECで安全と確認された結果だけを使い、署名のない応答、偽の証明、名前解決の障害はいずれも検証失敗となる。任意のSVCB指定は少し違い、安全に不存在を証明できれば未固定の状態に戻れるが、偽の応答やタイムアウトでは先へ進めない。故障を発信者の意思表示に読み替えないための線引きだ。

失効もボタン一つで全員に届くわけではない。草案は運用上の想定としてレコードと否定応答のキャッシュを各１時間と置く。古い応答は期限まで残り、過去に署名された応答の再利用や期限切れデータの提供が見え方を延ばす可能性もある。60秒に設定した実験では変更が検証用リゾルバに63秒以内で見えたという。現場での一律の失効時間を示す数字ではない。