おはようございます！
GMOコネクトの名もなきエンジニアです。
よろしくお願いします！
日刊IETFは、I-D AnnounceやIETF Announceに投稿されたメールをサマリーし続けるという修行的な活動です！！
今回は、2026-05-06（UTC基準）に公開されたInternet-DraftとRFCをまとめました。投稿数が多かったため2部構成でお届けしており、こちらはPart 1（全2部構成のうちの1部目）になります。
本Partに収録したInternet-Draftは20件、RFCは0件です（本日合計はI-D 33件、RFC 0件で、Part 2に残り13件のI-Dを掲載しています）。
参照先:
📌 個人的な推しはUse of ML-DSA in TLS 1.3になります。NIST FIPS 204のML-DSAをTLS 1.3のsignature_algorithms拡張で素直に交渉できるようになっていく仕事は、PQCを実運用にきちんと落としていく流れの中でも、特にじわじわ効いてくる一本に映りますね。同じ日にFN-DSA in TLS 1.3、SSHでのSphincs+/SLH-DSAも顔を出していて、PQC署名がプロトコル横断で一斉に整えられていく雰囲気を、お腹いっぱい味わえる日になっていますよ。
サマリー
今日のPart 1はInternet-Draftが20本、AIエージェントの認可、PQC署名、身元と鍵の運用が広く厚く積み上がる構成です。AAuthのプロトコルとブートストラップ、Budget Required（HTTP 427）、MCPのDNSディスカバリ、ZTDNAIDのURIスキームなど、機械が動くための「身元と権限の地続き」が一気に整う日になりました。加えて、TLS向けML-DSAとFN-DSA、SSH向けSphincs+/SLH-DSA、CMS向けComposite ML-KEM、RPKIのCCRとTAタイブレーカ、STIR、MLSのSD-CWTといった鍵と身元の足腰も並びます。
Hot Topics
まず一本目に注目したいのはHTTP 427 Budget Requiredになります。「クレデンシャルを持っているかどうか」とは独立に、「どの決済レール経由でいくらまで使ってよいか」をきちんとプロトコル側で整える発想で、AIエージェントが真面目にお財布を持ち歩く時代を見据えた、なかなか野心的な提案にしっかり仕上がっていますね。もう一本はAAuth Protocolで、身元ベース、リソース管理、PSアサート、フェデレーテッドの4モードを並べて、エージェント認可の地図を改めて描き直しに行く野心作です。
投稿されたInternet-Draft
Compliance Profile of Signed Action Receipts for AI Agents
AIエージェントが下したアクセス制御判断を、機械可読な証跡として残す署名付きアクションレシートに対し、多法域コンプライアンスプロファイルを定義する文書のrev 03です。EU AI ActとDORA、米国側ではNIST AI RMF、Colorado AI Act、Texas Responsible AI、NY DFS、HIPAAセキュリティルール、SEC Rule 17a-4、CIRCIAなど、レシートを多面的な規制要件へ写像します。OPTIONALからREQUIREDへの昇格、保管下限、RFC 3161かOpenTimestampsのタイムスタンプアンカ、拡張フィールド2件追加が骨子です。
draft-marques-asqav-compliance-receipts-03
Protocol 427: An HTTP Budget-Required Status Code with Post-Quantum-Signed Budget Attestations
日々ネットでお金を使うAIエージェントが増えてきた現状を踏まえ、従来のHTTP認証や決済が「資格を持っているか」と「どの決済レール経由でいくらまで使ってよいか」を混同している点を切り分ける文書です。HTTPステータスコード427（Budget Required）、Budget認証スキーム、CBOR符号化されたBudget-Attestationエンベロープを定義し、主署名にML-DSA-87、オプションのレール鍵署名にハッシュベースのステートレス署名を併用する設計になっています。426 Upgrade Requiredを使ったバージョン交渉も添える、なかなか野心的な一本ですね。
draft-mcgraw-httpapi-agent-budget-00
AAuth Bootstrap Guidance
AAuthというエージェント認可プロトコルにおいて、エージェントを登録しAAuthエージェントトークンを発行する側、いわゆるAgent Provider向けの参考情報をまとめた文書です。プラットフォームごとの鍵の扱い、任意のプラットフォームアテステーションの組み込み、エージェント識別子の戦略、リフレッシュパターンといった、運用に直結するテーマが具体的に整理されています。ここで述べられている内容は規範的なプロトコルではなく、相互運用可能なAP実装が採用ないし応用できる共通パターンの形で書かれており、実装ガイドの立ち位置をきちんと示しているのが好印象ですね。
draft-hardt-aauth-bootstrap-01
AAuth Protocol
AAuth、すなわちエージェントとリソースの間の認可とアイデンティティクレーム取得を扱うプロトコルを定義する文書です。リソースアクセスのモードとして、身元ベース、リソース管理（2者）、PSアサート（3者）、フェデレーテッド（4者）の4種を整理し、エージェントガバナンスを直交するレイヤとして据える整理が骨子です。HTTPメッセージ署名と鍵ディスカバリのための同伴ドラフト、HTTP Signature Keysの仕様にきちんと土台を置く設計で、OAuthの後ろに広がるエージェント時代のための受け皿を、本気で組み立てに行く一本ですね。
draft-hardt-oauth-aauth-protocol-01
Discovery of Model Context Protocol Servers via DNS TXT Records
Model Context Protocol、MCPサーバをDNS TXTレコードでディスカバリする仕組みを定義する文書のrev 03です。_mcp.はMCPサーバ自身の存在、エンドポイントURL、トランスポート、暗号身元、能力プロファイルを掲示します。_org-alter.はドメイン運営組織の身元を、_alter.は個人の~handleとEd25519署名済みの身元エンベロープを公開します。DNSSEC検証とDANE TLSAでの葉証明書ピン留めも要件に含まれ、HTTPSラウンドトリップなしで軽量にブートストラップできる設計ですね。
draft-morrison-mcp-dns-discovery-03
The 'ztdnaid' URI Scheme for Zero-Trust Digital DNA Identifiers (ZTDNAID)
ゼロトラストアーキテクチャ実装の中で、グローバルにユニークかつ暗号的に検証可能なDigital DNA Identifier、いわゆるZTDNAIDを表現するための「ztdnaid」URIスキームを定義する文書です。ZTDNAIDはエンティティの不変かつユニークなDigital DNA Recordを、認証や認可、アテステーション、トラストレジストリ参照に使えるリゾルブ可能な識別子に束ねます。SAG-CTRのようなトラストレジストリと組み合わせて使う想定で、決定的解決とオフライン検証、安全な参照解除の三点を支える設計が骨子になっていますね。
A Comprehensive Roadmap for OAuth 2.0 Standards and Drafts
OAuth 2.0のエコシステムは、RFC 6749の公開以来、拡張仕様、セキュリティBCP、アプリ別プロファイルが膨大に積み上がっており、実装者やアーキテクト、セキュリティ監査担当者から見ると見通しが効きづらい状況になりがちです。本ドラフトはこの広大な現状を一望できるロードマップとして、主要RFCと活発なInternet-Draftを機能領域ごとに分類し、相互の関係を整理し、進化の文脈を解説します。使うべき仕様の選択、最新ベストプラクティスの追従、今後の方向性の見通しを、ひとまとめに掴めるようにする実用的な一本ですね。
Push-Based Delivery For Multiple Security Event Tokens (SET) Using HTTP
Security Event Token、SETを複数まとめてHTTP POSTで届けるための作法を定義する文書です。受信側の指定エンドポイントへ、TLS上のHTTP POSTで複数SETをHTTPボディに収めて送り、受信側はHTTPレスポンスで成功と失敗を表明する、シンプルな送り出し型設計が骨子です。一件ずつ運ぶよりも、明らかに通信コストが下がる現場のニーズに素直に応える形になっており、SCIMやリスクシグナル連携などのSET活用の現場で、地味にじわじわ効いてくるアップデートに仕上がっていますね。
draft-deshpande-secevent-http-multi-set-push-02
Messaging Layer Security Credentials using Selective Disclosure JSON and CBOR Web Tokens
MLSプロトコルではクライアントを署名鍵ペアで認証するためのCredentialが要りますが、本ドラフトはそのCredentialとして、Selective Disclosure CBOR Web Token（SD-CWT）と、Selective Disclosure JSON Web Token（SD-JWT）の両形式を採用するMLS Credentialを定義します。これらのトークン形式はホルダが自分自身のクレームを選択的に開示でき、改ざん耐性とホルダ鍵への暗号バインディングを併せ持つ設計で、MLSのクライアント認証へ強い属性開示モデルを持ち込みやすくする一本ですね。
draft-mahy-mls-sd-cwt-credential-02
KerPass EPHEMSEC One-Time Password Algorithm
KerPass EPHEMSECは、One-Time PasswordとOne-Time Keyを生成するアルゴリズムで、従来のOTPが静的な共有秘密にだけ依存しがちなところに、公開鍵暗号を持ち込み認証サーバへの安全な配備を整える設計です。生成したOTPやOTKを文脈データに束ねる仕組みもあり、信頼されたエージェントが文脈を注入する場合、フィッシングや中間者攻撃への耐性が引き上がります。同期ヒントを出力に埋め込む組み込み時刻同期の仕組みも持ち、PAKEやTLS-PSKと組み合わせるときの値合わせがすんなり成立する点が地味にうれしいですね。
draft-mvieuille-kerpass-ephemsec-03
Use of ML-DSA in TLS 1.3
TLS 1.3における認証用に、PQC署名スキームのML-DSA、すなわちFIPS 204の使い方を定義する短めの文書です。TLS 1.3のsignature_algorithmsとsignature_algorithms_cert拡張で、ML-DSAをどう交渉し、証明書チェーンの検証時にどう扱うか、コードポイントの割り当てや変数長の取り回しといった実装上の作法をきちんと整えます。従来の楕円曲線署名と並べて、PQC署名をTLSで運ぶための土台を1本にまとめる役割で、PQC移行の周辺ドラフト群と並べて押さえておきたい基幹的な一本ですね。
Use of FN-DSA in TLS 1.3
NISTがFIPS 206として標準化を進めているNTRU格子ベースのPQC署名アルゴリズムFN-DSAを、TLS 1.3の認証で使うための交渉作法を定義する文書です。signature_algorithmsとsignature_algorithms_cert拡張を使い、ハンドシェイクとサーバ証明書の双方でFN-DSAを扱えるようにし、コードポイントの割り当てとアルゴリズム識別子の整合を整えるのが骨子です。ML-DSAやSLH-DSAと並ぶPQC署名の選択肢として、TLSの運用シナリオに地味に効いてくる、足腰強化系の一本に仕上がっていますね。
Stateless Hash-Based Signatures for Secure Shell (SSH)
SSHプロトコルにSphincs+/SLH-DSAのデジタル署名を持ち込む方法を定義する短めの文書です。SLH-DSAはハッシュベースのステートレス署名で、PQC耐性を素直な構成で備える性質を持ちます。本ドラフトはこれをSSHでスタンドアロン使用するパターンと、Ed25519あるいはEd448とのハイブリッドで使うパターンの両方をカバーします。SSH鍵運用の長寿命を考えると、PQC側へ静かに足場を移す動きが今のうちから整っているのは現場として心強く、いざというときに切り替えやすい備えになる地味で大事な一本ですね。
draft-josefsson-ssh-sphincs-02
Composite ML-KEM for use in Cryptographic Message Syntax (CMS)
Composite ML-KEMはML-KEMをRSA-OAEP、ECDH、X25519、X448と組み合わせる構成を定義しており、本ドラフトはその使い方をCMS（Cryptographic Message Syntax）で扱う作法を整える内容です。CMSにおけるKEM採用の枠組み、KEMRecipientInfo構造（RFC 9629）の上にComposite ML-KEMを乗せる規約として書かれており、PQC移行期に従来鍵交換と並走させるハイブリッド構成を、CMSベースのメール暗号や文書暗号で素直に運用できるよう整える、地味だけれどメッセージング基盤の足腰を確実に強くする一本ですね。
draft-ietf-lamps-cms-composite-kem-01
A Profile for Resource Public Key Infrastructure (RPKI) Canonical Cache Representation (CCR)
Resource Public Key Infrastructure、RPKIで「ある時点の検証済みキャッシュ状態」を表現するための、Canonical Cache Representation（CCR）コンテンツタイプを定義する文書です。CCRはDER符号化のデータ交換形式で、RPKIキャッシュの状態を様々な側面から表現できる作りになっています。コンパクトかつ多目的なフォーマットとして設計されており、監査トレイル、解析パイプライン、検証済みペイロードの配信といった用途で素直に効いてくる、ルーティングセキュリティ運用に地味に効くタイプの一本ですね。
draft-ietf-sidrops-rpki-ccr-04
Tiebreaking Resource Public Key Infrastructure (RPKI) Trust Anchors
RPKIにおけるTrust Anchor、TAは自己署名X.509 CA証明書としてしっかり表現されますが、時間が経つにつれてRelying Party、RPは同じTA運用者から複数の有効なTA証明書を持ってしまう状況がしばしば出てきます。本ドラフトはRPが認証パス検証のためにどのTA証明書を選ぶかを決めるためのタイブレーキング方式を提案し、運用上のあいまいさをきちんと取り除きにいきます。RFC 8630を更新する位置づけで、RPKIの足元を着実に整える、地味だけれど実務にすぐ効くタイプの一本ですね。
draft-ietf-sidrops-rpki-ta-tiebreaker-03
Call Placement Service (CPS) URI Certificate Extension for STI Certificates
STIR証明書に、Call Placement ServiceのHTTPS URIを伝えるための、非クリティカルなX.509 v3拡張を定義する文書です。STIR PASSporTの発信側と検証側が、CPSのエンドポイントを単一の証明書参照だけで素直に発見でき、Out-of-Band PASSporTの取得経路へ滑らかにたどり着けるようにします。CPSエンドポイントURIを発見する手段を新たに追加するだけの最小設計で、既存のSTIR証明書とOOB APIに完全な後方互換を保つ、電話網の認証基盤に静かに効いてくる地味で実用的な拡張ですね。
draft-sliwa-stir-cert-cps-ext-02
Automatically Connecting Stub Networks to Unmanaged Infrastructure
スタブネットワークを隣接するインフラネットワークへ自動接続するための実践集を記してくれている文書で、具体的には制約あるIoTネットワークなど、隣接インフラ側のリンク（たとえば家庭内ネットワーク）と、スタブネットワーク上のデバイス間でサービスディスカバリと到達性の機能パリティを揃えたい場面に焦点が当たっています。プレフィックス委譲、ルート広告、サービスディスカバリの突き合わせ、複数経路の扱いまで、現場で実装するときに踏みがちな段差を一つずつ丁寧に均していく作りで、IoT配線の地味で大事な土台になる一本ですね。
A Top-level Domain for Private Use
私的用途のためのトップレベルドメインとして「internal」を、きちんと正式に位置づけてくれている、短めながら影響範囲のしっかり広い文書になっていますね。社内利用や閉域網でのDNS名前空間運用において、外部DNSと衝突しない安定した文字列を欲しがる現場ニーズに応える形で、パブリックインターネットには委譲されないTLDとしてinternalを規定する筋立てです。地味で短い仕様書ですが、社内DNSやキャッシュの設計、企業ネットワークの運用に与える影響は大きく、長く参照されるタイプの一本になりそうですね。
SFC: Self-Describing Resilient Container File Format
Self-Describing Resilient Container、SFC形式のrev 01で、不安定で帯域制約のある通信路、非同期経路、物理メディア手渡し搬送、複数セッション転送、異種経路混在の配送向けに設計された汎用バイナリコンテナを規定します。ファイルやディレクトリツリーを独立にアドレス可能で自己同定可能なチャンクへ分解し、各チャンクが単独で完全性を検証できるだけのメタデータを背負う作りで、再構成にはGlobal Headerが要る区別を保ちます。Image、Split Transport、HTTP Hints、Preprocessing、Directoryの5プロファイル併設です。
発行されたRFC
本日発行されたRFCはありませんでした。
編集後記
AIエージェントがお金を実際にじゃんじゃん使い、決済レールにきちんと乗り、APIの向こうのリソースを動かしていく時代の足場を、本当にいよいよ皆で本気になって組み上げ始めたなあと、Part 1を読みながらしみじみと感じ入ってしまう一日になりましたね。PQC署名がTLS、SSH、CMSにきちんと出揃い、RPKIやSTIR、MLSの足元も静かに整理されていく光景は、派手ではないですが「機械同士の信頼の仕組み」が層を増やしながら本気で組み上がっている、IETFらしい朝練みたいな心地良さが漂う一日でした。
最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。