使用iText 5.5.4，如果我选择在签名过程中嵌入CRL，由于字符串太长错误，它会破坏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的一致性？
答案 0 :(得分：2)
正如您在Adobe Acrobat Pro 11.0.09的预检中所看到的，CRL长度为67107个字符，而此特定PDF标准要求字符串的最大长度不得超过32767字节
考虑到问题字符串被引用为1 0 obj/Contents似乎表明它实际上是为CMS签名容器保留的字符串，而不是普通的CRL。
查看PDF / A规范（我手头只有第3部分，但第2部分和第3部分应该在这里重合），有两个部分似乎相互矛盾：
符合文件不得包含任何超过32767字节的字符串。
（第6.1.13节实施限制）
和
时间戳和撤销信息应包含在[PDF签名（DER编码的PKCS＃7二进制数据对象）]中，以改善签名的长期不可否认属性。
（附件B PDF / A中数字签名的要求）
在你的情况下，后一个建议打破了之前的要求，因为PKCS＃7 / CMS对象嵌入了PDF中的字符串。
但是，由于我们对建议有要求，只要不违反要求，就只需遵循建议。规范甚至明确地这样说：
在签名过程中生成签名外观和任何其他PDF对象时，a 符合本标准的读者应确保其不会使符合ISO 19005
的这一部分失效（第6.4.3节数字签名）
因此，在签名过程中， iText签名确实会失败...如果您使用了PDF / A感知API ，那就是。很遗憾，您尚未提供源代码，因此不清楚您是否使用过PdfAStamper或仅PdfStamper。
您没有提供源代码，因此只能以更一般的方式回答。
首先检查是否确实需要为签名容器保留的空间或是否有很多填充字节。在后一种情况下，微调预订代码。
如果这还不够，将CRL嵌入签名容器会自动导致违反PDF / A一致性，因此不允许。
然后，一种选择是尝试在此处使用OCSP响应而不是CRL。 OCSP响应通常只包含一个或最多极少数证书的信息，而CRL可能变得非常大。
如果CA没有OCSP服务器，我就看不到真正的PDF / A-2解决方案。您可能希望尝试在PAdES第4部分（ETSI TS 102 778-4）DSS（文档安全性存储）结构中而不是在签名容器中嵌入与验证相关的信息。普通的PDF / A观众很可能不会认识到CRL，更不用说使用那里的CRL，而是更多样化的观众，例如当前的Adobe Reader版本，应该。
