要約

  • DNSKEYのSEPビットは、運用者が想定する鍵の用途を示す。DS作成などをツールが扱う際には役立つが、鍵の認証や信頼チェーンを証明するものではない。
  • RFC 4034とRFC 4035は、ビット15の有無によって検証動作を変えてはならないと定める。SEP付きの鍵も、RRsetの署名検証にはZone Keyビットを必要とする。
  • Edward LewisはRFC 3757の3人の共著者の一人だ。記録が裏付けるのはこの標準化への貢献であり、単独設計者、特定実装の担当者、現職についての主張ではない。

鍵のラベルと信頼のあいだ

DNSSECでは、子ゾーンがDNSKEYを公開し、親ゾーンはDSを公開して委任先の鍵との関係を示す。両者の間には、運用者が何を意図したかと、プロトコルが何を検証できるかという違いがある。Secure Entry Point（SEP）は前者を手助けする。後者の証明にはならない。

2004年4月のRFC 3757は、Olaf Kolkman、Jakob Schlyter、Edward Lewisの共著で、DNSKEYのフラグ欄にSEPを導入した。文書が挙げる用途は、DSレコード生成の補助と、静的に設定する鍵の識別である。同時に、DNSの検証プロトコルはSEPを使わないと明記している。名称の「Secure」だけから、鍵そのものが信頼済みだと読むことはできない。

たとえば署名ツールは、子ゾーンが公開する鍵の中からSEP付きの鍵を選び、親へ渡すDSの候補を作れる。そこで作業は終わらない。選んだ鍵と計算結果が対応するかを確認し、親ゾーンが正しいDSを公開したかも別に確かめる必要がある。子側のフラグは親側の公開を保証せず、署名の正しさも証明しない。検証リゾルバーは、運用者の意図ではなくDNSSECの規則を適用する。

2005年にRFC 3757を置き換えたRFC 4034とRFC 4035は、この境界を維持した。RFC 4034はSEPを署名・デバッグソフト向けのヒントとして説明する。RFC 4035は、SEPが設定されているからといって検証の振る舞いを変えてはならないと規定する。さらにSEPはZone Keyフラグの代わりにはならない。RRsetの署名検証に使うには、DNSKEYにZone Keyも必要だ。ひとつは運用上の扱い、もうひとつは検証におけるプロトコル上の役割を示す。

RFC 6781によれば、KSKにはSEPを付け、ZSKには付けない分担がよく使われる。しかし、機能ごとに別の鍵を持たず、同じ種類の鍵で複数の役割を担う構成もある。常にKSK/ZSKが分離していると仮定するツールは、鍵を選び違えたり表示を誤ったりする可能性がある。RFCの警告は実際のツール確認を促す根拠にはなるが、誤検証が発生したという証拠ではない。

SEPとRFC 5011のREVOKEも別物だ。RFC 5011は信頼アンカーを自動更新する状態機械を定め、そこでは別のDNSKEYフラグが失効を表す。SEPを失効通知や信頼アンカー更新の合図に読み替えてはならない。

Lewisについて公開記録が示す範囲も限定される。RFC 3757は3人の著者に彼を含め、IETF DatatrackerのプロフィールはそのRFCを記録している。Internet Society Pulseの著者ページは限られた職歴上の文脈を与える。これらはSEPを一人で設計したことや特定製品を実装したことを証明しない。RFC内のARIN表記も過去の所属情報であり、現在の雇用先とは限らない。さらに規格文書は意味と動作を定めるが、導入率、障害件数、誤用の実績は測っていない。確かな結論は、SEPは鍵の扱いを助ける印で、信頼の根拠ではないということだ。

出典