要約

  • RFC 9905はIETF Standards Trackであり、2025年11月に公開され、RFC 4034とRFC 5155を更新する。SHA-1廃止を「作ることは止めるが、読むことは続ける」という非対称な移行として定義する。
  • RSASHA1およびRSASHA1-NSEC3-SHA1は、DS、DNSKEY、RRSIGレコードの作成に MUST NOT である。影響を受けるDSだけを持つ委任は、定められた条件ではinsecureとして扱うのであり、bogusや検証失敗と表現してはならない。
  • バリデーター実装は、両アルゴリズムによる検証を引き続き MUST 実装する。したがって、いま全てのバリデーターがSHA-1検証を削除できるとは言えない。すでに削除したソフトウェアは、この義務を満たすため手動ビルドを必要とする場合がある。
  • 移行では、権威署名、DS公開、再帰検証を別々に棚卸しし、強いアルゴリズムとの重複期間とロールバックの証拠を用意する。

重要なのは、三つの責務を一つの「SHA-1対応状況」にまとめないことだ。権威側には新規生成禁止がある。親ゾーンへのDS公開には、対象アルゴリズムのDSを作成してはならないという制約がある。対象DSしかない委任は、別の受理可能なDSがなければinsecureになる。再帰側には、残るデータを検証する実装義務がある。RFC 9905のレジストリ行は、生成列ではMUST NOT、検証実装列ではMUSTという、異なる変更管理入力になる。

**Theo March 分析：**これは暗号アルゴリズムの単純な削除ではなく、ソフトウェアのライフサイクルとロックインを可視化する移行である。検証コードを先に消せば、残存する委任を読めることの証拠を失う。一方、旧署名だけを残し、受理可能な強いアルゴリズムとDSの共存を確認しなければ、撤去時に安全な戻り道がない。継続検証は署名継続の許可ではなく、移行中の互換性を限定して維持する要求だ。

運用の順序と具体的な確認

第一に、権威署名装置を確認する。各ゾーンのDNSKEYとRRSIGについて、現在生成されているアルゴリズムを一覧化し、RSASHA1とRSASHA1-NSEC3-SHA1が新しいレコードに使われていないことを確認する。SHA-1系を使うゾーン所有者は、IANAレジストリが推奨する強いアルゴリズムへ直ちに移行すべきだ。ただし、特定アルゴリズムの普及率や将来の登録簿変更をここから推測してはいけない。

第二に、親ゾーンのDSを確認する。対象二方式で新しいDSを作成せず、各委任に受理可能な強いアルゴリズムのDSが存在し、親側から見えることを検査する。対象DSしかない場合、他の受理可能なDSで検証できなければデータはinsecureとして扱われる。この規範上の結果をbogus、failed、あるいは一律の検証エラーに置き換えない。

第三に、再帰検証の実装を確認する。実際のビルドと設定で両アルゴリズムの検証が可能であることをテストし、クエリー、DNSKEY、RRSIG、チェーンの結果を保存する。SHA-1検証を既に削除したソフトウェアは、手動ビルドを評価する必要がある場合がある。特定ベンダーの挙動、既定値、採用状況、障害、性能については、この事実範囲から主張できない。

重複期間の証拠には、強いDNSKEYとRRSIGが公開され検証できること、親DSが公開されチェーンを形成すること、再帰側が旧方式も検証できることを含める。その後に旧署名または旧DSの撤去を進め、前後の応答、TTL、チェーン検証結果を保存する。新しいチェーンが検証できない場合や親と権威の状態が一致しない場合は、最後に検証済みの構成へ戻す。これはSHA-1を再生成するロールバックではなく、準備済みの強い署名とDS状態を戻す操作である。

出典