3
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

日刊IETF (2026-06-23) AIエージェントの行動を署名レシートで残す提案が相次いだ日 (Part1/3)

3
Posted at

こんばんは!
GMOコネクトの名もなきエンジニアです。
よろしくお願いします!

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

  • Internet-Draft: 本Part20件(本日のInternet-Draft合計61件)
  • RFC: 本Part0件(本日のRFC合計0件)

参照先:


その日のサマリー & Hot Topics

  • 2026年6月23日分の前半は、AIエージェントの行動をどう記録し、どんな条件で受け入れるかという文書が目立ちました。SCITTを使った行動レシートのプロファイル、異種の資格情報をまとめて検証する仕組み、セッションに束ねたエージェント識別の受け入れ条件、エージェントを発見する階層化プロトコルなどが並びます。耐量子ではNTRUの考慮事項とACMEでPQCへの構えを表明するプロファイルが登場しました。SCIONの制御プレーンPKIやBFDの改訂、標準化過程そのものを更新する文書、北米の電話番号を11桁へ広げる提案まで含まれ、幅の広い一日です。
  • 注目はSCITTを使ったAIエージェント行動レシートのプロファイルです。COSE_Sign1の署名済みステートメントをJCSで正規化してハッシュチェーンでつなぎ、Transparency Serviceへ登録することで、自己署名のチェーン単独では得られない非二枚舌性や末尾切り詰めの検知まで得る設計になっています。おもしろいのは主張の狭さで、記録が改ざんされていないことだけを述べ、エージェントの判断が正しかったとも、記録された入力が真実だったとも主張しません。検証できることとできないことを最初に切り分ける態度は、この分野の文書としてとても誠実だと感じます。

投稿されたInternet-Draft

A SCITT Profile for AI-Agent Action Receipts

自律的に動くAIエージェントの行動レシート向けに、IETFのSCITTアーキテクチャを絞り込んだプロファイルです。誰のために何を、どんなポリシーの下でどう判定したかを、改ざん検知可能で署名済み、オフライン検証可能な記録として残します。各レシートはRFC9052のCOSE_Sign1署名済みステートメントで、RFC8785のJCS正規化とハッシュチェーン順序づけを経てSCITT Transparency Serviceへ登録し非二枚舌性を得ます。主張はあえて狭く、正しさや安全性、入力の真実性までは述べません。判定を再現するオフライン再実行機能は今回の対象外です。
Draft Link

Object-Oriented Programming Standard for Pure C

純粋なC言語だけでオブジェクト指向プログラミングを行うための標準、RFC-OOP-Cを定義する提案です。命名規則やクラス構造マクロ、メソッドマクロ、メモリ割り当てパターン、ライフサイクル管理、構造体のバージョニング、適合性チェッカーRFC_Checkerのインターフェースなどを規定します。対象はC11すなわちISO/IEC 9899の2011年版で、対応ツールチェーンを持つマイクロコントローラやプラットフォーム全般に適用できます。ベアメタルやFreeRTOS、embOSと互換のスレッド安全性やメモリ割り当て戦略といった補足指針も添えています。
Draft Link

SCION Control Plane PKI

経路を意識したドメイン間ネットワークアーキテクチャSCIONの制御プレーン向け公開鍵基盤、CP-PKIの信頼概念と設計を扱う文書です。暗号材料の扱いと経路情報配布時のメッセージ認証をCP-PKIが担う仕組みを説明します。Isolation Domainに根ざした局所的な信頼モデルを導入し、証明書の種類を定義したうえで、Trust Root Configurationの構造や形式、ライフサイクルを規定し、CP-PKIインフラの導入と維持に関する実践的な指針も示します。Internet Standardではなく、IETFの正式なレビューはまだ受けていません。
Draft Link

Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)

IPv4およびIPv6上で、単一のIPホップに対してBidirectional Forwarding Detectionプロトコルを用いる方法を記した文書です。BFDは対向するシステム間の転送経路が生きているかを短い周期で検知する仕組みで、リンクや隣接ノードの障害を素早く見つける目的で使われます。単一ホップという限定された構成に絞ることで、実装や運用の前提をはっきりさせています。この文書はRFC5881を廃止するものとされ、既存の実装や記述を最新の内容へ置き換える改訂版という性格を持ちます。長年使われてきた仕様の更新にあたる一本です。
Draft Link

Heterogeneous Credential Verification for Workload and Agentic Systems

利用者や組織のために動くAIエージェントを含む、複数システムにまたがる環境のワークロードは、1つのリクエストの中で異種の資格情報を複数提示することが増えています。ワークロードのアイデンティティトークンやOAuthアクセストークン、Verifiable Presentation、X.509証明書などで、発行する権威も形式も保証の意味も異なります。こうした集合を受け取る側には、共通の表現方法も、種類を識別する方法も、権威ある検証者を決める方法も、検証結果を一貫してまとめる方法もありません。本文書は受信時にこの集合を処理する仕組みを定義します。
Draft Link

A Core Acceptance Profile for Session-Bound Agent Identity

セッションに束ねられたエージェントのアイデンティティについて、検証者側が何を条件に受け入れるかを定めるコアな受け入れプロファイルです。暗号的に妥当な材料であっても、検証者の意図と異なるサービスやテナント、タスク、権限境界へ誤って受け入れてしまう取り違えを防ぐことを狙います。検証者は、権限付与や鍵の所持証明、TLSまたはexported authenticatorのセッション、鮮度と再生防止の状態、必要に応じたアテステーション結果、ポリシーのすべてが同一の相互作用を指すときにのみ受け入れます。ワイヤ形式や配備の選択はバインディングプロファイル側に委ねています。
Draft Link

Implementation Status of OAuth Identity Chaining and Transaction Tokens

OAuthワーキンググループが手がける2つのドラフト仕様、ドメイン間のアイデンティティチェーンとトランザクショントークンについて、オープンソースによる実装の状況を報告する文書です。各ドラフトについて、すべての規範的な節を、試験対象とした実装中の対応するソース位置へ対応づけ、その節を動かすテストの範囲をまとめています。あわせて親ドラフトごとに未解決の課題候補を1つずつ記録しています。報告はRFC7942の作法に沿ってまとめられたもので、2つの親ドラフトの編集者が参照し、日々の実装作業に活用することを想定して作られています。
Draft Link

Agent Discovery Protocol (ADP) v1.1 -- Well-Known Metadata and Interaction Layer

インターネット上のAIエージェントを発見し、検証し、やり取りするための階層化プロトコル、Agent Discovery Protocol v1.1を定義する文書です。DNSでの発見はDNS-AIDすなわちSVCBレコードへ委ね、Well-KnownなJSONメタデータ形式、Ed25519に基づくアイデンティティモデル、リアルタイム通信のAgent Gateway Protocolを組み合わせて規定します。分散的かつ段階的に導入できる設計で、クライアントは必要に応じてDNSからHTTP、さらにWebSocketへと段階を上げていきます。
Draft Link

NTRU KEM Security Considerations

ISO/IEC 29192-4 Amendment 2で標準化が進むNTRU鍵カプセル化機構について、セキュリティ上の考慮事項を丁寧にまとめた文書です。NTRUをいつ安全に使えるか、そしてどう使えば避けられるはずのセキュリティ後退を招かずに済むかを、プロトコル設計者や実装者が判断する助けとなるよう意図されています。派手な新提案というより、既存の鍵カプセル化機構を実際に組み込む際の落とし穴を整理し、判断材料を与える性格の文書となっています。標準化がまだ進行中の技術だけに、実装側の理解を後押しする狙いで書かれました。
Draft Link

A Proposal for Long-Term Expansion of the North American Numbering Plan (NANP) to 11 Digits

北米番号計画は、現在の割り当てと利用の傾向が続く前提のもとで、今後数十年のうちに利用できる電話番号資源が枯渇すると見込まれています。市外局番のオーバーレイや番号プーリングといった既存の緩和策はNANPの寿命を延ばしますが、運用の複雑さや利用者の混乱を増やしてもいます。本文書は、市外局番であるNPAを3桁から4桁へ広げることで、電話番号全体を10桁から11桁へ一律かつ長期的に拡張する案を示しています。後方互換性や固定長の番号体系、混乱を最小限に抑える多段階の移行戦略を重視し、議論を促す目的で書かれています。
Draft Link

Post-Quantum Cryptographic Agility Profile for ACME

RFC8555のACMEに対するプロファイル拡張を定義し、サーバーとクライアントがアカウント単位や注文単位でPQCへの構えを表明できるようにする文書です。拡張はACMEディレクトリにpqcAgilityメタデータを導入し、注文オブジェクトにも任意のpqcAgilityメンバーを加え、注文がアカウントの宣言した準備閾値を満たすか判定するサーバー側スコアリング機構を導入します。ACMEのコアな状態機械自体は変更せず、発見可能な能力メタデータと注文単位のポリシー指示を加えるにとどめました。マルチテナントのACMEサーバーには、アカウントをまたぐPQC構えの漏洩を防ぐテナント分離制御の実装を求めます。
Draft Link

The Internet Standards Process

インターネットコミュニティがプロトコルや手続きを標準化する際にたどる過程を定める文書です。標準化過程の各段階、文書を次の段階へ進めるための要件、過程で用いる文書の種類を規定し、知的財産権や著作権に関する扱いも盛り込みました。RFC 2026、RFC 5657、RFC 6410、RFC 7100、RFC 7127、RFC 8789、RFC 9282という一連の文書を廃止し、RFC 7475からの変更点も反映しています。長年運用されてきた標準化プロセスの規定を、現状に合わせて丁寧に整理し直した内容になっています。
Draft Link

Post-Stack MPLS Network Action (MNA) Header Specification

MPLSラベルスタックの後ろにNetwork Actionの符号化と付随データを運ぶための、Post-Stack MPLS Network Action(MNA)ヘッダー仕様です。MPLS Network Action Sub-Stack Specificationで定義されたIn-Stack MNA仕様を土台にしています。Network Actionは、パケット転送の判断に影響を与えたり、MPLSパケット内に追加のOAM情報を運んだり、利用者定義の操作を行ったりする用途に使えます。設計はRFC 9789で規定された枠組みに沿い、ラベルスタックの内側ではなく後ろ側に情報を置く構成を採りました。
Draft Link

Updates to SMTP related IANA registries

EMAILCOREワーキンググループがSMTP仕様の更新作業を進める中で、SMTP関連のIANAレジストリに情報の欠落や古い記載が残っていることが分かりました。この文書はそうしたレジストリのエントリを見直し、必要な更新を加えるものです。長く運用されてきた登録簿の記載を現状に合わせて整えることで、後続の仕様策定や実装が参照する際の正確さを高めます。地味な内容ながらもSMTPのエコシステム全体の基盤を支える整理作業であり、細かな不整合を一つずつ丁寧に潰していく地道な取り組みが着実に積み重ねられています。
Draft Link

The TLS TimeToken Secure Protocol (tttps://)

TLS TimeToken Secure Protocol(tttps://)を定める文書です。RFC8446のTLS 1.3に、暗号的に検証可能な時間的順序付けを加える拡張であり、ブロックチェーンに依存しない汎用の時間証明プロトコルとされています。地上網から深宇宙、SAGIN中継まで配備環境をまたぎ、単一の不透明なコンテキスト識別子と伝搬遅延に適応する階層を用いて、100ミリ秒未満の地上での順序付けから惑星間の光伝搬時間まで扱う設計です。順序に経済的価値がある場面ではチャネルの無作為性という前提が崩れると指摘しました。
Draft Link

A Framework for Fast Network Notifications

AIや機械学習の学習と推論から大規模なクラウドサービスまで、多くのネットワークアプリケーションは高帯域や低遅延、低ジッタ、最小のパケット損失を組み合わせた条件を求めています。これを満たせるかは、障害や信号劣化、輻輳へネットワークが素早く適応できるかにかかっており、既存の仕組みは遅すぎるか粒度が粗すぎるため、現代の転送ハードウェアが状態を検知し配布する時間尺度に追いつけないと姉妹文書は述べています。この文書はFast Network Notifications(FANN)の枠組みを示すもので、参照アーキテクチャや通知の役割、情報モデルをまとめています。
Draft Link

Enhanced Dual Stack: Automatic IPv6/IPv4 Selection Based on Performance

Enhanced Dual Stack(EDS)は、IPv6配備に伴う運用リスクと作業負荷を減らすためのホスト側の枠組みです。多くのアプリケーションは静的なアドレス選択規則でIPv6かIPv4かを選んでいますが、これは有用な基準であっても現在の到達性や性能の実測ではありません。IPv6が壊れていたり劣化していたりする状態で選ばれると、利用者は失敗や遅延に直面します。Happy Eyeballsを実装したアプリケーションではこのリスクは減りますが、従来のAPIを使う既存のアプリケーションは自動的には助かりません。EDSは新旧いずれでも性能に基づく選択を目指します。
Draft Link

A Profile for Source Origin Authorization (SOA) Service Profiles

Source Origin Authorization(SOA)というRPKIの新しいオブジェクトを定める文書です。AS間の送信元アドレス保護サービスで用いる、ASレベルのサービスプロファイルを公開するために使われます。SOAオブジェクトはデジタル署名された成果物で、公開元のAS、そのサービス上の役割、サービス記述子に加え、私的な同期チャネルを認証するためのブートストラップ情報、たとえばエンドポイントのアドレスや公開鍵を運びます。SOA自体は加入者と提供者の関係を作るものではなく、保護対象プレフィックスの認可でもなく、発見と検証を経て初めて成り立ちます。
Draft Link

Source Address Validation Using Source Origin Authorizations (SOAs)

ドメイン間の送信元アドレス検証をAS同士が協調して行うには情報共有の基盤が要るという前提のもと、二層の手法を示す文書です。第一層ではRPKIを、サービス発見や身元認証、私的チャネルを確立するための最小限のブートストラップ情報の伝達に用います。ここで使われるのが、暗号的に署名されたASレベルのサービスプロファイルであるSource Origin Authorization(SOA)です。加入者と提供者はそれぞれ自分のSOAプロファイルを公開し、具体的なサービス関係は発見、要求検証、提供者の受諾を経て成立します。第二層では、先行ASの情報を私的チャネル上で交換します。
Draft Link

An EAT Profile for Trustworthy Device Assignment

コンフィデンシャルコンピューティングにおけるデバイス割り当て(DA)は、ネットワークアダプタやGPUといったデバイスを、オンチップかPCIe Root Portの背後かを問わずTVMへ割り当てる方法を指します。TVMが割り当てたデバイスを信頼するには、デバイスが自身の識別情報やファームウェア、構成の状態を確認するEvidenceを提供する必要があります。EvidenceのクレームはTVM外部の第三者が処理しうるため、相互運用性には情報表現の標準化が欠かせません。この文書はDA向けのEvidence形式をEATのプロファイルとして定めています。
Draft Link

発行されたRFC

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

編集後記

  • 61件という大所帯の前半をまとめながら、AIエージェントの行動をどう記録するかという話題が、一日の中でこれほど積み上がるものなのかとしみじみ驚いていました。特にSCITTのプロファイルが、記録が改ざんされていないことだけを主張し、エージェントの判断が正しかったとも入力が真実だったとも言わないと明記していたのが強く印象に残っていて、検証できる範囲をきちんと線引きしてから設計に入る姿勢がとても好きになり、Part2とPart3にもエージェント関連の提案がまだ控えているので続きを読むのが今から楽しみです。

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

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

3
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?