摘要

  • RFC 9509 登记 id-kp-jwt、id-kp-httpContentEncrypt 与 id-kp-oauthAccessTokenSigning，分别标示 JWT/JWS、HTTP JSON 的 JWE 加密与 OAuth 访问令牌签名用途。
  • 当前 3GPP 规范允许每种用途使用不同证书，也允许一张证书携带多种用途；这会直接改变密钥泄露、轮换与撤销的影响半径。
  • 用途 OID 只是链条中的一层。初始信任、NF 身份、KU/EKU、JOSE 处理、令牌声明、授权政策与服务执行都需要独立收据。

证书组合最容易在一切正常时被忽视。一张多用途证书减少了签发和轮换对象，看起来更干净；直到某个签名用途需要紧急撤销，TLS、客户端断言和其他职责一起失去同一条验证路径。分开证书则把故障圈缩小，却把库存、到期日与分发路径成倍增加。RFC 9509 的重要性，正在于它让这种原本模糊的组合变成可命名、可审计的设计选择。

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（CCA）。第二项用于 JWE 场景，例如在 SEPP 之间为 HTTP JSON 内容封装内容加密密钥。第三项用于 OAuth 2.0 访问令牌签名。TLS 客户端与服务端用途继续使用既有 EKU，并未被替代。

这些名称针对的是越权复用。具备 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 解密密钥泄露，也不应自动带来 OAuth 令牌签名能力。代价是更多密钥、注册请求、证书链、轮换负责人、到期告警、撤销传播与验证器配置。

多用途证书可以减少对象数量，却把多个职责绑在同一私钥、同一验证路径和同一撤销事件上。为一个用途进行紧急轮换，可能同时中断其他服务。这里没有普遍正确的拓扑，只有必须公开承担的耦合关系。

用途不能替代身份

证书链从签发之前开始。TS 33.310 允许用 OAM 证书、签名后的 NF 配置参数或初始认证密钥建立初始信任。运营商 RA/CA 还要验证持钥证明、NF Instance ID，并在适用时核对 NF type。若初始信任携带 EKU，最终申请中的用途可以被要求与之对应。

因此，id-kp-jwt 只回答“这把经过认证的公钥准备用来做什么”，不回答“哪一个 NF 持有它”，更不回答“这个 NF 是否可以调用某项服务”。subjectAltName 中的实例身份、实际构建出的证书路径、有效期与撤销状态、签发档案各自承担不同证明责任。

运行时还要继续过关。当前 3GPP TS 33.501 V19.5.0把 CCA 定义为由 NF 服务消费者签署的 JWT；接收方验证 JWS、实例身份与时间声明。在 OAuth 角色中，NRF 是授权服务器，消费者是客户端，生产者是资源服务器。生产者要核对允许的签发者、签名、subject、audience、适用的切片或服务集标识、scope、额外资源与操作范围、过期时间，并在需要时检查 CCA 与 TLS 证书身份的一致性。通过这些检查之后，流程才进入服务执行。

3GPP TS 29.500描述服务化接口的技术实现，TS 29.573补充跨 PLMN 与 SEPP 场景。加密用途 OID 并不能证明某个 JSON 对象合规、获准、送达、解密或产生动作。

撤销信息也会与发现状态分离

TS 33.310 指出，若 NRF 不知道证书已经撤销，它仍可能在发现结果中返回该生产者实例。也就是说，证书状态与服务发现状态可以脱节。证书组合会决定这种脱节只影响一种职责，还是同时拖住多种职责。

完整记录应包括初始信任方式、NF 实例与类型、确切证书和密钥标识、证书链、KU/EKU 集合、允许和禁止的用途组合、JOSE 算法与头部、相关 claims、授权政策版本、撤销证据、请求与响应，以及服务遥测。只保存“证书有效”会抹去真正做出决定的层次。

用途信息还可能被外部观察。TLS 1.2可能明文传送证书；TLS 1.3在 ServerHello 之后保护证书消息；公开信任证书还可能进入 Certificate Transparency。观察到 EKU，只能说明这把钥匙被准备承担何种职责，不能说明它实际做过什么。

本文公开采用三篇 Heng Lu 文章作为分析原则：运行代码优先要求结论追随实际执行，现实层次要求分开声明、技术验证与结果，最小初始规范与本地采用则强调共同词汇不应吞掉实施选择。RFC 9509 统一了用途语言，运营商仍要为证书组合负责。