合格签名完整解析

Spec: ETSI EN 319 411-2 Spec: ETSI EN 319 411-1 Spec: ETSI EN 319 421 Evidence: Standard-backed

一览

「合格」是欧盟 eIDAS 规章下的一种法律地位，而不是库可以授予的属性。它需要多个参与方分别完成特定职责：一份合格凭证、一个合格签名创建设备、一个合格信任服务提供者，以及已公布的信任清单。本页说明这些角色，并明确指出 NextPDF 所承担的那个有限部分，以及它并不承担的那些更大的部分。

为何重要

一个 qualified electronic signature 在其适用管辖范围内，具有法律赋予的效力。这正是「合格」吸引人的地方，也正是草率宣称它危险的原因。假设某个工作流程被描述为能够产生合格签名，但链中有一个角色缺失——凭证并非合格、设备并非 QSCD、提供者并未列于信任清单上。那么这些签名就不是合格签名。这个缺口通常会在最关键的时刻暴露出来：一场争议、一次审计、一项跨境承认检查。

困难在于：一个完全有效的高端签名与一个合格签名，在 PDF 查看器中可能看起来一模一样。差别在于凭证、设备、提供者与信任清单；这些没有一项由签署引擎提供。关键是准确知道哪一个参与方掌握哪一项保证。

简短版本

合格是一条链，而非一项功能。 它需要一份由合格信任服务提供者签发的合格凭证、一次在 QSCD 上完成的签署，以及可通过信任清单查询到的合格服务状态。缺少其中任何一项，结果都不再是合格签名。
QSCD 是强制的。 根据合格凭证政策，签名必须仅由一个合格签名创建设备创建。 Spec: ETSI EN 319 411-2, §6.3.5
唯一控制权属于签署者与设备。 私钥必须处于签署者的唯一控制之下，并保存在一个能够保护它、代表用户签署的设备中。 Spec: ETSI EN 319 411-1, §6.3.5
NextPDF 的部分既狭窄又诚实。 它会组装结构正确的 PDF 签名，并且可以嵌入一个受信任的时间戳记与长期验证材料。它并非 QSCD、并非（合格的）信任服务提供者；它不签发凭证、不运营信任清单，也不授予合格地位。

NextPDF 如何看待这件事

逐一指名各个角色

一个 qualified electronic signature——在 eIDAS 之下——由彼此独立的责任构成。NextPDF 只占其中一格；其余格子属于引擎之外的参与方与标准。

Step 1 of 5: eIDAS Regulation (EU) 910/2014 defines "qualified" and its legal effect — the legal frame
Step 2 of 5: ETSI EN 319 411-1 / 411-2 qualified certificate policy; QSCD mandatory; sole control
Step 3 of 5: ETSI EN 319 412-5 qualified-certificate profile — the QC statements
Step 4 of 5: ETSI EN 319 421 / RFC 3161 trusted time from a TSP issuing time-stamps
Step 5 of 5: ISO 32000-2 §12.8 the PDF signature carrier NextPDF builds

一个 qualified electronic signature 依序所走过的那条链，以及每一环节由谁掌握：合格凭证、QSCD、合格信任服务提供者与信任清单都不是签署引擎——NextPDF 只负责组装 PDF 签名载体，并可加上受信任的时间与验证材料。

合格凭证。 签发给签署者，并携带 QC 声明，以机器可读形式标示它是一份用于电子签名的合格凭证，同时标识签发它的那个合格信任服务提供者。 Spec: ETSI EN 319 412-5, §4.2 NextPDF 不签发它。
QSCD。 一个合格签名创建设备——以 ETSI 的用语来说，是一个保管用户私钥、防止其泄漏，并代表用户执行签署的安全密码设备。 Spec: ETSI EN 319 411-1, §3.1 NextPDF 是通过这样一个设备完成签署的软件；引擎本身并不是 QSCD，它的软件密钥路径也不是。
合格信任服务提供者。 QTSP 签发合格凭证，并接受监督；政策要求这些凭证之下的签名只能由一个 QSCD 创建。 Spec: ETSI EN 319 411-2, §6.3.5 NextPDF 并不是信任服务提供者。
信任清单。 信赖方用来确认提供者与服务曾属合格的已公布证据。NextPDF 既不运营信任清单，也不为其背书。

NextPDF 所扮演的那个狭窄部分

在这条链中，NextPDF 的工作有限且具体。它组装 PDF 签名：放置签名字段、计算字节范围，并构建 CMS SignedData，也就是标准要求 Contents 项目必须保存的内容。 Spec: ISO 32000-2, §12.8 当签署密钥位于 QSCD 上时，NextPDF 会跨过 HSM 支持的签署中描述的同一道硬件边界，通过它完成签署，而密钥始终留在设备上。

NextPDF 也可以嵌入让签名保持长期可验证的两项要素：来自时间戳记机构的受信任时间戳记，以及长期验证材料。时间戳记是受信任第三方对某项数据在某个特定时刻之前已经存在所作的证明 Spec: RFC 3161, §1 ；在欧盟框架中，该机构是在一项适用于签发时间戳记之信任服务提供者的政策下运营的。 Spec: ETSI EN 319 421, §1 NextPDF 请求并嵌入这个令牌。它并不运营该时间戳记机构；嵌入一个时间戳记本身，也不会让一个签名成为合格的。

证据怎么说

Evidence: Standard-backed QSCD 的要求在合格凭证政策中写得很明确：订户（或代管的 TSP）的义务要求数字签名仅由一个 QSCD 创建。 Spec: ETSI EN 319 411-2, §6.3.5 设备本身被定义为一个保管用户私钥、防止其泄漏，并代表用户执行签署的设备 Spec: ETSI EN 319 411-1, §3.1 ；对于自然人私钥必须处于签署者的唯一控制之下。 Spec: ETSI EN 319 411-1, §6.3.5 一个签署库无法代表这条链履行其中任何一项义务。

Evidence: Standard-backed 让一份凭证成为合格的，是凭证中携带的 QC 声明：其中包含机器可读的指示，表明它是作为一份用于电子签名的合格凭证签发的，并包含标识签发它的那个合格信任服务提供者的数据。 Spec: ETSI EN 319 412-5, §4.2 一个使用一份凭证来构建签名的库，并不会让这份凭证成为合格；签发它的那个 QTSP 才会。

Evidence: Standard-backed 受信任的时间有它自己的提供者角色。RFC 3161 将时间戳记机构定义为一个受信任第三方，它为某项数据在某个时间瞬间提供存在性证明 Spec: RFC 3161, §1 ；ETSI EN 319 421 规定了适用于签发时间戳记之信任服务提供者的政策与安全要求，这些时间戳记可支持数字签名，或证明某项数据在某个特定时间之前已经存在。 Spec: ETSI EN 319 421, §1 NextPDF 嵌入来自这样一个提供者的令牌；该提供者的合格地位，若有的话，属于该提供者，而非引擎。

实际范例

没有任何 API 能「让一个签名成为合格的」；如果代码范例暗示事实并非如此，那段范例本身就是错误的。这里真正有用的产物，是一份审查者可以使用的责任检查清单：

链中的环节	由谁掌握	NextPDF 的部分
签发合格凭证	合格信任服务提供者	使用它；不签发它
在 QSCD 上签署	签署者＋设备	通过它签署；本身不是 QSCD
私钥唯一控制	签署者＋设备	在 QSCD 上时绝不持有密钥
提供者/服务属合格	QTSP ＋监督	对此不作任何主张
可通过信任清单探查到	信任清单运营者	不运营也不检查它们
PDF 签名结构良好	签署引擎	这是 NextPDF 的格子
嵌入受信任时间戳记	时间戳记机构	请求并嵌入该权杖
长期验证材料	signing/validation 流程	可以嵌入它（见「相关文档」）

如果引擎那一格之上的任何一列未被满足，结果——充其量——是一个有效的高端签名，而非一个合格签名。NextPDF 可以让它所掌握的每一列都成立，却仍然无法让签名成为合格的，因为这个地位并非引擎所能授予。

常见误解

「NextPDF 会产生合格签名。」

它不会，而且措辞必须精确。NextPDF 会产生结构正确的 PDF 签名，并且兼容于在 QSCD 上签署以及嵌入合格提供者的时间戳记。某个特定签名是否合格，取决于部署：它取决于一份合格凭证、一个 QSCD、一个合格信任服务提供者，以及信任清单地位——这些没有一项由引擎提供或认证。正确的说法是「NextPDF 组装签名；合格地位来自凭证、设备与提供者。」说得更多，就是在过度宣称一种软件无法授予的法律地位。

限制与边界

这道边界必须直白陈述，不能淡化：

NextPDF 是什么。 一个 PDF 2.0 签署引擎。它依照 Spec: ISO 32000-2, §12.8 构建签名，在获得设备时通过该设备签署，并且可以嵌入时间戳记与长期验证材料。
NextPDF 不是什么。 它并非 QSCD、并非一个合格（或任何）信任服务提供者、并非一个证书颁发机构，也并非一个信任清单运营者。它不评估、不确认，也不授予合格地位。
「符合于」并非「已认证」。 这是一项结构性陈述：NextPDF 构建符合于 PDF 签名标准的签名，并且可以携带 AdES 配置文件所预期的那些元素。它并非对任何由此产生的签名为合格的一项认证，也不能取代那些共同使其成立的 QSCD、凭证、提供者与信任清单条件。
管辖范围至关重要。 「合格」及其法律效力是由 eIDAS 规章在其适用范围内所定义的。本页是一份工程说明，而非法律意见。某个签名对于特定用途是否具有法律充分性，是适用法律与当事方法律顾问的问题，而非库文档的问题。

Qualified-signature support — edition availability
Edition	Availability
Core	Core 构建 PDF 签名载体与 CMS 容器。它本身并不对合格地位作出贡献。
Pro	Pro 加入受管理密钥签署与签名增强，并在行为层级加以描述。它仍然不是一个 QSCD，也不是信任服务提供者。
Enterprise	Enterprise 加入通过 PKCS#11 的硬件令牌签署，因此签署密钥可以存放在由某个部署作为 QSCD 来运营的设备上。引擎通过该设备签署；合格地位仍然属于凭证、设备与提供者——绝不属于引擎。

迷你常见问答

高端签名与合格签名是同一回事吗？ 不是。它们在查看器中可能看起来一模一样。合格签名另外还需要一份合格凭证、一个 QSCD，以及一个合格信任服务提供者；高端签名则不需要。差别在于那条链，而不在 PDF 字节。

在 HSM 上签署会让签名成为合格的吗？ 光凭这一点不会。QSCD 是必要条件，但并不充分。凭证必须是一份来自合格信任服务提供者的合格凭证，而且设备必须符合该部署的 QSCD 标准。一个通用的 HSM 并不会自动成为一个 QSCD。

加入一个时间戳记会让签名成为合格的吗？ 不会。一个受信任的时间戳记会强化持久性与时间证明；它并不提供那些定义合格地位的凭证、设备或提供者条件。它对于长期设置档是必要的，但对于合格地位并不充分。

NextPDF 能告诉我我的签名是否合格吗？ 不能。引擎对于合格地位不作任何主张。确立它是凭证、设备、提供者、信任清单与适用法律的问题——超出引擎的责任范围。

词汇表

合格电子签名（Qualified electronic signature）——在 eIDAS 规章之下，是由 QSCD 创建、并基于一份合格凭证的高端电子签名；它是一种法律地位，而非一项软件功能。
eIDAS——欧盟关于电子识别与信任服务的第 910/2014 号规章 (EU)；定义「合格」及其效力的法律框架。
QSCD（合格签名创建设备）——一个符合 eIDAS 标准的设备；以 ETSI 的用语来说，是一个保管用户密钥、保护密钥，并代表用户签署的安全密码设备。
合格凭证（Qualified certificate）——一份由合格信任服务提供者签发的凭证，其 QC 声明以机器可读方式标示它为用于电子签名的合格凭证。
QTSP（合格信任服务提供者）——一个受监督的信任服务提供者，签发合格凭证与相关合格服务。
信任清单（Trusted list）——信赖方用来确认某个提供者与服务曾属合格的已公布证据。
唯一控制（Sole control）——一项义务，要求自然人签署者的私钥被保管在该签署者的唯一控制之下。
时间戳记机构（Time Stamp Authority，TSA）——一个为某项数据在某个时间瞬间提供存在性证明的受信任第三方（RFC 3161）。