摘要

  • RFC 9734 注册了 id-kp-imUri，即 OID 1.3.6.1.5.5.7.3.40，让证书可以声明其密钥用于签署即时通信身份凭据，而不是承担通用 TLS 客户端或服务器认证。
  • EKU 说明“密钥准备用来做什么”。账号标识应由 subjectAltName 承载；证书路径、期望标识匹配、账号控制、吊销新鲜度和应用授权都是另外的判断。
  • 在 MLS 中，证书公钥必须与 LeafNode 的签名密钥相同；但应用仍要提供可接受的参考标识，认证服务仍要验证其与证书所呈现标识的关系。

一个离职员工的旧手机重新上线。证书没有过期，链条有效，扩展里也有 id-kp-imUri。群聊系统于是把界面点亮：身份已验证。

界面把三个问题压成了一个。证书是否适合 IM 身份凭据，是一个问题；证书里命名了哪个账号，是第二个问题；这个账号和这台手机今天是否仍有权加入群聊，是第三个问题。

RFC 9734 只负责把第一个问题说得更准确。它在 2025 年 2 月作为标准跟踪 RFC 发布，定义了即时通信身份 KeyPurposeId。规范的安全动机很具体：组织不一定愿意给 IM 客户端发带有通用 id-kp-clientAuth 或 id-kp-serverAuth 的证书，因为同一凭据可能被带进别的协议，形成跨协议滥用。

所以 RFC 建议发行者不要把这两个宽泛用途与 id-kp-imUri 并列。新 OID 的价值来自边界变窄，而不是身份结论变大。

用途字段和身份字段不是同一栏

RFC 5280 对两种扩展作了清楚分工。Extended Key Usage 表示被认证公钥可以承担哪些用途。Subject Alternative Name 把一个或多个身份绑定到证书主体；URI 使用 uniformResourceIdentifier 表示，并且必须是包含 scheme 的绝对 URI。

这意味着一张证书可以同时留下多条彼此独立的证据：

记录 能支持的窄结论
id-kp-imUri 这把公钥被限定到 IM 身份凭据用途
subjectAltName 中预期的 im: URI 发行者按其流程把该 URI 写入证书身份
有效认证路径 签名、有效期、约束和策略到达被接受的信任锚
私钥签名成功 当时的呈现者控制对应私钥
账号挑战成功 某个命名流程在某时连接了请求者和账号
群组准入成功 应用允许这个客户端进入特定群组和 epoch

第一行不会自动生成第二行，第二行不会自动生成第五行，第五行也不会自动生成第六行。

RFC 3860 把 im: URI 定义为 INSTANT INBOX 的标识，并建议用于 S/MIME 即时通信的证书在 subjectAltName 中包含主体的 IM URI。它同时明确：抽象服务假定可靠送达，本身不提供应用层送达保证。一个收件箱标识从来不是送达回执。

RFC 9734 还提到 subjectAltName 可以是 XMPP URI。RFC 6121 中的 JID 可以标识账号或资源，但 roster 修改、stanza 处理等动作仍有单独授权规则。名字合法不等于动作有权。

IANA 分配的是共同语义，不是账号信誉

IANA SMI 注册表 在 PKIX 扩展密钥用途弧下把十进制 40 分配给 id-kp-imUri。这能避免不同规范为同一数字赋予不同意义。IANA 没有见过某一张证书的申请者、账号挑战或设备状态。

RFC 9734 允许发行者把这项 EKU 标记为 critical 或 non-critical。RFC 5280 允许应用要求特定用途必须存在。真正的保护因此取决于四件事：发行配置、解析实现、依赖方策略以及错误时是否拒绝。

如果客户端忽略用途，OID 只是装饰。如果发行者同时加入 clientAuth、serverAuth 或 anyExtendedKeyUsage，狭窄边界又被打开。如果同一把密钥跨协议复用，新字段也不能独自阻止另一套验证器接受它。

比“有多少证书带新 OID”更有意义的指标，是错误凭据被拒绝了多少次。测试应把 IM 用途证书送入 TLS 客户端和服务器认证路径，也把通用 TLS 证书送入要求 id-kp-imUri 的入口。用途约束必须在负面路径上成为可观察的运行代码。

有效证书路径不知道应用原本想找谁

路径验证处理发行者签名、有效期、信任锚、Basic Constraints、Name Constraints、证书策略、Key Usage 和 EKU。它回答的是给定 PKI 策略下能否接受这条路径。它不会替应用生成期望的 IM 账号。

RFC 9525 在服务身份场景中区分证书呈现的标识和客户端期望的参考标识。这套语言很有帮助：一边是证书带来的名字，另一边是业务原本要认证的对象。没有第二边，就没有匹配问题，更没有匹配结果。

证书可以同时呈现两个 URI；别名可以在证书有效期内改名；视觉相近的 Unicode 表示可能需要保守规则。审计记录必须保留参考标识、呈现标识、归一化和比较算法、信任锚、策略版本、时间、结果与原因。只留下“链有效”，相当于把问题丢掉后保存答案。

MLS 把证书密钥接到成员，却不替应用制定身份政策

RFC 9420 要求 X509Credential 中终端实体证书的公钥与 LeafNode 的 signature_key 完全一致。这项绑定很强：成员不能拿一张证书，转而用无关密钥签署群组对象。

但 RFC 9420 随即把标识可接受性留给应用。应用维护成员的参考标识，凭据提供呈现标识，认证服务验证证书确实代表这些呈现标识，并确认它们能认证参考标识。新增凭据和替换凭据必须在相应的 Add、Update 或 Commit 等时点重新验证。

因此一次准入至少包含四张回执：

  1. 证书公钥与 LeafNode 签名密钥一致；
  2. 路径、有效期、约束与 id-kp-imUri 被接受；
  3. 呈现 URI 按明确规则匹配期望 URI；
  4. 应用允许这台客户端在这个群组、角色和 epoch 中行动。

同一账号还可能对应多台设备。RFC 9420 明确提醒，应用层标识未必能唯一标识客户端；leaf index 也只在一个 epoch 内有意义。企业若要区分受管电脑、私人手机和自动机器人，就必须在账号之外保留客户端或设备坐标。

静态证书跟不上账号状态变化

证书签发正确，不代表今天仍适合使用。账号会停用，设备会丢失，人员会离职，租户会迁移，群组会撤销成员资格。私钥却可能继续可用。

RFC 6960 为 OCSP 定义 good、revoked 和 unknown。其中 good 最低限度只表示：在有效期内没有相同序列号的证书被报告为吊销；它甚至不必证明该证书曾被签发，也不包办全部有效性。thisUpdate、nextUpdate 和 producedAt 决定状态证据的时间范围。

因此 unknown 不能静默变成 good，旧的 good 也不能永久使用。验证者还要确认响应者权威和新鲜度。账号数据库可能比 PKI 吊销更快变化，两种状态需要并列保存，而不是相互覆盖。

RFC 9734 引用的 draft-barnes-mimi-identity-arch-02 把吊销作为凭据之外的独立信息流，并比较短期凭据、OCSP 和 CRL。它仍是进行中的草案，不能证明任何部署；但它准确揭示了静态对象的限制：证书无法在失效后自行改写。

把一个绿色标识还原成证据链

发行环节保存申请 URI、账号证明方法、验证权威、政策版本、密钥持有证明、subjectAltName、EKU、序列号和有效期。验证环节保存期望标识、呈现标识、匹配规则、路径、信任锚、用途判断、时间、吊销来源和失败策略。MLS 环节保存 LeafNode、凭据指纹、认证服务决定、群组、epoch、客户端和准入规则。结果环节只保存相应系统真正观察到的提案接受、消息认证、服务交付、设备确认或人工响应。

RFC 的规范文本、XML、编辑记录、勘误索引和 IETF 历史证明公开规范的出处，不证明产品部署。

Heng Lu 的运行代码优先原则追问实际执行了哪些检查；最小初始规范允许公共层只协调一个狭窄 OID，把账号、设备和准入决定留给明确责任人；现实层级则阻止注册号、扩展值、名称匹配和业务授权被压成一个制度事实。

RFC 9734 的进步在于让一项声明更小、更准。最危险的实现，是把它重新膨胀为“身份已验证”。

来源