PDF 签名 - LTV - CRL 替代方案？
PDF Signature - LTV - CRL alternative?
我正在开发一个允许使用智能卡（比利时 ID）签名的 .NET PDF 签名应用程序。另外，我希望签名支持LTV。
我已经按照 iText 中的说明和示例进行操作，它似乎运行良好。 Acrobat Reader DC表示签名有效，并提供LTV。
然而，存在一个实际问题：包含的 CRL 太大。我的测试 ID 上有 14MB。这意味着，对于每个签名，需要下载 14MB，这会减慢操作速度并显着增加每个签名 PDF 的文件大小。
我想知道是否有替代方案来包含完整的 CRL，同时仍然支持 LTV？包含完整的 CRL 似乎有点矫枉过正，而似乎唯一需要的 "thing" 是包含一个可验证的证明，证明链中的证书在签名时没有被撤销。我认为使用 OCSP 可能会提供这样的功能，但是简单地删除 CRL 并包含一个 OcspClientBouncyCastle 实例并不能解决问题。提供给 SignDetached 的 OCSP 是否用于检查证书是否在签名时被吊销？
一个相关问题涉及 LTV "support" 本身。正如我所提到的，Acrobat Reader 仅在包含 CRL 时表示该文件支持 LTV。然而，检查在线服务 http://dss.nowina.lu/validation（欧盟参考）似乎表明了其他事情。在那里，即使没有嵌入式 CRL 的文件在描述 "Is AdES-T validation conclusive?" 后面也有一个有效检查（这是 "Long Term Validation Data" 下唯一的检查点）。因此，我想知道是否需要为 LTV 包含 CRL？
足以说明我很困惑 :)。
顺便说一句，我似乎无法解决来自同一个验证服务的另外 2 个警告："The 'issuer-serial' attribute is absent or does not match!" 和 "The signer's certificate is not supported by SSCD!"。但也许那是另一个问题。
在此先感谢您的帮助。
我看过你的示例文档。它不符合任何 LTV 配置文件，仅符合 T 级别，即它带有时间戳。
详细
PDF 签名仅通过使用包含
的子过滤器 ETSI.CAdES.detached 嵌入单个 CMS 容器来实现
CMS容器证书集中签名者证书的证书链
C=BE,CN=比利时根 CA2
C=BE,CN=公民CA,SERIALNUMBER=201103
C=BE,CN=Donny Tytgat（签名）,SURNAME=Tytgat,GIVENNAME=Donny Geert,SERIALNUMBER=81032305309);
一个签名的 Adobe RevocationInfoArchival 属性包含对签名者证书的单个良好 OCSP 响应；响应由
签名
- CN=比利时 OCSP 响应者，C=BE
具有 id-pkix-ocsp-nocheck 扩展名；
签名时间戳
- C=BE,SERIALNUMBER=2014,O=比利时联邦政府,CN=时间戳机构
因此，签名符合 Baseline T-Level 为
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-Level：
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-Level，因为
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 服务，要么只是不提供该服务 public。
顺便说一句，这就是诊断树的评论
<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 相关的配置文件有更多要求。
我正在开发一个允许使用智能卡（比利时 ID）签名的 .NET PDF 签名应用程序。另外，我希望签名支持LTV。
我已经按照 iText 中的说明和示例进行操作，它似乎运行良好。 Acrobat Reader DC表示签名有效，并提供LTV。
然而，存在一个实际问题：包含的 CRL 太大。我的测试 ID 上有 14MB。这意味着，对于每个签名，需要下载 14MB，这会减慢操作速度并显着增加每个签名 PDF 的文件大小。
我想知道是否有替代方案来包含完整的 CRL，同时仍然支持 LTV？包含完整的 CRL 似乎有点矫枉过正，而似乎唯一需要的 "thing" 是包含一个可验证的证明，证明链中的证书在签名时没有被撤销。我认为使用 OCSP 可能会提供这样的功能，但是简单地删除 CRL 并包含一个 OcspClientBouncyCastle 实例并不能解决问题。提供给 SignDetached 的 OCSP 是否用于检查证书是否在签名时被吊销？
一个相关问题涉及 LTV "support" 本身。正如我所提到的，Acrobat Reader 仅在包含 CRL 时表示该文件支持 LTV。然而，检查在线服务 http://dss.nowina.lu/validation（欧盟参考）似乎表明了其他事情。在那里，即使没有嵌入式 CRL 的文件在描述 "Is AdES-T validation conclusive?" 后面也有一个有效检查（这是 "Long Term Validation Data" 下唯一的检查点）。因此，我想知道是否需要为 LTV 包含 CRL？
足以说明我很困惑 :)。
顺便说一句，我似乎无法解决来自同一个验证服务的另外 2 个警告："The 'issuer-serial' attribute is absent or does not match!" 和 "The signer's certificate is not supported by SSCD!"。但也许那是另一个问题。
在此先感谢您的帮助。
我看过你的示例文档。它不符合任何 LTV 配置文件，仅符合 T 级别，即它带有时间戳。
详细
PDF 签名仅通过使用包含
的子过滤器 ETSI.CAdES.detached 嵌入单个 CMS 容器来实现CMS容器证书集中签名者证书的证书链
C=BE,CN=比利时根 CA2
C=BE,CN=公民CA,SERIALNUMBER=201103
C=BE,CN=Donny Tytgat（签名）,SURNAME=Tytgat,GIVENNAME=Donny Geert,SERIALNUMBER=81032305309);
一个签名的 Adobe
签名RevocationInfoArchival属性包含对签名者证书的单个良好 OCSP 响应；响应由- CN=比利时 OCSP 响应者，C=BE
具有
id-pkix-ocsp-nocheck扩展名；签名时间戳
- C=BE,SERIALNUMBER=2014,O=比利时联邦政府,CN=时间戳机构
因此，签名符合 Baseline T-Level 为
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-Level：
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-Level，因为
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 服务，要么只是不提供该服务 public。
顺便说一句，这就是诊断树的评论
<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 相关的配置文件有更多要求。