要約

  • RFC 9509は、JWT/JWS、HTTP JSONのJWE暗号化、OAuthアクセストークン署名に対して三つのEKUを登録した。
  • 現行3GPP仕様は、用途ごとに別証明書を置く方法と、一枚に複数用途を載せる方法の双方を認める。侵害や失効の影響範囲は同じではない。
  • EKUは目的を表すだけであり、初期信頼、NF本人性、KU、JOSE処理、claims、認可判断、サービス実行の証拠を省略できない。

証明書を一枚減らすと、運用項目も一つ減ったように見える。しかし、その一枚がTLS認証、CCA署名、JWE鍵処理、トークン署名を結び付けていれば、失効時に失うものは一つではない。RFC 9509を読む際の中心はOIDの暗記ではなく、この依存関係を誰が設計したかである。

RFC 9509は2024年3月のProposed Standardであり、RFC Editorの情報ページとIETF Datatrackerが公開記録を示す。IANA SMIレジストリでは、37がid-kp-jwt、38がid-kp-httpContentEncrypt、39がid-kp-oauthAccessTokenSigningである。

最初の用途はJWT上のJWS署名検証で、5GのClient Credentials Assertionを含む。二つ目はJWEで保護するHTTP JSON、特にSEPP間での内容暗号鍵処理に使う。三つ目はOAuth 2.0アクセストークン署名である。既存のTLSクライアント・サーバー用途は残る。

区別が必要なのは、暗号演算ができることと、その仕事を任されていることが違うからだ。TLSクライアント証明書の秘密鍵が署名可能でも、CCAを署名してよいとは限らない。サービス消費者が運用者発行の証明書を持つことも、サービス提供者を名乗る根拠にはならない。RFC 9509は署名用途に署名可能なKey Usageを、JWEの鍵配送例にkeyEnciphermentを求める。

分離か集約かは運用ポリシーで決まる

RFC 5280ではKUとEKUが両方あれば双方を満たす必要がある。一方、RFC 9509は他のEKUとの併記を禁じない。RFC 9336の許可・除外モデルにより、依存側は特定の組合せ、EKU欠落、anyExtendedKeyUsageを拒否できる。

現行の3GPP TS 33.310 V19.5.0はさらに明確だ。実装は用途ごとに異なる証明書を配備しても、一枚に複数用途を持たせてもよい。初期信頼の証明書にも、最終的な5G Core NF証明書にも同じ選択がある。

用途別に分ければ、CCA署名証明書の失効がTLS本人性まで消す必要はない。JWE用秘密鍵の漏えいも、トークン署名権限へ直結しない。その代わり、鍵生成、登録、配布、更新、期限、失効、検証器設定が増える。

多用途化すれば管理対象は減るが、一つの秘密鍵と一つの証明経路に障害が集中する。ある用途の緊急ローテーションが他の業務を止める可能性もある。これはどちらが常に正しいという話ではなく、結合した影響を記録する責任の話である。

NFの識別と用途は別の面にある

TS 33.310の登録手順は、OAM証明書、署名済みNFプロファイル、または初期認証鍵から始まる。運用者RA/CAは鍵所有証明とNF Instance IDを検証し、必要ならNF typeも照合する。初期信頼にEKUが含まれる場合、最終申請のEKUとの一致も確認できる。

したがってid-kp-jwtはNFを識別しない。認証された鍵の用途を限定するだけである。subjectAltNameのインスタンスID、証明経路、失効状態、登録記録は別の証拠だ。

稼働時には、現行3GPP TS 33.501 V19.5.0がさらに多くの検査を置く。CCAはサービス消費者が署名するJWTであり、受信側はJWS、本人性、時刻を検査する。OAuthではNRFが認可サーバー、消費者NFがクライアント、提供者NFがリソースサーバーとなる。提供者は許可されたissuer、署名、subject、audience、必要なsliceやservice-set、scope、追加のresource/action、失効時刻を検査し、場合によってCCAとTLS証明書の本人性も突き合わせる。その後にはじめてサービス実行へ進む。

3GPP TS 29.500はサービスベースインターフェースを具体化し、TS 29.573はPLMN間とSEPPの文脈を扱う。暗号化EKUは、特定JSONの正当性、到達、復号、処理結果を証明しない。

発見情報は失効に追い付かないことがある

TS 33.310は、証明書失効をNRFが知らなければ、その提供者を発見結果に含める可能性を示す。暗号資格の状態とサービス発見の状態は別である。監査記録には初期信頼方式、NFインスタンスと種別、正確な証明書・鍵・経路、KU/EKU、許可・禁止組合せ、JOSEアルゴリズムとヘッダー、claims、認可ポリシー版、失効証拠、要求・応答、サービス観測が必要だ。

用途情報自体が観測される場合もある。TLS 1.2では証明書が平文で流れ得るが、TLS 1.3はServerHello後の証明書メッセージを保護する。公開信頼証明書はCertificate Transparencyから目的を推測され得る。それでも分かるのは準備された能力であり、実行事実ではない。

編集上の視座は、実行コードの優位、現実の層、最小初期仕様と地域ごとの採用判断である。共通OIDは相互運用の言葉を与えるが、証明書構成と実際の認可まで中央で決めるものではない。