摘要

  • TLS 1.3 以 certificate_request_context 区分客户端认证块对应的 CertificateRequest，特别适合处理握手后多次请求以及乱序到达的响应。连接内唯一性和不可预测性保护的是这次协议关联，并不会生成应用授权范围。
  • 可审计的认证收据必须分别保存 TLS 上下文、私钥持有证明、证书路径判断、应用主体、资源、动作、政策版本、决定、有效期和撤销状态。让不透明上下文代替这些要素，只会把准确的消息配对误写成从未作出的权限决定。

设想一条长期存在的连接。服务先在查看账户资料前发出一次客户端证书请求，又在批准管理变更前发出第二次请求。程序在短期内把两个上下文分别标记为“查看”和“管理”，客户端因为需要调用硬件凭据而以相反顺序回应。TLS 能准确还原两组请求与响应。一年后，审计库只剩“第二个上下文通过认证”。这句话无法说明当时涉及哪个账户、采用哪版规则，也无法证明持钥者获准完成那项管理操作。

RFC 9846 于 2026 年 7 月成为 Proposed Standard，并取代 RFC 8446。它把字段的协议职责写得很窄：CertificateRequest 包含长度为零到 255 个八位组的不透明 certificate_request_context，其后是请求认证参数的扩展；客户端在返回 Certificate 时原样回显这个上下文。服务器因此知道响应源于哪一项请求。

每条连接中的上下文必须唯一。如果两次请求复用同一上下文，某个 CertificateVerify 就可能被当作另一项请求的答案。初始握手中的上下文必须为空；非空值属于握手后认证场景。边界非常明确：唯一性只覆盖当前连接，不覆盖新连接、组织、账户、资源或凭据的整个生命周期。

握手后请求还应让上下文对客户端不可预测。随机生成是直接做法，其目的在于阻止攻击者利用暂时取得私钥的窗口，为可预测的未来请求预制有效的 CertificateVerify。不可预测性保护新鲜度和请求绑定。它不会把随机字节变成秘密能力、访问令牌、角色证明或业务授权书。

请求里的扩展表达 TLS 层面的选择条件。signature_algorithms 是必需项，其他扩展可以提示可接受的证书颁发机构、对象标识过滤条件或证书签名算法。它们会限制客户端可返回的认证材料，却不回答持有某张证书的人能否访问某份档案、执行某笔付款或管理另一个租户。

客户端愿意认证时，会发送 Certificate、CertificateVerify 和 Finished。CertificateVerify 证明响应端掌握与证书对应的私钥，并覆盖相关握手记录；Finished 再把认证块固定在 TLS 状态中。这些是强证据，但强度不能扩大证据主题。它们证明这条密码学对话中有人控制密钥，不证明所有上层业务规则已经满足。

客户端也可以合法拒绝提供证书：发送空的 Certificate，再发送 Finished。TLS 由此准确知道本次请求没有获得客户端证书。这个结果不天然等于用户注销、撤回同意、拒绝某项交易或作废其他凭据。是否允许匿名继续、改用第二因素或关闭连接，仍由应用协议决定。

上下文之所以必要，与握手后认证的时序有关。客户端可能需要询问用户，或者等待密码设备响应。在此期间，其他消息继续通过，多项请求也可能同时悬而未决。响应不必依照请求发出顺序返回。唯一上下文让服务器消除歧义，而不必把线路先后顺序误当成身份。

服务器只有在客户端先提供空的 post_handshake_auth 扩展时，才能发起握手后证书认证。若客户端没有声明这项能力，后续 CertificateRequest 属于意外消息并触发致命警报。然而，TLS 能力声明并不意味着每种上层协议都允许使用它。

RFC 9113 给出了鲜明反例。HTTP/2 禁止服务器发送 TLS 1.3 握手后的 CertificateRequest，客户端应把它视为连接错误。即使客户端曾声明 post_handshake_auth 也不例外，因为同一 TLS 实现可能为别的应用协议声明能力。TLS 具备某种机制，不足以推翻 HTTP/2 对连接和多路复用的治理。

证书路径是否有效，又是另一层判断。RFC 5280 所描述的路径验证，要在证书约束、所选信任锚和依赖方输入之下确认名称与公钥的绑定。信任锚的选择本身就是政策，应用还可以继续收紧路径条件。正确回显请求上下文既不选择信任锚，也不会让一条在某处有效的路径自动适用于所有用途。

因此应把三个谓词分开。第一，持有证明说明端点控制一把私钥。第二，选定的路径政策可能说明该密钥在具体信任框架下与某个认证名称绑定。第三，应用把结果映射为主体，再判断主体能对指定资源执行什么动作。前一个谓词成功，不能替后两个谓词预先作答。

RFC 9525 说明应用协议在采用 TLS 时仍需定义服务身份核验方式。该文档主要讨论服务器身份，而不是通用的客户端授权模型；但它揭示了同一结构：TLS 提供认证工具，使用它的协议负责说明参照身份以及匹配后的后果。

OAuth 双向 TLS 让分工更加可见。RFC 8705 区分基于双向 TLS 的客户端认证与证书绑定访问令牌。授权服务器依据已注册的 client_id 和本地政策检查证书，并可把令牌绑定到密钥持有证明。在资源服务器处，访问令牌仍然承载授权决定；TLS 证书和请求上下文本身不会列出允许访问的资源。

RFC 6749 把 OAuth scope 放在授权层。RFC 7662 又允许资源服务器查询令牌是否仍为 active，并获得相关元数据。上下文匹配成功不会告知令牌是否到期、撤销或缩小范围。若一条长连接只在建立时检查权限，后来发生的政策变化可能一直得不到执行。

RFC 9325 对 TLS 与 DTLS 的安全版本、算法和部署实践提出建议，却没有试图定义普适角色系统。同样，IANA TLS 参数登记表 协调可互操作的代码与名称，不替任何企业决定员工、设备或服务的权限。

运营者评估规范时，还应保留 RFC 9846 信息页 和对应的 勘误记录。RFC 8446 则有助于辨认被取代文本与迁移背景。这些来源能证明当时参考了哪版标准，却仍不能替代某次交易采用的本地授权政策。

这里可以借用卢恒的两项观察。最小初始规范 的价值，在于先解决必要协调，同时不给未来的本地决定封口；政策之镜 则要求人们找到真正作决定的位置，而不是被技术痕迹吸引。certificate_request_context 正是优秀的最小协调机制：它解决消息归属，把 TLS 无法知晓的权限问题留给应用。

错误设计往往始于命名。开发者把上下文字段称为“scope”，把临时映射称为“session role”，又把认证成功称为“authorized”。不久之后，监控面板、客户支持和审计导出都继承了这些词。原先只存在于内存中的便捷标签，逐渐被当成协议保证，但任何规范都没有为这些字节规定跨连接、跨产品的业务含义。

另一个危险是把新上下文视为权限续期。握手后认证可以再次证明密钥持有，却不会自动重新计算账户状态、许可证、令牌范围或撤销记录。相反，一条连接内的旧认证也不应永久冻结旧政策。认证事件与授权决定必须各自拥有生效时间，并明确哪些事件会触发重新评估。

清晰架构至少保留四个命名空间。TLS 记录连接、请求、上下文、握手记录与证明结果；PKI 记录证书、验证路径、信任锚和约束；应用身份层记录主体、账户、租户及绑定方法；授权层记录资源、动作、规则、决定与有效区间。它们可以用关联标识相连，但任何标识都不能冒充另一层的语义。

这种分离也改善事故处置。如果私钥泄露，团队可以查出哪些应用决定依赖该密钥，而不把上下文的每次出现假定为相同权限。如果政策改变，系统可以在 TLS 连接仍存活时停止未来动作。如果争议集中在身份映射，调查者能检查证书到主体的绑定，而不篡改握手记录对当时密码学事实的描述。

资料来源