IETFのTLS WGでは、Googleの方らによって提案されている『TLS Trust Anchor Negotiation』という仕組みが議論されています。
これは、クライアントとサーバ側で共に信頼できるCA(トラストアンカー)をネゴシエーションし、複数あるサーバ証明書から適切なものを提供できるようにする仕組みです。
(引用: IETF 120 スライド PDF より)
具体的な提案仕様よりも、explainer を読むのが分かりやすい。自分用に軽く目を通しておく
https://github.com/davidben/tls-trust-expressions/blob/main/explainer.md
目次
背景
現状、クライアントがどのCAを信頼しているか伝えず、サーバ側は全てのクライアントに信頼されているだろうCAのサーバ証明書を利用します。
本議論の中では、それを『単一証明書デプロイモデル』と読んでいます。単一証明書デプロイモデルでは次のような
- 新しいCAを利用しようとしても、全てのクライアントに信頼されている必要がある。更新されていないクライアントがいると利用できない。キーローテーションも同様
- クライアント側が新しいセキュリティ要件を課したとして、古いクライアントが居るとそれに答えられない
この課題を解決するために、『複数証明書デプロイモデル』として、サーバ側がクライアントに合わせて証明書を出し分けられるようにするのが、『TLS Trust Anchor Negotiation』の議論である。
目標
TLS Trust Anchor Negotiationの目標は、Webで使用されるHTTPSにおいて『複数証明書デプロイモデル』を有効にすることです。次の項目を目指します。
- 可用性と競合することなく、ユーザのセキュリティニーズを満たせるように進化できる
- サーバ側では複数のサーバ証明書を設定でき、接続ごとに適切な証明書を自動的に送信できる
- サーバの運用者の手動作業を可能な限り少なくし、ACMEが利用できる
- TLSハンドシェイクに追加されるトラフィックを最小限に抑える
また、耐量子計算機暗号 (PQC) 証明書への移行などもユースケースに含まれている
実現案
既存の実現案として RFC 8446 TLS1.3には、certificate_authorities拡張を使う方法があります。certificate_authorities拡張を使うことで、サポートしているCAを示すことが出来ます。
しかし、certificate_authorities拡張は1CAあたり100バイト程度消費し、100CAを扱う昨今のクライアントでは、送信するデータ量が大きくなってしまいます。
そこで、Googleの方らによって次の２つの提案仕様が出されています
( 前者の仕様の議論を経て、後者の仕様が提出されていますが、現在は合わせて議論されている段階です
簡単に紹介します
(それぞれACMEの拡張も行ってたりしますが、細かいところは割愛
Trust Expressions
WebブラウザやOSによって管理される信頼するCAリスト（ルートプログラム）に、名前とバージョンを付けトラストストアマニフェストとします。クライアントはそのマニフェストを参照し、trust_expressionsとして送信することで信頼するCAのリストをサーバに伝えます。
enum { trust_expressions(TBD), (2^16-1) } ExtensionType;
struct {
TrustStore trust_store;
uint24 excluded_labels<0..2^16-1>;
} TrustExpression;
TrustExpression TrustExpressionList<1..2^16-1>;
Trust Anchor Identifiers
CAを5バイトで表現できるようにtrust anchor identifiersという識別子を導入しています。これを用いて、ハンドシェク中、クライアントはtrust_anchors拡張でサポートするCAのリストをサーバに通知できるようにします。
また、サーバも HTTPS/SVCB DNS レコード を用いて自身がサポートしているCAのリストを提示することで、クライアントが送信するデータ量を最小限に抑えることが出来ます。
example.net. 7200 IN SVCB 3 server.example.net. (
tls-trust-anchors=32473.1,32473.2.1,32473.2.2 )
