トラスト・スパニング・プロトコルのImplmentor's draftがアナウンスされています

こんにちは、富士榮です。

Trust Over IPファウンデーションが今週開催されるIIW（Internet Identity Workshop）に合わせてトラスト・スパニング・プロトコルのImplementor's draftをアナウンスしてきました。アナウンスに使われたToIPのブログが非常にわかりやすいのそのまま機械翻訳にかけてみました。※そして私は現在IIWに参加するためマウンテンビューに来ています。

こちらが原文です。

TOIP ANNOUNCES THE FIRST IMPLEMENTERS DRAFT OF THE TRUST SPANNING PROTOCOL SPECIFICATION

https://trustoverip.org/blog/2024/04/11/toip-announces-the-first-implementers-draft-of-the-trust-spanning-protocol-specification/

早速中身を見ていきます。

なぜトラスト・スパニング・プロトコルが必要なのか？

インターネットがグローバルな情報経済を完全に変貌させたことに疑問を抱く人はいないだろう。接続性と信頼性の高いコンテンツ配信に不可欠なものとなった。しかし、インターネットが成長するにつれて、インターネットに対する脅威や、何を信頼すべきかという難しい課題も増えてきた。

現在、AIはこうした懸念をさらに加速させている。CyberArkによる2023年の調査によると、セキュリティ専門家の93％が2023年にAIを活用した脅威が組織に影響を及ぼすと予想しており、AIを活用したマルウェアが懸念事項の第1位に挙げられている。業界の著名人であるマーク・アンドリーセンは最近、AIの偽物を検出するための戦争は勝ち目がない、唯一の解決策はコンテンツの真正性を証明できるようにすることで「問題を逆転」させる方法を見つけることだと述べた。

30年もの間、セキュリティの問題は着実に深刻化しているのに、なぜ業界はまだ解決策を持っていないのだろうか？DNSSECや TLSのような技術や、IETFや CA/Browser Forumのような業界団体があるにもかかわらず、データ漏洩、ランサムウェア攻撃、個人情報盗難、マルウェアの蔓延に関する見出しが毎日のように掲載されるのはなぜでしょうか？生成AIへの関心が爆発的に高まっているにもかかわらず、なぜ多くの専門家は、AIが私たちを守るためというよりも、私たちを攻撃するために使われることを心配しているのだろうか？

その答えが、ToIP（Trust Over IP）ファウンデーションが4年前に設立された理由である。要するに、真正性、機密性、およびメタデータ・プライバシー機能は、インターネットのコア構造に組み込まれることはなかったのです。この問題の根本を解決するためには、既存のインターネットの上に次世代のトラストレイヤーが必要である。

このレイヤーの中心は、インターネット・プロトコル（IP）がデジタル・データにとってそうであるように、デジタル・トラストにとってそうであるプロトコルである。それがToIPトラスト・スパニング・プロトコル（TSP）である。

TSPのハイレベルな概要はどこで入手できますか？

まず、2023年1月にToIPトラスト・スパニング・プロトコル・タスクフォース（TSPTF）を立ち上げた際に発表したこのブログ記事から確認できる。TSPの全体的な目的と、ToIPスタックの中での位置づけが説明されている。

次に、昨年8月に発表されたToIPトラスト・スパニング・プロトコルの中間進捗報告書を読んで、TSP設計の7つの柱を要約することができる。いくつかの用語の進化を除いて、これら7つの柱は、過去7ヶ月間、複数の段階のワーキングドラフトを経てきた中で変わっていない。

本日、最初のImplementor's draftを発表できることを嬉しく思う。

Implmentor's draftは何をカバーしているのか？

この表は、仕様書の10の主要セクションをまとめたものである：

• 検証可能な識別子（VID）
• VID は7 つの柱の最初のものであり、TSP に対する技術的な信頼を提供する暗号的に検証可能な識別子である。VID が必要な理由、VID が公開鍵と ToIP エンドポイント・アドレスへのアクセスを提供する方法、VID の検証方法、および鍵のローテーション方法について説明する。
• メッセージ
• TSPはメッセージベースの非同期通信プロトコルである。メッセージ・エンベロープ、ペイロード（機密、非機密、ヘッダー）、署名、リレーションシップのセットアップ、帯域外の紹介。
• ネストされたメッセージ
• TSPメッセージは、メタデータ・プライバシーを達成するために1層または2層にネストすることができる。対象：ペイロード・ネスト、ネストされた関係 VID。
• 仲介者を経由するメッセージ
• TSPメッセージは、非同期配信、信頼性、パフォーマンスなど、いくつかの理由で仲介者を経由することができる。しかし、主な焦点はメタデータのプライバシー保護である。対象範囲：メッセージルーティング、直接の隣接関係、エンドポイント間（「トンネルされた」）メッセージ、プライベートVID、単一の仲介者、2つ以上の仲介者。
• マルチ・レシピエント・コミュニケーション
• TSP メッセージは複数の受信者に送ることができる。対象：複数受信者リストとエニーキャスト仲介。
• 制御ペイロードフィールド
• TSPメッセージは多目的であるため、専用の 制御メッセージではなく、制御ペイロードを定義する 。リレーションシップの形成（パラレル、ネスト、サードパーティの紹介）、リレーションシップのイベント（キーの更新、ルーティング情報、リレーションシップのキャンセル）。
• 暗号アルゴリズム
• TSPの真正性と機密性の特性は、公開鍵/秘密鍵暗号に依存しています。公開鍵署名、公開鍵認証暗号化、暗号化と復号のプリミティブ、ハイブリッド公開鍵暗号化（HPKE）、Libsodiumシールドボックス。
• シリアライズとエンコーディング
• TSPは 、 メッセージのシリアライズとエンコーディングにCESR（Composable Event Streaming Representation）を使用 します。CESRは、JSON、CBOR、MsgPakなどの一般的なデータ・エンコーディング・フォーマットをサポートします。対象：エンベロープ・エンコーディング、ペイロード・エンコーディング（非機密、機密、ネスト）、署名エンコーディング。
• トランスポート
• TSPの真正性、機密性、メタデータ・プライバシー特性は、トランスポート・プロトコルの選択に依存しないように設計されている。対象：トランスポート・サービス・インターフェース、トランスポート・メカニズムの例。
• 付録）テストベクター
• (まだ完成していない）一般的なユースケースのテストベクタ。ダイレクトモードのメッセージ、ダイレクトモードのネストされたメッセージ、ルーティングされたモデルのメッセージ。

TSPは他のトラスト・プロトコルとどう違うのか？

デジタル・トラストのための基本的な新しいインターネット規模のプロトコルを提案することは、野心的な事業です。なぜToIPファウンデーションはこのような道を選んだのだろうか？まず、この分野の関連する取り組みから見ていこうと思う。

関連プロトコル

この表は、デジタルトラストの様々な側面に取り組む他の有名なプロトコルをまとめたものです：

• OpenID Connect（OIDC）
• データ形式としてJSONを使用するRESTful HTTP APIとしてOpenID Foundationによって指定されたOAuth 2.0認可フレームワークの上にある認証レイヤ。基本的なユーザプロファイル情報へのアクセスをサポートします。オプションのYeahHighlight機能には、IDデータの暗号化、OpenIDプロバイダの発見、セッション管理などがある。
• OpenID for Verifiable Credentials（OID4VC）
• 検証可能なデジタル証明書の発行（OID4VCI）と提示（OID4VP）のためにOIDCの上に構築されたOpenID Connectワーキンググループのプロトコルファミリーと、ウォレットベースのユーザー認証プロトコル（SIOP）。
• DIDComm
• Decentralized Identity Foundation（DIF）のDIDCommワーキンググループによって仕様化されたDIDCommは、エンドポイントがDID（分散識別子）によって指定されるピアツーピアのセキュアメッセージングプロトコルである。
• TLS (Transport Layer Security)
• 安全なHTTPSブラウザー接続を可能にすることでよく知られる IETF の暗号プロトコル。X.509デジタル証明書を使用することにより、セキュリティ、機密性、完全性、真正性を提供する。
• MLS (Message Layer Security)
• IETF のMLS ワーキンググループによって仕様化された MLS は、任意のサイズのグループにおいて、エンドツーエンドで暗号化されたメッセージを扱うセキュリティレイヤーである。MLS のセキュリティ特性には、メッセージの機密性、メッセージの完全性と認証、メンバー認証、非同期性、前方秘匿性、漏洩後のセキュリティ、スケーラビリティなどが含まれる。
• RCS (Rich Communications Services)
• GSMAが指定したテキストベースのモバイル・メッセージング・プロトコルで、SMSメッセージに代わり、通話中のマルチメディアを含む豊富な機能を提供する。RCSはネイティブではエンドツーエンドの暗号化をサポートしていない。Googleは独自の実装でSignal Protocolを使用して暗号化を追加した。アップルは、GSMAがエンドツーエンドの暗号化を標準化すれば、RCSをサポートすると述べている。
• Signal Protocol
• 音声およびインスタントメッセージの会話をエンドツーエンドで暗号化する、Signal Foundationによって指定された非連帯暗号プロトコル。このプロトコルは、ダブルラチェットアルゴリズム、プレキー、およびトリプル楕円曲線ディフィー・ヘルマン（3-DH）ハンドシェイクを組み合わせたものです。
• Matrix Protocol
• Matrix Foundationによって規定された連合リアルタイム通信のためのアプリケーション層通信プロトコルで、オープンなサーバフェデレーション上でJSON形式のメッセージを安全に配信し、永続化するためのHTTP APIを提供する。WebRTCを介して標準的なWebサービスと統合し、ブラウザ間のアプリケーションを容易にすることができる。
• DNSSEC
• ドメイン・ネーム・システム（DNS）で交換されるデータを保護するための、IETFによる拡張仕様のスイート。このプロトコルは、データの暗号認証、認証された存在拒否、データの完全性を提供するが、可用性や機密性は提供しない。
• ISO/IEC 14443-4:2018
• 非接触環境用に設計された半二重ブロック伝送プロトコルで、プロトコルの活性化シーケンスと非活性化シーケンスを定義する。ISO/IEC 14443 の他の部分との併用を意図しており、タイプ A とタイプ B の近接カードやオブジェクトに適用可能である。

関連する暗号データ構造

インターネット規模のデジタル・トラストに必要な要素はプロトコルだけではない。この表は、これまでに開発された標準的な暗号データ構造のいくつかをまとめたものである：

• X.509デジタル証明書
•  TLSを含む多くのインターネット・プロトコルで使用される公開鍵証明 書やデジタル署名の形式を定義するITU標準 。X.509証明書は、電子署名を使用して、ID（ホスト名、組織、個人）と公開鍵を結びつける。証明書は、認証局（CA）または自己署名によって署名される。X.509 は、 証明書失効 リストと 認証パス検証アルゴリズムも定義して いる。
• 暗号化/署名されたPDFファイル
•  ポータブル・ドキュメント・フォーマット（Portable Document Format）は、もともとアドビが開発したもので、2008年にISO標準となった。PDFファイルは暗号化することができる。PDF 2.0は標準として256ビットAES暗号化を定義しているが、サードパーティがPDF用に独自の暗号化システムを定義する方法も定義している。ISO 32000-2は、PDFファイルを安全な認証のためにデジタル署名する方法を定義している。
•  検証可能なデジタル証明書
•  デジタル・ウォレットの出現に 伴い、W3C 検証可能クレデンシャル・データ・モデル、 ISO mDL/mDOC、 IETF SD-JWT、 Hyperledger AnonCreds、 ToIP Authentic Chained Data Container（ACDC）など、暗号的に検証可能なデジタル・クレデンシャルのための複数のフォーマットが開発 されてきた。
•  C2PAコンテンツ認証
• C2PA標準は、暗号的に検証可能な出所情報をデジタルメディアコンテンツにバインドするモデルと、その情報の信頼性を評価するモデルを定義する。

 TSPはどう違うのか、なぜ違うのか？

上記のセクションが示すように、インターネットの多数のセキュリティ、機密性、およびプライバシー問題に対処するために設計されたプロトコルと暗号データ構造には、何千人もの工数が費やされてきた。では、なぜToIPファウンデーションのメンバーは4年もの歳月をかけてTSPを開発したのだろうか？

その基本的な理由をこの表にまとめた：

•  上位層プロトコルのスパニング層としてのミニマリスト・デザイン
•  TSPの唯一で最も重要な設計目標であり、（DIDCommを例外とする）上記のプロトコルとの最大の差別化要因は、プロトコルスタックにおけるスパニングレイヤーの重要な役割である。それが「可能な限りシンプルでなければならないが、これ以上シンプルであってはならない」理由は、ToIPスタックの設計原則の第3原則で詳しく説明されている。TSPが上記のプロトコルの機能の多くを含まないのは、まさにそれらの機能をより上位のプロトコルで提供できるように設計されているからである。その利点は、TSPレイヤーで達成された技術的な信頼機能をすべて自動的に継承するため、それらの上位プロトコルはすべて、よりシンプルで将来性のあるものにできるということである。
•  分散型ピアツーピアアーキテクチャ
•  HTTPとRESTful API上に構築されたOpenIDファミリーのプロトコルは、本質的にウェブ中心（クライアント／サーバー）である。TSPはそのようなアーキテクチャ上の仮定はしていない。IPプロトコルのように、どのような種類のネットワークやソフトウェア・アーキテクチャであっても、2つのピア間で動作することができる。
• VIDsとDIDs
•  DIDCommのように、すべてのTSPエンドポイントは、W3C Decentralized Identifiers(DIDs)仕様で定義されているような暗号的に検証可能な識別子（VID）を使用する。VIDは完全な分散化をサポートするだけでなく、ライフタイム・リレーションシップ管理のための移植性と暗号的な俊敏性を提供する。
• 公開鍵認証による暗号化と署名
• TSPは、最新の公開鍵認証暗号化と公開鍵署名を組み合わせて、鍵の漏洩によるなりすましと送信者のなりすましの両方に対する最強の保護を提供する。これは、IETF RFC9180HPKE（HypbridPublic Key Encryption）で定義されたAuth Modeプリミティブ、またはESSR（Encrypt Sender Sign Receiver）パターンで強化されたHPKE Base ModeまたはLibsodium Sealed Boxプリミティブのいずれかを使用することで実現される。
• ペイロードの敏捷性
• TSPは、JSON、CBOR、MsgPakを含むテキストとバイナリの両方のプリミティブを同じメッセージ内で合成することをサポートするCESRテキスト・バイナリ・デュアル・エンコーディング・フォーマットを使用する。
• 暗号の俊敏性
• CESRのもう一つの大きな特徴は、あらゆるタイプの暗号プリミティブに対応するコードテーブルである。例えば、CESRは上記の暗号データ構造のどれでも伝送することができる。これにより、TSPエコシステムは正確な署名と暗号化アルゴリズムを標準化しながらも、時とともに進化させることができる。
• トランスポートの独立性
• Trust Over IP "という名称は、トランスポートをTCP/IPスタックに依存することを示唆しているが、実際には、TSPの中核的な設計目標は、基礎となるトランスポート・プロトコルから完全に独立して、エンドツーエンドの真正性、機密性、およびメタデータ・プライバシーを提供することである。

どのような実装プロジェクトが発表されましたか?

最初の実装者ドラフトと並行して、来週のInternet Identity Workshop#38 では、TSP 仕様の主要著者の 1 人が主導する最初の 2 つの TSP 実装プロジェクトを発表する予定です：

共著者のWenjing Chuが率いるRustオープンソース実装は、OWFプレミア・メンバーのFuturewei、Gen、AccentureがスポンサーとなるOpenWallet Foundation（OWF）の新しいプロジェクトとして提案されている。

Pythonのオープンソース実装は、共著者のSam Smithと彼の同僚によってWeb of Trust GitHubコミュニティプロジェクトで開発されている。

これらのプロジェクトのいずれかに貢献したり、独自のプロジェクトを立ち上げたりすることに興味がある方は、ぜひご協力していただきたい。ToIPのコンタクトページか GitHubからご連絡いただきたい。

この草案について、どのようなフィードバックを求めていますか？

いつものように、私たちは新しいプロトコル仕様に関する通常の質問に対するフィードバックを求めている：

• 仕様は明確で理解しやすいか？
• 仕様書は明確で理解しやすいか？
• より多くの例や図解があれば助かる箇所はありますか？
• 追加してほしい特定のテストベクターはありますか？

また、特に以下の分野でのご意見を募集している：

1. TSPをどのように利用しますか？すでに持っているものをどのように強化できるか？どのような種類のトラスト・タスク・プロトコルをTSPに重ねることに最も興味があるか？
2. TSP は、計画しているトラスト・タスク・プロトコルをサポートするために必要なベースライン機能を提供するか？
3. TSP はソリューションをより分散化することを可能とするか？
4. どのような種類のVIDのサポートを実装する予定か？
5. どのようなトランスポート・プロトコルにバインドする予定か？
6. どのような暗号アルゴリズムを使用したいですか、または使用する必要があるか？
7. 技術スタックで解決しようとしている問題で、既存のソリューションでは対処できず、TSPで対処できる、あるいは対処すべき問題は何か？
8. 私たちが知らない他の開発中のプロトコルで、TSPと競合する、あるいはTSPを補完する可能性のあるものはあるか？

どのようにフィードバックできますか？

仕様を確認するには

Githubページバージョン: https://trustoverip.github.io/tswg-tsp-specification

マークダウン版: https://github.com/trustoverip/tswg-tsp-specification

コメント、バグ報告、問題提起は、GitHubのToIPパブリックレビュープロセスに従うこと：

バグ/問題: https://github.com/trustoverip/tswg-tsp-specification/issues

ディスカッション: https://github.com/trustoverip/tswg-tsp-specification/discussions

ご覧の通り、割と広くトラストについてカバーされており、実際の仕様も出てきているので見ていけると良いと思います。