要約

  • RFC 9563は、SM3を用いるSM2にDNSSECアルゴリズム番号17を、SM3にDSダイジェスト種別6を割り当て、ワイヤ上の意味を一意にした。
  • これはIndependent StreamのInformational RFCであり、IETF Standards Track仕様ではない。文書自身が、IETFもIRTFも用途への適合性を分析していないと明記する。
  • レジストリ登録の先には、署名側の実装、親子ゾーンの委任、バリデータ能力、ローカルポリシー、署名検証、アプリケーションの結果という別々の証拠が必要になる。

検証リゾルバが署名付き応答を受け取り、アルゴリズム欄に17を見つけたとする。その番号はもう未知ではない。IANAレジストリを見れば意味が分かる。それでも、リゾルバにSM2実装がないかもしれず、委任に使われたSM3ダイジェストを扱えないかもしれない。ポリシーが経路を採用しないこともある。暗号計算に成功しても、秘密鍵の管理まで正しかったとは限らない。番号は証拠連鎖の入口であり、出口ではない。

RFC 9563は2024年12月4日に公開され、SM2署名とSM3ダイジェストをDNSSECレコードへ収める方法を定義した。アルゴリズム番号は17、ニーモニックはSM2SM3、DSダイジェスト種別は6である。同時に、文書は自らの権威の範囲も限定している。Independent StreamのInformational文書で、IETFコミュニティの合意によるものではない。IETFもIRTFも、SM2またはSM3がこの用途に適するかを分析しておらず、意図的あるいは意図しない弱点があり得ると注意を促す。

これは飾りの注意書きではない。文書から何を推論してよいかを決める一次資料である。

割当てがなくすのは曖昧さであって不確実性ではない

コードポイントがなければ、二つの実装はDNSKEY、RRSIG、DSの中で同じ方式を確実に指示できない。したがって割当てには実務的価値がある。共通のワイヤ形式に名前を与え、私的な解釈同士の衝突を防ぐ。

2026年9月27日に確認したIANA DNS Security Algorithm Numbersレジストリでは、アルゴリズム17の署名・検証での使用と実装推奨はいずれもMAYである。DSレジストリでも種別6は、委任・検証での使用と実装がMAYとされる。これは日付付きのレジストリ事実であり、普及率調査、調達承認、暗号解析の結論ではない。

RFC 6014とIANA表が解決するのは名前空間の統治である。誰がどの審査規則で値を割り当て、その値が何を意味するかを定める。ある運用網で対応リゾルバが一台もなくても、レジストリ記載は正しくあり得る。逆に、実装が存在しても広範な受容は証明されない。カタログを配備報告として読むと、この区別が消える。

RFC 7841も同じ境界を守る。ヘッダと定型文は、どのRFCストリームが文書を公開し、どのステータスを持つかを示す。「RFC 9563」という番号は永続的な文書を指すが、Independent Streamという由来を消したり、IETF合意を生み出したりはしない。

DNSSEC検証は一つの演算ではなく経路である

DNSSECが問うのは、署名方程式が一回成立するかだけではない。RFC 4033は権威サーバ、セキュリティ対応リゾルバ、トラストアンカーの役割を分ける。RFC 4034はDNSKEY、RRSIG、DS、存在否定に関するレコード形式を定義する。RFC 4035は、対応アルゴリズムを選び、一致する鍵を探し、正規化データを再構成し、有効期間を確認し、受け入れられた連鎖に沿って署名を検証するよう求める。

番号17を構文解析できてもSM2を計算できない場合がある。SM2署名には対応してもダイジェスト種別6には対応しない場合もある。子ゾーンがDNSKEYを公開していても、親の委任に利用可能なDSがなければ経路はできない。すべての暗号プリミティブがあっても、ローカルポリシーが採用しないこともある。

RFC 6840の5.2節は重要な結果を明示する。未対応のDSダイジェストは、未対応のDNSKEYアルゴリズムと同様に無視される。対応するDSが一つも残らなければ、バリデータは委任をbogusではなくinsecureとして扱い得る。ゾーンは実際に署名済みで、レジストリも正確なのに、あるリゾルバには対応する認証経路がないという状態が成立する。

RFC 8624が実装・利用推奨を継続的に扱うのはこのためだ。アルゴリズム変更には、署名側と検証側が重なる移行期間が要る。同RFCの表はRFC 9563より前に作られたため、番号17や種別6の現在の対応状況を示す証拠にはならない。実際の能力は、製品、版、暗号バックエンド、ビルド、設定、リゾルバ集団ごとに測る必要がある。

有効な署名が答える問いには境界がある

RFC 9563は暗号演算に必要な公開鍵と署名の符号化を定める。検証成功から言えるのは、選択された公開鍵、検証規則、有効時間のもとで、正規化DNSデータと署名が整合したということだ。秘密鍵を誰が管理していたか、使用が正当に承認されたか、ロールオーバーが連続性を保ったか、アプリケーションが返答を採用したかまでは示さない。

RFC 7583が鍵生成、保管、ロールオーバー、侵害対応、廃止を運用課題として扱うのは、鍵が組織とシステムの中で生きるからである。RFC 9563も暗号アジリティを要求し、弱点が見つかればDS、DNSKEY、RRSIG、NSEC3をキャッシュ時間に配慮して更新する必要があるとする。レジストリの一行では、その移行を実行できない。

必要な証拠は、公開経路とステータス、現在のレジストリ、署名側のビルドと設定、観測したDNSKEY・DS・RRSIG、リゾルバの対応能力、トラストアンカーとポリシー、検証ログ、キャッシュを考慮した移行の連続性、アプリケーション結果へと続く。それぞれの記録は別の出来事を証明する。

Heng Luの「running code primary」と現実層の考え方を当てはめれば、象徴的権威、設定された意図、実行可能な能力、観測結果はどれも現実だが、互いの代わりにはなれない。RFC 9563はSM2とSM3をDNSSECで正確に語れるようにした。その後の現実は、コードと観測だけが示せる。