2026年8月18日
CAdES（CMS 高级电子签名，CMS Advanced Electronic Signatures）是 ETSI 标准——EN 319 122——用于在加密消息语法（CMS）之上构建高级电子签名。CMS 格式定义于 RFC 5652，最初称为 PKCS#7。通俗地说：CAdES 在常规 CMS/PKCS#7 数字签名的基础上，加入了必要的签名属性，用来证明是谁签的、什么时候签的、以及签署后数据未被改动。它最常用于签署任意数据或文件（软件包、电子发票、登记记录、交易报文），而不是面向可视化呈现的 PDF 文档——那是 PAdES 的领域——也不是 XML 原生数据，那属于 XAdES 的范畴。
如果你的团队在欧盟运营或向欧盟销售，CAdES 之所以重要，是因为它是 ETSI 为满足 eIDAS 对高级电子签名和合格电子签名的要求而标准化的三种签名格式之一。本文将讲清 CAdES 是什么、它如何满足 eIDAS 高级签名要求、各基线 Profile 分别增加了什么，以及在真实系统中如何在 CAdES、PAdES、XAdES 之间做选择。
CAdES 是什么？
CAdES 是 CMS Advanced Electronic Signatures 的缩写。现行规范是 ETSI EN 319 122，它定义了如何使用 CMS SignedData 结构构建电子签名——这正是 S/MIME 邮件、代码签名和众多 PKI 应用所使用的二进制封装格式（RFC 5652，历史上的 PKCS#7）。
一个普通的 CMS 签名本身已经包含签署者证书，以及对内容（或对签名属性）计算出的签名值。CAdES 在此基础上增加了一组受控的签名属性和未签名属性，把一个原始的密码学签名变成一份具有证据效力的对象：
- 签名证书（signing-certificate）属性：将签名绑定到具体的签署者证书，防止证书替换攻击。
- 签名时间戳（signature time-stamp）：由可信时间源出具的时间戳，证明签名在某一时刻已经存在。
- 完整验证数据（更高层级 Profile）：内嵌的证书链、吊销响应（CRL/OCSP）以及后续的归档时间戳，使签名在密钥过期、CA 消失之后很久仍可验证。
由于 CAdES 与内容无关，被签的载荷可以是任何东西：一个二进制文件、一笔 JSON 交易、一批记录。这使它成为系统间签名、某些法域的电子发票流水线、签名数据集的长期归档，以及任何被签对象不是人类可读 PDF 的工作流的自然选择。
CAdES 如何满足 eIDAS 高级电子签名要求
在 eIDAS 下，高级电子签名（AdES）必须满足四项要求：与签署人唯一关联、能够识别签署人、使用签署人独自控制的签名创建数据生成、并与被签数据相关联从而任何后续改动都可被检测。
CAdES 的设计正是为了让合规签名能够证明以上四点：
- 唯一关联与识别：签名内嵌了对签署者证书的引用，该证书由 CA 在完成身份核验后签发。
- 独自控制：产生签名的私钥仅由签署人持有（存放在令牌、HSM 或由其控制的远程签名服务中）。格式本身无法强制这一点，但 CAdES 是承载和证明此类"独自控制"签名的容器。
- 篡改检测：签名是针对内容计算的（通过包含消息摘要在内的签名属性），任何修改都会在数学上使签名失效。
当签名密钥存放在合格签名创建设备（QSCD）中、且证书为合格证书时，同样的 CAdES 结构就构成合格电子签名（QES）——eIDAS 的最高等级，在整个欧盟与手写签名具有同等法律效力。关于法律等级的深入解读，请参阅我们的高级电子签名作为商业标准、合格电子签名，以及实践中符合 eIDAS 的电子签名需要满足什么条件的相关指南。
CAdES 基线 Profile：B-B、B-T、B-LT、B-LTA
ETSI 定义了四个基线 Profile。每个 Profile 都在前一个的基础上叠加属性，延长签名可被验证的时间跨度并提升验证可信度。
一个实用的理解方式：B-B 是高级签名的底线；B-T 是大多数商业交易的合理默认；B-LT 适合需要按保存期限留存的合同与记录；B-LTA 面向法定保存期长达多年的归档级证据。注意，CAdES-B-LT 和 B-LTA 签名通常是在既有签名之上追加验证数据而生成的——这项工作往往由接收方系统或归档服务完成，而非签署人。
分离式签名与内嵌式签名
CMS SignedData 支持两种打包方式，CAdES 两者都继承：
- 内嵌式（enveloping，attached）：被签内容嵌入签名结构内部。一个文件承载一切，便于存储和传输，但接收方需要支持 CMS 的工具才能提取内容。
- 分离式（detached）：签名结构中只有签名本身，内容存放在独立文件中。原始文件保持字节级不变、可被任何工具读取，但你必须同时保存和传输两个部分——丢失分离式签名就意味着丢失证据。
当被签产物必须能被非密码学系统使用（例如下游流水线要解析的数据文件）时，选择分离式签名；当一个自包含的证据包比载荷的直接可读性更重要时，选择内嵌式签名。
CAdES vs PAdES vs XAdES：如何选择格式
三种 ETSI AdES 格式共享同一套基线 Profile 逻辑（B-B、B-T、B-LT、B-LTA）和同样的 eIDAS 目标，区别在于它们签署的容器。
经验法则：
- 签署人们会阅读和打印的文档 → PAdES。我们的 PDF 高级电子签名 PAdES 指南和什么是面向 PDF 的 PAdES详解了这条路径。
- 在文档级或元素级签署 XML（符合 EN 16931 Profile 的电子发票、SOAP/XML 服务）→ XAdES。
- 签署任意文件、数据块或批量数据，且已有 CMS/PKCS#7 工具链 → CAdES。
在同一 Profile 层级上，三者没有谁"更强"；选择取决于你的生态使用哪种数据格式。
验证与长期归档
创建 CAdES 签名只是故事的一半；验证它——今天以及十年后——是另一半。B-LT 或 B-LTA 签名的验证可以离线进行，因为所需的一切（证书链、吊销数据、时间戳）都随签名携带。而裸 B-B 签名的验证依赖对 CA 吊销服务的实时访问，多年后这些服务可能已不存在。
一个健全的验证流程会检查：签名的密码学完整性、到可信根的证书路径、所声称签署时刻的吊销状态、时间戳令牌本身的有效性，以及（对 B-LTA）归档时间戳链条。关于日常检查签名的实操层面，请参阅我们的数字签名验证指南。
对于长期归档，把"B-LTA + 定期重新加盖时间戳"当作标准模式：随着哈希或签名算法老化，归档方用当前算法加盖新的归档时间戳，无需原始签署人再次参与，即可保全证据效力。
企业落地建议
在将 CAdES 定为标准之前，几条务实的建议：
- 先确认你的生态的期望。如果合作伙伴、监管机构或行业方案（电子发票网络、海关、登记系统）指定了格式，遵从其要求；当对方只说"AdES"时，让容器匹配你的数据。
- 任何交易性签名至少默认使用 B-T；TSA 时间戳的边际成本相对其证据价值微不足道。
- 规划好由谁追加验证数据。从 B-T 升级到 B-LT 需要在验证时捕获吊销证据——把这一步明确指派给你的接收/归档系统。
- 当你需要 QES 级效力时，优先选用合格证书，并在需要时使用 QSCD 或同等合格的远程签名服务。
- 不要自己手写 CMS。使用持续维护的库，或已处理好 Profile 合规、TSA 集成和验证数据捕获的签名平台；细微的属性错误会悄无声息地破坏合规性。
用 Nota Sign 构建合规的高级电子签名
Nota Sign 是法大大旗下的全球电子签名平台，其基础设施连续多年被 IDC 评为中国电子签名软件市场第一。平台支持 SES、AES、QES 三个签名等级，覆盖 100+ 国家和地区，具备深厚的亚太合规能力——包括香港的 iAM Smart 和新加坡的 Singpass——并设有区域数据中心以满足数据驻留要求。
无论你的工作流需要对合同做基于 PDF 的 PAdES 签名，还是对数据载荷做基于 CMS 的签名，Nota Sign 的平台和 API 都会处理证书管理、可信时间戳和长期验证证据，让你的团队不必自己搭建底层管道。定价设计对成长型团队友好：小型企业无按席位收费，中大型及企业级需求可提供定制方案。
准备好讨论你的合规架构了吗？联系 Nota Sign 团队，聊聊你的签名格式与验证需求。
