要約

  • IETF は LAMPS の憲章を改定し、PKIX と S/MIME の保守に加え、ハイブリッド鍵確立、二重署名、簡素化した証明書処理を作業対象にした。
  • 憲章が与えるのは議題を扱う権限であり、草案採用、RFC 公開、実装出荷、トラストアンカー設置、相互運用や移行の完了ではない。

自己署名は設置者の判断を代行しない

新憲章にある印象的な例は、署名のない X.509 証明書で主体情報を伝える案だ。耐量子署名は大きくなりやすい。すでに保護された設定経路でアンカーを受け取る端末なら、自己署名を運ぶことが帯域と処理の重荷になる場合がある。

だが、ルートが自分の鍵で自分を署名しても、利用側がそのルートを信頼すべき理由にはならない。RFC 5280 はトラストアンカー情報を証明書パス検証への入力として扱い、信頼できる帯域外手順で得られるものとする。RFC 5914 は TrustAnchorInfo という別の表現を定義する。

軽量な容器を評価するなら、署名の有無より設置の証拠を問う必要がある。誰が承認したか、配布経路はどう認証されたか、どの主体名、公鍵、制約を固定したか、旧アンカーをどう置き換え、異常時にどう戻すか。記録のない軽量化は、権限の出所まで薄くしてしまう。

これは憲章が許した検討例であり、標準化済みの仕組みでも導入報告でもない。

8月21日に変わったのは制度上の境界だ

IETF は 2026 年 8 月 21 日 20時40分 UTC、Limited Additional Mechanisms for PKIX and SMIME の再憲章化を発表した。Datatracker では LAMPS は active、現行憲章は承認済み revision 08 とされる。

グループは、終了した PKIX および S/MIME ワーキンググループ由来の CMP、CMC、EST、S/MIME、PKIX などを保守する。同時に、RSA、Diffie-Hellman、ECDSA、ECDH、EdDSA を置き換えるか併用する公開鍵方式を既存環境へ統合する仕事を担う。

あらゆる再設計が許されたわけではない。憲章は、実際の導入に関心を持つ既知の集団と、採用判断ができる程度に具体化した少なくとも一つの案を求める。これは議題への入口であって、方式が安全だという認定ではない。提案は審査で欠陥を示し得るし、当事者は障害方針で割れ、グループが採用しないこともある。

NIST の標準から製品の受容までは別工程だ

NIST は ML-KEM の FIPS 203、ML-DSA の FIPS 204、SLH-DSA の FIPS 205 を公開した。憲章は CFRG が評価した方式も対象にできる。

アルゴリズムが標準化されても、PKIX 証明書、CMS オブジェクト、登録交換、S/MIME クライアントへの埋め込みは自動ではない。符号化、パラメータ、証明書プロファイル、検証とエラーの規則、テストベクトル、実装が要る。

仕様では NIST または IANA が割り当てた OID を使うとされる。OID は構造中で方式を識別可能にするが、ライブラリを更新せず、受容方針も変更しない。

したがって、耐量子対応という一語を、アルゴリズム標準、プロトコルプロファイル、識別子、文書状態、コード、設定、生成物、受理結果、実サービスの観測へ分解すべきだ。

ハイブリッドには共通の導出規則が要る

ハイブリッド鍵確立は、従来方式の共有秘密と、適格な耐量子方式の共有秘密を組み合わせる。LAMPS はその形式、識別子、登録、運用を規定することになる。

二つの値を並べるだけでは組み合わせにならない。双方が同じ符号化と導出手順を実装しなければならない。憲章は HKDF、NIST SP 800-56C の方法、または CFRG の評価した関数を候補として挙げる。RFC 5869 が抽出と展開を分けるように、ソルト、文脈、出力長も合意の一部である。

一方の要素が破られる、誤実装される、置換される、欠落するとき何が守られるかも明記する必要がある。composite KEM は証拠確定時点で active Internet-Draft だ。活発な仕様作業は示すが、最終的な相互運用を示さない。

二重署名は受容状態を増やす

従来署名と耐量子署名を合わせる作業も憲章に入った。composite signature の文書も active Internet-Draft である。

検証側には、全要素の成功が必須か、移行中は片方を許すか、識別子と鍵と署名をどう結ぶか、外側だけ理解するライブラリが未知の要素をどう扱うかという規則が必要だ。緩い扱いは組み合わせを従来方式だけの権限へ降格させる。

認証局、CMS 生成器、メールクライアント、暗号ライブラリ、最終アプリは異なる段階にいられる。実運用はその交差部分だ。新しい材料を含む証明書の数だけでは移行を測れない。

マイルストーンは文書の時計である

発表は 2026 年 10 月に PKIX/CMS の composite signatures、11 月に composite KEM、12 月に CAA Security を置く。これは順序と遅延を可視化する作業計画であり、IETF Last Call、IESG 承認、RFC 公開、製品出荷、全端末配備の保証ではない。

遅延は複雑さ、争点、審査能力の不足を示すかもしれないが、暗号方式の失敗と同義ではない。期日どおりの文書も、制約端末が大きなオブジェクトを運べることや、安全なロールバックを証明しない。

制度の進捗と実装・受容の証拠は別々に報告する必要がある。

憲章の権限は作業境界で止まる

憲章は問題を正式な議題にし、査読者を集め、文書に居場所を与える。しかし LAMPS を認証局、アルゴリズム規制者、遠隔の信頼ストア管理者にはしない。

NIST は自らの標準を管理し、指定機関は規則に従って識別子を割り当て、IETF プロセスが文書状態を決める。ベンダーがコードを出荷し、運用者と製品所有者が何を受け入れるかを設定する。RFC に沿うアンカーもローカルな権限付与である。

各項目について、憲章版、問題、導入主体、草案版、採用記録、未解決の異議、合意、安全分析、依存、OID、テスト、独立実装、登録対応、利用側設定、フォールバック、観測結果を保存すべきだ。

Sources