摘要

  • RFC 3183 是 2001 年发布的实验性方案，允许邮件传输代理、边界守卫和网关代表组织处理 S/MIME；域签名可以证明组织在完成内部核验后放行消息，却未必向外部收件人提供可独立验证的个人姓名。
  • 发件人签名、域签名、审查签名、附加属性签名以及域加解密分别代表不同动作。把它们压成一个“可信”状态，会抹掉责任边界。

一封邮件可以在密码学上正确“已签名”，同时仍有五个问题没有回答：内容是谁写的？组织用什么证据认出了他？谁决定让邮件越过边界？谁只批准了转发？谁能在途中看到明文？RFC 3183 的价值，正在于它没有让一个签名替所有问题作答。

这份名为 Domain Security Services using S/MIME 的 RFC 于 2001 年 10 月以 Experimental 状态发布。它面对的是当时很实际的组织边界：终端用户没有桌面 PKI，内外系统采用不同消息格式或证书体系，邮件存储会改写内容，机构又需要检查、审计和策略执行。邮件传输代理、守卫、防火墙与协议转换网关因而可能代表整个安全域处理 S/MIME。文件没有宣判“端到端”和“域代办”谁必然正确，只提供可组合的机制。

第一种是发件人签名。它把发件人的证书身份与内容联系起来。第二种是域签名，RFC 称之为代理签名。域签名者在生成它之前，必须先认证发件人：可以验证内层个人签名，也可以采用 S/MIME 之外的认证链路；同时还要核验所依赖的其他签名。认证失败时，不得生成域签名。

但“域内部已经认出某个人”和“外部收件人能够显示这个人的证书姓名”不是同一事实。若消息保留发件人签名，收件方可以依据该证书识别个人。若没有发件人签名，RFC 3183 明确把可作出的假定收窄到来源域。组织可能确实知道内部员工是谁；外部世界拿到的仍是组织的可验证陈述，而不是那名员工独立可验的个人证书。

这条边界把现实动作、组织判断、协议表示和收件方观察分开。某人创作了内容；内部系统认证了某个主体；域权限者决定放行一种消息表示；收件人验证到了域签名。四件事可以相互支撑，却不能被一句“个人已认证”替代。

审查签名证明另一种权力：具名审查者或审查机构批准消息继续传输。边界守卫可以把它作为放行条件，但审查者不会因此成为作者。RFC 3183 也明确指出，这种签名不认证发件人。它更不自动证明内容真实、合法、安全、已投递或已被接受。它只证明一项较窄的策略决定发生过。

附加属性签名则把 SignerInfo 中的属性绑定到消息。核验成功能够说明哪一个属性权限者把哪些属性字节同哪些内容绑在一起；它不能单独证明属性指向的外部事实准确、仍然有效，或足以支持日后的另一项决策。密码学能固定一种表示关系，不能让表示自动变成现实。

为了避免这些含义互换，RFC 3183 定义了带类型的 SignatureType 签名属性。后来经核准的 Erratum 3757 补上原文遗漏的属性对象标识符：id-aa-signatureType，即 1.2.840.113549.1.9.2.28。这项修正让实现能够准确识别属性，却没有扩大任何签名的权限。补全标签，不会让审查签名变成作者签名。

加密又引入了托管边界。域机密权限者可以代表用户或域加密与解密。这能解决互操作和策略问题，也会把大量用户的密钥风险集中到一处。收件域权限者完成解密后，明文就会在该边界之后存在。如果权限者被攻破，而终端又没有能独立验证的幸存签名，那么权限者自己声称“核验成功”并不能替终端保证完整性。

RFC 对邮件列表和嵌套 CMS 对象的处理尤其说明顺序的重要性。网关可能先验证一层、解密一层、移除封装、保留部分签名属性、增加新的域签名、再次加密，再用另一层保留邮件列表扩展历史。因此，“消息有签名”不是一种脱离时间与位置的属性。必须记录哪一层的哪些字节，由哪个证书、以哪种签名类型，在哪一次变换前后签署。

同期 S/MIME、CMS 和增强安全服务 RFC 提供了容器与属性；后来的 CMS、S/MIME 与 PKIX 文档更新了标准背景。它们都不能倒推 RFC 3183 曾被广泛部署，也不能把 Experimental 变成互联网标准。IANA 登记能证明标识符被分配，不能证明真实使用。

这段历史最持久的启示，是把“安全”重新写成一串有主语的动词：个人创作，域认证并放行，审查者批准传输，属性权限者完成绑定，机密权限者打开密文，收件人观察结果。只有保留这些主语，系统才有可能在争议发生后还原谁行使了什么权力。