要約

  • JWTClaimConstraints向けAuthority Tokenプロファイル第05版では、DER符号化された制約をACMEクライアントとサーバーにとって不透明なオクテット列とし、解析せず完全一致だけを確認する。
  • 制約の意味はToken Authorityが分野固有の規則で審査する。一方、どの発行者証明書をサーバーが信頼するかは、導入エコシステムが決める。
  • 任意のtoken-authorityはクライアントがトークン取得先を探すための案内にすぎない。サーバーは検証に使わず、x5uまたはx5cで示された証明書が信頼設定済みかを調べる。
  • 文書はなおワーキンググループのInternet-Draftである。検証成功は、法的身元、発信者の主張の真偽、あらゆる制度での権限を保証しない。

実装レビューが三つの責任を切り分けた

著者らは2026年9月5日に第05版を告知した。これに先立つACME議長のレビューは、規範要件が誰に向けられ、複数のフィールドを実装者がどう扱うのかを問うた。Chris Wendtの回答と変更記録によれば、対象読者、発行者の信頼、token-authorityの役割が明確化された。

このプロファイルはSecure Telephone Identityの認証局を対象とする。証明書が主張できる内容を制限するJWTClaimConstraints拡張について、申請者の権限をACMEで示す仕組みである。RFC 9448が拡張を定義し、RFC 8226とRFC 9118が証明書と制約の背景を与える。

第05版では、ACMEクライアントが識別子を送り、トークンを取得する。ACMEサーバーはチャレンジ応答を検証する。Token Authorityはその前段で、申請された制約が分野の方針に合うかを判断し、署名済みトークンを発行する。

クライアントとサーバーが見るのは、base64urlで表したDER値である。これは不透明なオクテット列としてそのまま運ばれ、トークンと識別子の間で一オクテットずつ照合される。mustInclude、permittedValues、mustExcludeを解析して妥当性を判断するのは両者の仕事ではない。意味の審査はToken Authorityに残る。

これは仕様の弱さではなく、権限の節度である。RFC 8555のACMEは証明書管理を自動化するが、電話番号に関する制約の制度設計まで一般的なチャレンジサーバーに委ねてはいない。

取得先の案内は信頼先の指定ではない

任意のtoken-authorityパラメーターは、クライアントにトークン取得先の候補を伝える。第05版は、サーバーがチャレンジ応答の検証にこの値を使わないと明記した。クライアント向けの発見情報と、サーバーの信頼判断は別である。

発行者証明書はトークン内のx5uまたはx5cから得る。両方とも欠けることは許されない。サーバーは証明書を取得または読み出し、署名を検証し、その証明書が当該エコシステムのAuthority Token発行者として設定上信頼されていることも確認する。証明書へのリンク自体が信頼を生むわけではない。

信頼アンカーと証明書要件を誰が管理するかは仕様の範囲外であり、導入エコシステムに委ねられる。STIRガバナンスは一例として挙がるだけで、世界共通の機関を指すものではない。登録、権限範囲、停止、取消し、異議申立ては別の制度設計を要する。

すでにStandards TrackとなっているRFC 9447も、認証局とToken Authority、クライアントとToken Authorityの間に既存関係があることを前提とする。その関係を仮定できない環境にはチャレンジを適用できない。新プロファイルは制約の形式を拡張するが、この制度的前提を消してはいない。

成功結果が示すのは限定された整合性である

信頼する発行者を設定した後も、サーバーの検査は多い。トークンの構造と種別、署名を確認し、expが存在して期限内であること、jtiが存在することを求める。注文を出したACMEアカウント鍵との結び付きと、要求した証明書に対するcaフラグの一致も調べる。

さらに、トークンと識別子の制約値を完全一致で比較する。いずれかに失敗すればチャレンジをinvalidにし、通常はunauthorizedのACME問題文書を返すべきだとする。別アカウント、別の申請形態、別の制約への安易な転用を防ぐための強い機械的チェックである。

ただし、expは時間、署名は鍵、完全一致は二つの表現の同一性を示すだけである。誰が発行者を信頼集合へ入れたのか、どの方針版が権限を定めたのか、意味の判断が正しかったのかは説明しない。

Datatrackerの現行記録は、文書をActiveかつIn WG Last Callとし、IESG状態をI-D Existsとしている。document shepherd、担当Area Director、telechat日程はない。以前の呼び掛けには7月25日の終了日があったため、現在もコメント募集中とは言えない。第05版は承認済みRFCでも、実装や配備の報告でもない。

運用面では、一つの注文にJWTClaimConstraints識別子とTNAuthList識別子を各一つまでとする。発行済み証明書のx5u URLは、利用者が必要とする間、通常は少なくとも失効時まで取得可能に保つことも推奨される。後日の検証材料は残るが、信頼を採用した理由までは残らない。

制約権限レシートなら機密を出さずに接続できる

導入エコシステムは、ACME判断と結合できる制約権限レシートを生成できる。電話番号や生の制約値は載せず、方針の識別子と版、Token Authorityの身元、信頼証明書のフィンガープリント、許可された制約族と委任範囲、注文と符号化制約のハッシュを結ぶ。

発行、判断、期限の時刻、結果と限定された失敗分類、信頼登録の発効・取消し状態、訂正・事故・異議申立ての窓口も必要である。プロトコル成功は法的身元、発信内容の真実性、指定外の制度における普遍的権利を判定しない、と明示する。

これはDaniel Kadeの編集上の提案であり、IETF要件ではない。実際の信頼方針システムから自動的に出すべきで、担当者が別台帳へ転記する仕組みでは不十分だ。機密を伏せたまま、誰のどの方針が技術結果に権威を与えたかを追えることが目的である。