1. Introduction

本节介绍 unsigned X.509 certificates 的背景, 包括 self-signed certificates 的 placeholder 用法及其局限.
RFC 文本

1.  引言

   X.509 证书 [RFC5280] 在 PKI 中关联两个实体: 关于主体 (subject)
   的信息, 以及来自签发者 (issuer) 的证明. 如果像 [RFC4158] 那样将
   PKI 视为以实体为节点的图, 则证书就是主体与签发者之间的一条边.

   在某些上下文中, 应用程序需要的是独立的主体信息, 而不是证书. 在图
   模型中, 应用程序需要的是节点, 而不是边. 例如, 认证路径验证
   ([RFC5280] 第 6 节) 从信任锚 (trust anchor) 开始, 信任锚有时也称
   为根证书颁发机构 (root certification authority, root CA). 应用程序
   通过带外方式信任该信任锚信息, 并不需要签发者的签名.

   X.509 没有为这种场景定义结构. 因此, X.509 信任锚通常用
   "self-signed" 证书表示, 即主体的密钥对自身进行签名. 也存在其他
   用于传递信任锚的格式, 例如 [RFC5914], 但 self-signed 证书仍被广泛
   使用.

   此外, 一些 TLS [RFC8446] 服务器部署在不打算呈现 CA 签发的身份时,
   会使用 self-signed 终端实体 (end entity) 证书, 而是期望依赖方通过
   带外方式认证该证书, 例如通过已知指纹.

   这些自签名通常没有安全价值, 接收方也不会检查它们, 它们只是作为
   placeholder 来满足 X.509 证书的语法要求.

   将签名作为 placeholder 计算有一些缺点:

   *  后量子签名算法体积较大, 因此包含 self-signature 会显著增加
      payload 的大小.

   *  如果主体是终端实体而不是 CA, 计算 X.509 签名可能使该密钥的预期
      用途面临跨协议攻击风险.

   *  这种 self-signature 是否要求 basic constraints 中的 CA bit 或 key
      usage 中的 keyCertSign 并不明确. 如果该密钥预期用于非 X.509 用途,
      声明这些能力会带来不必要的风险.

   *  如果主体是终端实体, 且该终端实体的密钥不是签名密钥 (例如 Key
      Encapsulation Mechanism (KEM) 密钥), 则不存在可与该密钥配合使用的
      有效 signature algorithm.

   本文档定义了 unsigned X.509 certificates 的 profile. 当证书被用作
   主体信息的容器且没有任何特定签发者时, 可以使用该 profile.
RFC 文本​

RFC 文本
