おはようございます！
GMOコネクトの名もなきエンジニアです。
よろしくお願いします！

日刊IETFは、I-D AnnounceやIETF Announceに投稿されたメールをサマリーし続けるという修行的な活動です！！
今回は、2026-06-26（UTC基準）に公開されたInternet-DraftとRFCをまとめました。

Internet-Draft: 本Part20件（本日のInternet-Draft合計59件）
RFC: 本Part0件（本日のRFC合計1件）

参照先:

その日のサマリー & Hot Topics

2026年6月26日分の前半は、エージェントの行動を人間の認可として証拠に残すEMILIAプロトコルの一群が主役です。認可レシート、エンフォースメントポイント、長期保存の証拠記録、姿勢アドバイザリのEyeまで、実行前に名前付きの人間が承認した事実をオフラインで検証する層が揃って提案されました。耐量子の話題も濃く、IKEv2のPQ/Tハイブリッド認証やDNSSECのKSK/ZSKアルゴリズム分割が、大きくなる署名や鍵への現実的な対処を示します。SCITTのREST APIやBlind BBS署名、RSA実装のサイドチャネル指針など、暗号運用の地道な整備も横に並びました。
目玉はEMILIAプロトコルの設計思想です。認可レシートは、自分の署名鍵を持つ承認者が行動ハッシュやnonceへ署名し、Merkleでアンカーした証跡をネットワーク接続なしで検証できるようにします。Eyeアドバイザリは姿勢を厳しくする方向にのみ働き、単独で認可のゲートにはならないという安全不変条件を規範として置きました。耐量子側ではDNSSECのアルゴリズム分割が興味深く、大きなアルゴリズムをKSKに閉じ込め、通常応答を左右するZSK署名は小さく保つ発想で応答の肥大を抑えます。IKEv2のPQ/Tハイブリッド認証も、片方のアルゴリズムさえ安全なら認証が保たれる設計で、移行期の現実解を示します。

投稿されたInternet-Draft

Algorithm-Split DNSSEC: KSK/ZSK Algorithm Separation

耐量子のDNSSEC署名は、広く使われる楕円曲線系より鍵や署名がはるかに大きくなります。頂点のDNSKEY RRsetはKSKとZSK両方の鍵材料を運ぶため肥大しますが、問題はゾーンの残りまで大きくする必要があるかです。KSKの署名はDNSKEY RRsetにしか現れず負担はわずかですが、ZSKの署名は他の全RRsetに現れ応答の大きさを左右します。大きなアルゴリズムをKSKに限りZSKには小さい署名を使えば、負担をDNSKEY RRset内に閉じ込められます。全アルゴリズムでゾーンを署名する規則を緩め、RFC4035とRFC6840を更新します。
Draft Link

Verifiable, Scope-Bound Advisories for Authorization Posture (EMILIA Eye)

名前付きスコープの認可の姿勢が変化したことを伝える、スコープ拘束の通知であるEMILIA Eyeアドバイザリを定義します。署名済みでオフライン検証でき、別スコープへの再利用を防ぐ拘束ハッシュを持ちます。clear、caution、elevated、review_requiredの姿勢と、log、step_up_authなど推奨アクションを表現します。安全不変条件は規範的で、アドバイザリ単独が行動のゲートになってはなりません。シグナルは姿勢を厳しくする方向にのみ働き、強い認証を求められますが、それ自体で認可は成立しません。RFC8417のペイロードで運ぶ実験的文書です。
Draft Link

An Enforcement-Point Profile for Authorization Receipts

authorization-receiptドラフトが規定する検証コアの上に構成する、Enforcement-Point（PEP）向けプロファイルを定義します。高リスクなエージェント行動に対し、Policy Enforcement Pointへ小さく安定した契約を与えます。allow、allow_with_signoff、deny、observeモードという決定語彙と、全決定がオフライン検証可能な認可レシート（EP-RECEIPT-v1）へ拘束される要件を含みます。不確実なときはfail-closedとし、拒否の決定は状態変更より前に効力を持つ不変条件を示します。
Draft Link

Long-Term, Crypto-Agile Preservation of Authorization Evidence (EP-EVIDENCE-RECORD)

高リスク行動を誰が認可したかの記録は、DORAで5年、HIPAAやSEC 17a-4で6年など長期保存が規制で求められています。記録保護に使う署名やハッシュのアルゴリズムは時間とともに弱まり、今日Ed25519とSHA-256で署名したレシートも保存期間の途中で破られる恐れがあります。本ドラフトはEP-EVIDENCE-RECORDという任意プロファイルを定義し、RFC4998の流儀の更新チェーンで、EMILIAの認可レシートなどの検証可能性を老朽化を越えて保ちます。各更新は、古い方式が破られる前に直前の更新全体を新しい強いアルゴリズムで時刻証明します。
Draft Link

Authorization Receipts for High-Risk Agent Actions

EMILIAプロトコル（EP）の認可レシートを定義します。名前付きで説明責任を負う人間の承認者を、実行前の一つの高リスク行動へ暗号的に結び付ける基本要素です。自分の署名鍵を持つ承認者が、行動ハッシュやポリシー参照、一度限りのnonce、有効期間を含む正規のAuthorization Contextへ署名します。生成されるTrust ReceiptはMerkleでアンカーされ完全にオフラインで検証でき、EP運用者やログへ接続せずに、承認された事実を確認できます。発起者は自分の行動を承認できないという職務分掌を強制し、TLA+とAlloyで機械検証されています。
Draft Link

The EMILIA Protocol Architecture: A Human-Authorization and Oversight Evidence Layer for Agentic and Autonomous Systems

自律的でエージェント的なシステムは、送金や記録変更、便益の割り当てといった不可逆な行動を機械速度で行う一方、説明責任を確立する証拠系は人間の速度に合わせて作られてきました。規制、監査、保険の各分野で同じ要件が繰り返し現れ、同じ成果物が欠けています。名前付きで説明責任を負う人間が特定の行動を実行前に認可したという、オフライン検証可能な証明であり、運用者を信頼せずに第三者が確認できるものです。本ドラフトはEMILIAプロトコル（EP）のアーキテクチャ概観であり、識別や委譲への層の位置を定め、構成要素仕様を束ねます。EPは認可を証明しますが、行動が合法だったとまでは証明しません。
Draft Link

Post-Quantum Traditional (PQ/T) Hybrid PKI Authentication in the Internet Key Exchange Version 2 (IKEv2)

IPsecの領域で暗号学的に意味のある量子計算機の影響を受けるのが、RSAやECDSAなど従来の非対称アルゴリズムに基づくIKEv2認証です。ML-DSAのようなPQC署名アルゴリズムは存在しますが、新しい暗号が実地で成熟するには時間がかかり、証明される前に新アルゴリズムだけへ頼るのは危険が伴います。本ドラフトはIKEv2向けに、従来とPQCの両方の署名アルゴリズムを取り入れたハイブリッドPKI認証方式を記述します。方式に含まれる片方のアルゴリズムさえ安全であれば認証全体が安全であり続けるよう設計されており、移行期の認証を頑健にする手順が示されています。
Draft Link

The Vaara Receipt: A Recomputable Receipt Format for Decisions About Agent Actions

vaara.receipt/v1を規定します。エージェント行動についての決定を、その根拠となった証拠へ、また任意で外部のタイムスタンプアンカーへ結び付ける、署名済みで独立に再計算できる記録です。JCSで正規化されるため、第三者は発行者へアクセスせずダイジェストを再計算し署名を検証できます。信頼はroot-agnosticで、ハードウェアの信頼実行環境の有無に関わらず同じ記録が検証可能であり、IETF RATSのEntity Attestation Resultとして再表現できます。下流の仕様は本文書のバージョンへ固定して証拠スキーマを足すプロファイルを定義します。
Draft Link

Non-source-routed Multicast in SR Networks

セグメントルーティング（SR）のアーキテクチャでは、ユニキャストのフローはパケット内の明示的な経路に従い、網内のフローごとの状態を持たずにソースルーティングできます。結果として、ユニキャストのフロー状態を伝える各プロトコルも不要になります。マルチキャストの場合、トラフィックはソースルーティングも非ソースルーティングもあり得ます。本ドラフトはSR網における非ソースルーティングのマルチキャストの選択肢を、木ベースのマルチキャスト技術やBIER、各種のSR固有解を含めてまとめます。SRの原理に照らして各解の長所と短所を列挙し、検討材料とします。
Draft Link

A YANG Data Model for IS-IS Application-Specific Link Attributes and Flexible Algorithm

IS-ISのApplication-Specific Link AttributesとFlexible Algorithmを扱うためのYANGデータモデルを定義する文書です。両機能をネットワーク管理者が標準化されたインタフェースで設定し、状態を取得できるようにする目的で、モデルの構造を簡潔にまとめています。文書自体は短く、対象とする二つの機能に絞って規定範囲を定めており、IS-ISの運用にYANGベースの管理を組み込みたい実装者にとっての基礎資料となる短い規定です。今後の拡張を見据えた土台としても参照できる内容になっています。
Draft Link

Group Address Allocation Protocol (GAAP)

マルチキャストの通信で使うグループアドレスを、分散的な仕組みで割り当てるプロトコルGAAPを定義する文書です。ガップと発音するこの方式は、基本の割り当てに集中管理のサービスを必要とせず、設定もごく少なくて済む点が特徴となっています。暗号化や管理スコープを伴う配備を行う場合には、追加の設定が必要になることもあります。マルチキャストパケットを送受信する際に一意なグループアドレスを必要とする参加者同士の間で動作するよう組み立てられ、IPv4とIPv6の両方の網に合わせて設計されました。既存プロトコルの拡張ではなく、単純で軽量な新しい代替案です。
Draft Link

Populating resolvers with the root zone

DNSの再帰リゾルバを運用する事業者にとって、堅牢でプライバシーに配慮したサービスを利用者へ届けることは大切な課題です。しかし攻撃を受けた際などにルートサーバから応答を得にくくなる問題や、最寄りのルートサーバまでの往復時間が長くなる問題、送信するクエリにまつわるプライバシーの懸念が壁として立ちはだかります。すでにキャッシュしたルートゾーン全体の複製をリゾルバ自身が提供するだけで、こうした課題はまとめて解消できます。複製の取得と保持の方法、内容が古くなった際の検知手順、エラー発生時の対処までをまとめた文書です。
Draft Link

Supply Chain Integrity, Transparency, and Trust (SCITT) Reference APIs

サプライチェーンの完全性と透明性、信頼を扱うSCITTアーキテクチャにおいて中核をなすSCITT Transparency Serviceについて、異なる実装同士が相互に運用できるようにするためのREST APIを定めた文書です。HTTPで扱うリソースの構成や、要求と応答それぞれのメッセージの形式、エラーが起きた際の処理までを規定し、サービスを実装する側が参照すべき仕様として整理されています。ソフトウェアの来歴や証跡を扱うSCITTの枠組みを、特定の実装に縛られない形で相互運用できるようにする点が主眼です。
Draft Link

Blind BBS Signatures

BBS署名方式に対する拡張を定めた文書で、ブラインド署名と呼ばれる仕組みを支える内容です。ブラインド署名とは、署名者自身がその中身をあらかじめ知らないメッセージに対して署名を行う仕組みを指します。既存のBBS署名の枠組みに手を加えることで、メッセージの内容を伏せたまま検証可能な署名を作り出せるようにする拡張が、この文書の中で定義されています。署名を求める側と署名者との間で、中身を明かさずに済ませたい場面は珍しくなく、この拡張はそうした場面を技術的に支える仕組みです。プライバシーを保ちながら署名の正当性を確かめたい場面で使われる見込みです。
Draft Link

Additional Cryptographic Algorithms For Use With TCP-AO

RFC5926が定めるTCP-AO向け暗号アルゴリズムの一覧に、新たな選択肢を加える文書です。今回追加されるのはHMAC-SHA256-128とKMAC256-128という二つのメッセージ認証コードアルゴリズムで、それぞれに対応する鍵導出関数もあわせて定義されています。ここで扱うMACアルゴリズムはいずれも128ビット、バイト数にして16バイトのMACを生成する仕様です。この16バイトのMACをTCP-AOへ符号化する際には、TCPオプションとして使える40バイトのうち20バイトが消費されることになります。
Draft Link

Implementation Guidance for the PKCS #1 RSA Cryptography Specification

RFC 8017に追加する内容を規定した文書で、RSA暗号の実装者に向けてサイドチャネル攻撃から身を守るための指針を示しています。RSAES-PKCS-v1_5という暗号方式については、その使用を勧めない立場を明確にしたうえで、脆弱なAPIを利用する側から生じかねないサイドチャネル攻撃を避けるための代替となるdepaddingアルゴリズムを提示しています。実装者がどのような点に気を配ればよいのかを具体的に示すことで、RSA実装全体の安全性を高めることを狙っています。CFRGでの検討を経てまとめられた成果物です。
Draft Link

A Deprecation Manifest for Field-Level Lifecycle Signalling in HTTP APIs

RFC 9745とRFC 8594が定めるDeprecationとSunsetのHTTP応答ヘッダは、リソースが非推奨になったことや将来そうなること、削除の時期をサーバ側から伝える手段です。ただしこれらはリソース単位で働くため、要求や応答に含まれる個々のメンバーごとのライフサイクルまでは表現できません。本ドラフトはこの隙間を埋めるものとして「application/deprecations+json」というメディア型を定義し、要求や応答の特定のメンバーについて非推奨と廃止予定を宣言するマニフェストを提案しています。既存のリンク関係から発見できる点も特徴です。
Draft Link

Self-Certifying Identity and Capability-Based Delegation for Autonomous AI Agents

自律的に動くAIエージェント同士が安全に通信するための識別と委譲の枠組みを提案する文書です。クライアント側のAIエージェントやサービス側のAIエージェント、Agent ProviderやAgent Brokerといった関係者の間で、暗号的に検証できる識別情報を保持するTrustful Mutable Storeという仕組みを導入しています。公開鍵から導かれる自己証明の識別子を、DNSを使うものとIPFSを使うものの二通りで実現し、エージェントへ軽量で分散的な識別を与える設計です。名前と暗号的な識別、信頼できる仲介者を組み合わせるモデルとして示されます。
Draft Link

Registry and Signature Agent card for Web bot auth

DIRECTORYの仕組みを使う署名エージェントが自らを説明するために公開する、Signature Agent Cardと呼ぶJSONメタデータ文書を定義しています。このカードには識別情報や利用目的、想定するレートの目安、暗号鍵といった内容が記されます。パラメータはOAuthのDynamic Client Registration Metadataレジストリから引き継がれ、CIMDと同じ名前空間にweb_bot_authという単一のオブジェクトを加える形で拡張しています。このオブジェクトをIANAへ登録し、そのメンバーを管理するレジストリも新たに設けました。
Draft Link

HTTP Message Signatures for automated traffic

HTTP Message Signaturesという仕組みを用いて、自動化された通信を識別するためのアーキテクチャを説明する文書です。自動的にリクエストを送信するHTTPクライアントが、そのリクエストに対して暗号的な署名を付けられるようにし、受け取るサーバ側は署名をもとに送信元の識別を確信を持って検証できるようにすることを目的としています。署名という仕組みを軸に据えることで、送信者が名乗る身元とリクエストの中身を結び付け、なりすましや改ざんを見分けやすくする仕様となっています。送信の自動化が広がる中で、識別の確からしさを高める試みといえる内容です。
Draft Link

発行されたRFC

本日発行されたRFCはありません。

編集後記

エージェントが機械速度でお金を動かし記録まで書き換えてしまう時代に、実行前に人間がちゃんと承認したという証拠を、運用者を信じなくても第三者がオフラインで確かめられる形で残そうというEMILIAの発想には、資料を読みながら何度も思わず膝を打ってしまいました。証拠記録をアルゴリズムの老朽化を越えて更新チェーンで守り抜く仕組みや、姿勢の変化を伝えるEyeが単独では認可のゲートにならないと言い切る潔さまで揃っていて、五年先や六年先の監査まで見据えた設計の周到さに、同じエンジニアとしてあらためて背筋が伸びる思いがしています。

最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。

お問合せ: https://gmo-connect.jp/contactus/