在签名 PDF 中嵌入 CRL 响应会破坏 PDF/A-2B 一致性
Embedding CRL response in signed PDF breaks PDF/A-2B conformance
对于 iText 5.5.4，如果我选择在签名过程中嵌入 CRL，它会因为 String too long 错误而破坏 PDF/A-2B 一致性：
Adobe Preflight http://img4.hostingpics.net/pics/234201so5.jpg
正如您在 Adobe Acrobat Pro 11.0.09 的预检中看到的那样，CRL 的长度为 67107 个字符，而此特定的 PDF 标准要求字符串的最大长度不得超过 32767 字节。
这是 Itext 中的错误还是在这种情况下有办法保持 PDF/A-2B 一致性？
这是 Itext 中的错误吗？
As you can see in the preflight from Adobe Acrobat Pro 11.0.09, the CRL is 67107 characters long whereas this specific PDF standard require that the maximum length for strings must not exceed 32767 bytes
考虑到问题字符串被引用为 1 0 obj/Contents 似乎表明它实际上是为 CMS 签名容器保留的字符串，而不是普通的 CRL。
查看 PDF/A 规范（我手头只有第 3 部分，但第 2 部分和第 3 部分在这里应该重合）有两个部分似乎相互矛盾：
A conforming file shall not contain any string longer than 32767 bytes.
(section 6.1.13 Implementation limits)
和
timestamping and revocation information should be included [in the PDF Signature (a DER-encoded PKCS#7 binary data object)] in order to improve the long-term non-repudiation properties of the signature.
(Annex B Requirements for digital signatures in PDF/A)
在您的情况下，后一个建议违反了前一个要求，因为 PKCS#7 / CMS 对象作为字符串嵌入到 PDF 中。
但由于我们对建议有要求，因此只要不违反要求，就需要遵循建议。规范甚至明确表示：
When generating signature appearances and any other PDF objects as part of the signing process, a
conforming reader shall ensure that it does not invalidate compliance with this part of ISO 19005
(section 6.4.3 Digital signatures)
因此，iText 签名确实应该在签名过程中失败...如果您使用了 PDF/A 感知 API，那就是。很遗憾，您没有提供源代码，因此不清楚您是否使用了 PdfAStamper 或仅使用了 PdfStamper.
或者在这种情况下是否有办法保持 PDF/A-2B 一致性？
您没有提供源代码，所以只能以更笼统的方式回答。
首先检查签名容器预留的space是否真的需要，或者填充字节是否多。在后一种情况下微调预订代码。
如果这还不够，将 CRL 嵌入签名容器会自动导致违反 PDF/A 一致性，因此是不允许的。
然后，一种选择是尝试在此处使用 OCSP 响应而不是 CRL。 OCSP 响应通常只包含一个或最多很少的证书的信息，而 CRL 可能会变得非常大。
如果 CA 没有 OCSP 服务器，我看不到真正的 PDF/A-2'ish 解决方案。您可能想尝试将与验证相关的信息嵌入到 PAdES 第 4 部分 (ETSI TS 102 778-4) DSS（文档安全存储）结构中，而不是嵌入到签名容器中。普通 PDF/A 查看器很可能不会识别，更不用说使用那里的 CRL，但更多功能的查看器，例如当前的 Adobe Reader 版本，应该。
对于 iText 5.5.4，如果我选择在签名过程中嵌入 CRL，它会因为 String too long 错误而破坏 PDF/A-2B 一致性：
Adobe Preflight http://img4.hostingpics.net/pics/234201so5.jpg
正如您在 Adobe Acrobat Pro 11.0.09 的预检中看到的那样，CRL 的长度为 67107 个字符，而此特定的 PDF 标准要求字符串的最大长度不得超过 32767 字节。
这是 Itext 中的错误还是在这种情况下有办法保持 PDF/A-2B 一致性？
这是 Itext 中的错误吗？
As you can see in the preflight from Adobe Acrobat Pro 11.0.09, the CRL is 67107 characters long whereas this specific PDF standard require that the maximum length for strings must not exceed 32767 bytes
考虑到问题字符串被引用为 1 0 obj/Contents 似乎表明它实际上是为 CMS 签名容器保留的字符串，而不是普通的 CRL。
查看 PDF/A 规范（我手头只有第 3 部分，但第 2 部分和第 3 部分在这里应该重合）有两个部分似乎相互矛盾：
A conforming file shall not contain any string longer than 32767 bytes.
(section 6.1.13 Implementation limits)
和
timestamping and revocation information should be included [in the PDF Signature (a DER-encoded PKCS#7 binary data object)] in order to improve the long-term non-repudiation properties of the signature.
(Annex B Requirements for digital signatures in PDF/A)
在您的情况下，后一个建议违反了前一个要求，因为 PKCS#7 / CMS 对象作为字符串嵌入到 PDF 中。
但由于我们对建议有要求，因此只要不违反要求，就需要遵循建议。规范甚至明确表示：
When generating signature appearances and any other PDF objects as part of the signing process, a conforming reader shall ensure that it does not invalidate compliance with this part of ISO 19005
(section 6.4.3 Digital signatures)
因此，iText 签名确实应该在签名过程中失败...如果您使用了 PDF/A 感知 API，那就是。很遗憾，您没有提供源代码，因此不清楚您是否使用了 PdfAStamper 或仅使用了 PdfStamper.
或者在这种情况下是否有办法保持 PDF/A-2B 一致性？
您没有提供源代码，所以只能以更笼统的方式回答。
首先检查签名容器预留的space是否真的需要，或者填充字节是否多。在后一种情况下微调预订代码。
如果这还不够，将 CRL 嵌入签名容器会自动导致违反 PDF/A 一致性，因此是不允许的。
然后，一种选择是尝试在此处使用 OCSP 响应而不是 CRL。 OCSP 响应通常只包含一个或最多很少的证书的信息，而 CRL 可能会变得非常大。
如果 CA 没有 OCSP 服务器，我看不到真正的 PDF/A-2'ish 解决方案。您可能想尝试将与验证相关的信息嵌入到 PAdES 第 4 部分 (ETSI TS 102 778-4) DSS（文档安全存储）结构中，而不是嵌入到签名容器中。普通 PDF/A 查看器很可能不会识别，更不用说使用那里的 CRL，但更多功能的查看器，例如当前的 Adobe Reader 版本，应该。