validation - PDF 签名 - LTV - CRL 替代方案？

Question

我正在开发一个 .NET PDF 签名应用程序，该应用程序允许使用智能卡(比利时 ID)进行签名。此外，我希望签名能够支持 LTV。

我已经按照 iText 的说明和示例进行操作，它似乎运行良好。 Acrobat Reader DC 指示签名有效，并提供 LTV。
然而，存在一个实际问题:包含的 CRL 太大。我的测试 ID 上有 14MB。这意味着，每个签名需要下载 14MB，这会减慢操作速度并显着增加每个签名 PDF 的文件大小。

我想知道是否有替代方案可以包含完整的 CRL，同时仍支持 LTV？包含完整的 CRL 似乎有点矫枉过正，而唯一需要的“东西”似乎是包含一个可验证的证据，证明链中的证书在签名时尚未被撤销。我认为使用 OCSP 可能会提供这样的功能，但是简单地删除 CRL 并包含 OcspClientBouncyCaSTLe 实例并不能解决问题。提供给 SignDetached 的 OCSP 是否用于检查签名时证书是否被吊销？

一个相关问题涉及 LTV“支持”本身。正如我所提到的，Acrobat Reader 仅在包含 CRL 时才指示该文件支持 LTV。在线查询http://dss.nowina.lu/validation然而(欧盟引用)似乎表明了一些其他的东西。在那里，即使没有嵌入 CRL 的文件也会在描述“AdES-T 验证是否具有结论性？”后面进行有效检查。 (这是“长期验证数据”下的唯一检查点)。因此，我想知道是否需要包含 LTV 的 CRL？

足以说我很困惑:)。

顺便说一句，来自同一验证服务的另外 2 个警告我似乎无法解决:“‘颁发者序列号’属性不存在或不匹配!”和“SSCD 不支持签名者的证书!”。但也许这是另一个问题。

预先感谢您的帮助。

Answer 1

我查看了您的示例文档。它不符合任何 LTV 配置文件，仅符合 T 级别，即带有时间戳。

详细

PDF 签名仅通过使用子过滤器 ETSI.CAdES.detached 嵌入单个 CMS 容器来实现，其中包含

• CMS容器证书集中签名者证书的证书链

  • C=BE,CN=比利时根 CA2

  • C=BE、CN=Citizen CA、SERIALNUMBER=201103

  • C=BE、CN=Donny Tytgat(签名)、SURNAME=Tytgat、GIVENNAME=Donny Geert、SERIALNUMBER=81032305309)；

• 已签名的 Adob​​e ReplicationInfoArchival 属性，其中包含签名者证书的单个良好 OCSP 响应；响应由

  签署
  • CN=比利时 OCSP 响应程序，C=BE

  具有 id-pkix-ocsp-nocheck 扩展名；

• 签名时间戳

  • C=BE、SERIALNUMBER=2014、O=比利时联邦政府、CN=时间戳机构

因此，签名符合基线 T 级别

A PAdES signature conformant to T-Level shall be a signature conformant to B-Level for which a Trust Service Provider [i.4] has generated a trusted token (time-mark or time-stamp token) proving that the signature itself actually existed at a certain date and time.

(section 7 - Requirements for T-Level Conformance - ETSI TS 103 172 V2.2.2)

其中 B 级一致性定义为

This clause defines requirements that PAdES signatures claiming conformance to the B-Level have to fulfil. The current clause specifies compliance requirements for short-term electronic signatures.

This clause actually profiles PAdES-BES (signatures that do not incorporate signature-policy-identifier) and PAdES-EPES (signatures that do incorporate signature-policy-identifier) signatures.

(section 6 - Requirements for B-Level Conformance - ibidem)

(还满足其他要求。)

---

它不符合 LT 级别的要求:

The generator shall include the full set of revocation data (CRL or OCSP responses) that have been used in the validation of the signer, and CA certificates used in signature. This set includes all certificate status information required for validating the signing certificate, for validating any attribute certificate present in the signature, and for validating any time-stamp token's signing certificate (i.e. a TSA certificate) already incorporated to the signature.

(section 8 - Requirements for LT-Level Conformance - ibidem)

因为没有有关 CA 证书或 TSA 证书的吊销信息。

因此，它也可以不符合 LTA 级别，如

A PAdES signature conformant to LTA-Level shall be a signature conformant to LT-Level to which one or more document-time-stamp has been incorporated

关于其他问题

I was wondering if there is an alternative to including the complete CRL while still supporting LTV? It seems a bit overkill to include the complete CRL while the only "thing" that seems needed is the inclusion of a verifyable proof that the certificates in the chain have not been revoked at time of signing. I thought that use of the OCSP might offer such functionality

只要有适当的 PKI 基础设施，这是可能的。但不幸的是，CA 和 TSA 证书均不包含负责它们的 OCSP 响应者的信息。因此，比利时公民 PKI 要么不为这些证书提供 OCSP 服务，要么只是不公开该规定。

顺便说一句，这就是诊断树的评论

<Message Id="0">OSCP Uri not found in certificate meta-data !</Message>

是使用 http://dss.nowina.lu/validation 验证签名时得到的信息服务。

There, even the file without the embedded CRL has a valid check behind the description "Is AdES-T validation conclusive?" (which is the only checkpoint under "Long Term Validation Data").

此用户界面布局误导了您，如上所述，对 LTV 相关配置文件有更多要求。