摘要

  • RFC 2015 采用 RFC 1847 的 multipart/signed：第一部分保留可读的 MIME 实体，第二部分携带分离式 PGP 签名，但第一部分的内容头也在签名覆盖范围内。
  • 七位传输、CRLF、Quoted-Printable 或 Base64、行首 From 与行尾空格并非排版细节；它们决定收发双方能否计算出同一组字节。
  • 验证成功只证明特定字节、签名与公钥之间的关系，不能单独证明真实身份、授权、意图、送达、阅读或后续结果。

RFC 2015 示例中最值得注意的，并不是那块 ASCII 装甲格式的签名，而是第一段 MIME 内容每一行前面的标记。正文和内容头一起构成签名输入。人看到的是一句西班牙语和一个玩笑；验证器面对的却是严格排序的字节流。

这解决了早期方案的可用性问题。先前的 application/pgp 形式要求软件解析 PGP 专用结构，才能取回被签名的正文。RFC 1847 提供了与具体安全协议无关的双部件框架，RFC 2015 把 PGP 绑定到它：第一部分是签名对象，第二部分是 application/pgp-signature。即使客户端不会验证 PGP，也仍能理解 MIME 结构和处理其中内容。

这种分离并没有让正文脱离密码学，反而明确了边界。发送端先确定文本表示，将换行规范化为 CRLF，再施加 Content-Transfer-Encoding，随后加入同样使用 CRLF 的 MIME 内容头，最后才对头部和编码后的数据计算分离式签名。若只签正文，网关便可能改动 Content-Type 或 Content-Transfer-Encoding，使相同字节获得不同解释。

旧式 SMTP 的七位限制把这套次序变成现实约束。遇到不支持八位内容的下一跳，网关会把邮件转成 Quoted-Printable 或 Base64。这有利于送达，却改变了签名后的第一部分。因此，发送端必须在签名前就把内容变成传输安全的七位形式，让“将要运输的表示”就是“已经签名的表示”。

最脆弱的地方往往非常不起眼。邮箱软件可能在行首 From 前加上 >，某些网关会删除行尾空格，本地邮件程序又可能用不同的换行规则存储文本。RFC 2015 的例子主动编码了这些位置；RFC 3156 后来进一步规定接收端恢复 CRLF、处理尾随空白，并澄清最后一行不能凭空增加本未参与签名的结束符。

只有加密而没有签名的对象可以保留八位内容，因为接收端从不透明的 OpenPGP 数据中解密出内部对象。分离式签名不同：接收端已经持有可读的第一部分，必须再次哈希与发送端完全相同的表示。即使先签名再加密，内部被签名对象仍受七位规范约束。

RFC 2480 随后把网关冲突变成政策选择。面向不支持 MIME 的环境，网关必须能够原样隧道传递安全 multipart；也可以为了可读性拆解 multipart/signed，但这会破坏签名。此时应保留签名并明确警告，而不是让证据消失。由网关代验或重新签名则引入新的密钥保管者和信任终点，因此默认应关闭。

这也限定了验证结论。成功意味着验证器还原了预期 MIME 实体，并用某把公钥验证了签名；公钥代表谁，需要另一套信任记录。结果本身不能证明是谁写下文字、签署者是否有组织授权、邮件是否送达、用户是否看见受保护的表示，也不能证明某项交易发生。失败同样不能直接归咎于攻击者：恶意篡改、网关转换、换行差异、存储损坏、错误密钥或构造错误都可能导致失败。

RFC 2015 留下的关键问题因此不是“有没有签名图标”，而是：网络究竟承诺不再改写哪一种表示？

来源