eCoC XML 签名：XMLDSig、XAdES、eIDAS 与 NAP 验收边界

先区分四个层次

eCoC 项目中经常把 XMLDSig、XAdES、eIDAS 和 qualified certificate 混成一个要求。它们实际回答不同问题：

层次	回答的问题
XMLDSig	如何对 XML 节点、引用和摘要进行密码学签名
XAdES	如何在 XML 签名上增加签署时间、证书、策略与长期验证属性
eIDAS	电子签名、印章、信任服务和法律等级如何定义与监管
NAP policy	哪个主体、证书、profile 和封装能通过该入口的实际验收

Implementing Regulation (EU) 2024/1061 要求相关电子交换使用电子签名，并验证签署时满足 eIDAS Article 26。它不等于在法规正文中统一指定所有 NAP 必须采用某个 XAdES-T、B-LT、QES 或 QeSeal 配置。

XMLDSig 是基础签名结构。XAdES 建立在 XMLDSig 之上，通过 qualifying properties 增加签署时间、证书引用、策略、时间戳或验证材料。

具体项目需要锁定：

签名完成后，任何对被引用 XML 的重写、格式化或命名空间调整都可能导致验签失败。

自然人电子签名和法人电子印章在 eIDAS 中是不同对象。对企业批量签发单车 eCoC，电子印章往往更符合组织化自动处理需求，但最终仍需确认签署主体是否与制造商或获认可的 EU representative 匹配。

以 RDW 的公开说明为例，其最低路径是 advanced electronic seal，qualified seal 可以使用但不是该 NAP 的统一最低要求。因此，对外不能声称“eCoC 必须使用 QES / QeSeal”。

成员国 Trusted List 是判断具体信任服务在特定时间是否具有 eIDAS qualified 状态的法律信息源，EU LOTL 则提供各国列表的机器可读入口和验证链。

核验时需要落到：

“供应商是欧洲 CA”“证书链能连到某个根”或“产品支持 PDF 签名”都不足以证明该证书可以用于目标 NAP 的 eCoC XML。

EU Trusted Lists 能回答信任服务的法律状态；DSS 能按配置的信任源和策略执行签名验证。NAP 还可能要求：

因此，“DSS 验证通过”与“NAP 测试通过”应分开记录。

如果选择 qualified 路径，还需满足该服务和签名/印章创建设备对应的 eIDAS 要求；不能只因为使用了通用 HSM 就自动宣称 qualified。

签名 PoC 不应只展示一个成功文件。至少测试：证书主体不匹配、证书链缺失、证书过期或吊销、引用节点错误、签后改写、时间戳不可用、NAP 未登记证书和算法不支持。

最终验收证据应同时包含本地独立验签报告和目标 NAP 的测试回执。

本文核验至 2026 年 7 月 30 日。具体签名 profile 与证书登记要求以所选 NAP 当前文件和测试结果为准。