要約

  • RFC 9906はIETF Standards Trackで、2025年11月に公開され、RFC 5933を更新する。
  • GOST R 34.11-94はDSを作成してはならず、そのDSしかない委任は、別の受け入れ可能なDSがなければ不安全として扱う。
  • ECC-GOSTはDNSKEYまたはRRSIGを作成してはならない。旧署名だけが残る場合、別の受け入れ可能なRRSIGがなければ関連レコードは不安全となる。
  • signing、validation、implementation、useの該当セルはすべて MUST NOT である。ゾーン運用者はサポート対象アルゴリズムへ移行し、レジストリはECC-GOST DSのアップロードと公開を拒否すべきである。

RFC 9906が完了させるのは、単なる署名器の設定変更ではない。関連する登録簿の各セルが MUST NOT となり、作成、実装、利用、検証を同じ方向へ揃える。RFC 9905のSHA-1移行とは異なり、ここでは検証サポートを継続しなければならないとはされない。旧ECC-GOSTを生成できないだけでなく、検証側にもサポート対象の経路として残さない。

ルールは二つに分けて読む必要がある。GOST R 34.11-94はDSを作成してはならない。委任にそのDSしかなく、別の受け入れ可能なDSもなければ、委任配下は不安全として扱われる。一方、ECC-GOSTはDNSKEYとRRSIGを作成してはならない。旧ECC-GOSTのRRSIGは未サポートとして扱われ、他に受け入れ可能なRRSIGがなければ、対応するリソースレコードは不安全になる。これはbogusでもfailedでもなく、仕様が指定するinsecureの結果である。

RFC 9558のGOST 2012アルゴリズムは別の系統であり、RFC 9906はその要求レベルを変更しない。アルゴリズム番号を確認せずに一括廃止してはならない。対象は旧来の2001/1994の組み合わせであり、GOST 2012を退役対象に含める根拠はない。

出典