この仕様の解説はまだ書かれていない。下の要約・関係・対応状況は維持されている。
Workload Identity Certificate を使い、トランスポート層でワークロード間を認証する。
WIMSE Mutual TLS
Workload Identity Certificate を使い、トランスポート層でワークロード間を認証する。
- 現在地
- WG ドラフト
- 公式に文書化された対応
- 0
他の仕様との関係
関係図
flowchart LR s_wimse_mtls["WIMSE Mutual TLS"] s_wimse_creds["WIMSE Workload Credentials"] s_mtls["Mutual-TLS Client Authentication and Certificate-Bound Tokens"] style s_wimse_mtls stroke-width:3px s_wimse_mtls -->|土台とする仕様| s_wimse_creds s_wimse_mtls -->|組み合わせ| s_mtls
公式に文書化された対応
利用状況には、公式のドキュメント（ベンダーやプロジェクト自身のもの、または標準化団体がその名前を挙げているページ）に対応が明記されているものだけを載せている。引用した文言がそのページにまだあるかは毎週確認している。実験的・アルファ・ベータの対応は「プレビュー」として別に数える。
出典付きの対応情報はまだ集めていない。普及していないという意味ではない。
動き
Datatracker の revision 履歴、このサイトの日次 run が書いた解説、draft 名を挙げた ML の件名。
このサイトの解説
Kathleen による mTLS ドラフトのレビューは、経路検証と名前だけでなく鍵ペアによる認証も扱うよう求め、WGLC が可能との見解を示している。
Review of https://datatracker.ietf.org/doc/draft-ietf-wimse-mutual-tls/
解説を読む
このレビューは、序論の第一文に at the transport layer を加えることを提案している。3.2 節の前に、証明書に結び付いた鍵ペアでワークロードを認証することについての節（ワークロードが期待される鍵ペアと照合する場合のプロビジョニングを含む）を追加することも勧めている。5.1 節では、サーバーがワークロード識別子の名前だけでなく、資格情報と鍵ペアで認証されるよう文言を改めることを提案している。さらに、mTLS を行うサーバーは、クライアント証明書チェーン、トラストドメイン、Workload Identifier に加えて鍵ペアも検証しなければならない（MUST）とする案を示している。これらの変更により、WGLC が可能になると見ている。
- 証明書チェーンや識別子の検査に加え、証明書の鍵の所有証明も認証の一部であると仕様に明記してほしい mTLS の実装者。