我可以毫无问题地签署一份pdf文件。我的app逻辑是; 1-在pdf中创建一个用于签名的空字段 2-将字段的哈希码发送到签名Web服务 3-获取签名对象 4-将此对象嵌入到字段中。
这是我的代码Signature is Invalid for PDF File with iText
感谢@mlk,帮我解决了。
但我意识到我有撤销的问题。
如图所示,我的签名不包含OCSP。在信任部分,“证明文件”选项失败(红叉)
webservice的响应已包含crl和ocsp
<sc:RevocationInformation>
<sc:CRLs>
<sc:CRL> .... CRL .... </sc:CRL>
</sc:CRLs>
<sc:OCSPs>
<sc:OCSP> ..... ocsp content..... </sc:OCSP>
</sc:OCSPs>
</sc:RevocationInformation>
但我只使用签名对象。
我的问题是如何将CRL和OCSP嵌入到pdf中。
正如我看到的一些例子,已使用SignDetached方法代替SignDeferred方法。如果我还必须使用SignDetached方法,那么我应该在pdf文件中创建一个字段。因为我需要这个字段的哈希码。这个过程是如何运作的。
编辑:当我打开我的测试pdf文件和由swisscom签名的pdf时,我会看到这个窗口。
对于swisscom
可以看出,验证方面存在差异。所以我点击signatue字段并验证,这样我就有了这个窗口。
这与swisscom原始签名文件相同。但我需要做额外的'验证'。我需要验证的签名中缺少什么?
编辑2:
和我签名的测试文件
答案 0 :(得分:1)
您的问题实际上有两个不同的方面,一方面您想知道为什么两个文档(您创建的文档和Swisscom提供的文档)在Adobe Reader中表现不同,另一方面您要问如何将CRL和OCSP嵌入pdf 。
首先,您在两个文档中观察到的不同Adobe Reader行为仅发生在旧的Adobe Reader版本上,Adobe Reader DC中的文件都立即验证,带有绿色标记。
因此,不仅读者不再表现不同,现在开箱即用的签名被认为是有效的!信任锚是从Adobe批准的信任列表中获得的。
此外,您可以看到两个签名都被视为&#34; LTV启用&#34;。因此,包括Adobe Reader验证所需的所有信息,特别是撤销信息(CRL和OCSP响应)。
两个签名之间的主要区别是PDF签名的过滤器,
您签名的文件中的过滤器值 ETSI.RFC3161 没有意义:此值是保留的 SubFilter < / strong>文档时间戳的值!由SwissCom签名的文件中的过滤器值 Adobe.PPKLite 确实是过滤器名称,它是Adobe签名处理程序的名称。
根据PDF规范ISO 32000-1和ISO 32000-2:
验证此签名时要使用的首选签名处理程序的名称。如果 Prop_Build 条目不存在,则它还应该是用于创建签名的签名处理程序的名称。如果存在 Prop_Build ,则可以使用它来确定创建签名的处理程序的名称(通常与过滤器相同,但不需要)。符合标准的阅读器可以在验证签名时替换不同的处理程序,只要它支持指定的 SubFilter 格式即可。示例签名处理程序是 Adobe.PPKLite , Entrust.PPKEF , CICI.SignIt 和 VeriSign.PPKVS 。< / p>
过滤器值的含义随着时间的推移而减少。早期的Adobe Reader版本(以及其他签名验证器的版本)仅自动处理具有某些过滤器值的签名,而现在过滤器值基本上被忽略。
因此,您观察到不同行为的Adobe Reader版本必须是旧版本,它仍然只能立即处理具有已知过滤器的签名,并且仅在需要时使用未知过滤器。
您引用this question作为源代码,特别是
IExternalSignatureContainer external = new ExternalBlankSignatureContainer(PdfName.ADOBE_PPKLITE, PdfName.ADBE_PKCS7_DETACHED);
PdfSignature external2 = new PdfSignature(PdfName.ADOBE_PPKLITE, PdfName.ADBE_PKCS7_DETACHED);//ADBE_PKCS7_SHA1);
//as pdf name I tried also PdfName.ETSI_RFC3161
显然,您使用尝试过的代码PdfName.ETSI_RFC3161
...
您的上下文中的这个问题实际上已经变得没有实际意义,因为您的签名被识别为 LTV启用,即特别是包括签名验证器所需的所有吊销信息(CRL,OCSP响应)。 Adobe Reader。因此,我只是笼统地介绍它。
基本上有两个地方可以将撤销信息放在PDF中:
有问题的属性已在PDF规范ISO 32000-1中指定:
PKCS#7对象应包含以下内容:
[...]
- 作为签名属性的撤销信息(PDF 1.6):该属性可以包括对签名者证书及其颁发者证书进行撤销检查所必需的所有撤销信息。由于吊销信息是带符号的属性,因此必须在计算数字签名之前获取它。
[...]
adbe撤销信息属性:
adbe-revocationInfoArchival OBJECT IDENTIFIER ::= { adbe(1.2.840.113583) acrobat(1) security(1) 8 }
吊销信息属性的值可以包括以下任何数据类型:
证书撤销列表(CRL),在RFC 3280中描述(参见参考书目):CRL通常很大,因此不应嵌入PKCS#7对象中。
在线证书状态协议(OCSP)响应,在RFC 2560,X.509 Internet公钥基础结构在线证书状态协议-OCSP(参见参考书目)中描述:这些通常很小并且大小不变,应该是PKCS#7对象中包含的数据类型。
自定义吊销信息:除了将其编码为OCTET STRING之外,本规范未规定格式。应用程序应该能够通过查看相关的OBJECT IDENTIFIER来确定OCTET STRING中包含的数据类型。
adbe的撤销信息属性值具有ASN.1类型RevocationInfoArchival:
RevocationInfoArchival ::= SEQUENCE { crl [0] EXPLICIT SEQUENCE of CRLs, OPTIONAL ocsp [1] EXPLICIT SEQUENCE of OCSP Responses, OPTIONAL otherRevInfo [2] EXPLICIT SEQUENCE of OtherRevInfo, OPTIONAL } OtherRevInfo ::= SEQUENCE { Type OBJECT IDENTIFIER Value OCTET STRING }
这种嵌入方式甚至在第一个ISO PDF规范ISO 32000-1之前就已为人所知,因此应该可用于大多数验证器。缺点是此属性已签名,因此必须尽早检索信息。这可能并非总是可行。
顺便说一下,这也是这些信息嵌入到您的文档中的方式,SwissCom将此属性嵌入到您的签名容器中。
该词典及其处理由ETSI指定,例如在ETSI EN 319 142-1中,已被复制到PDF规范更新ISO 32000-2:
文档安全存储( DSS )应为字典,其值 DSS 为文档目录中的键 字典。此字典用于提供单个位置,其中包含所有与验证相关的信息 应放置文档中的所有签名。
DSS 字典(如果存在)应仅包含文档和时间戳的验证相关信息 以PKCS#7和CMS(及其衍生物)格式表示的签名或表格签名的XAdES签名 动态XFA [i.7]。
注意:有关签署动态XFA的表格的XAdES签名规范,请参阅ETSI EN 319 142-2 [i.11]。
DSS词典中的条目
类型名称(可选)文档安全存储区应为 DSS 字典。
VRI 字典(可选)此词典包含签名 VRI 词典 该文件。这本词典中每个条目的关键是 签名的base-16编码(大写)SHA1摘要 它适用,值是Signature VRI字典 其中包含与验证相关的信息 签名。 (参见附加要求a,b,c。)。
Certs 数组(可选)对流的间接引用数组,每个引用 包含一个DER编码的X.509证书(应为 在IETF RFC 5280 [4]中定义。该数组包含证书 可以用于验证中的任何签名 文档。
OCSP 数组(可选)对流的间接引用数组,每个引用 包含DER编码的在线证书状态 协议(OCSP)响应(应在IETF中定义) RFC 6960 [5])。该阵列包含可用于的OCSP 验证文件中的任何签名。
CRL 数组(可选)对流的间接引用数组,每个引用 包含DER编码的证书吊销列表(CRL) (应按照IETF RFC 5280 [4]中的定义)。这个数组 包含可用于任何验证的CRL 文件中的签名。
由于这种嵌入方式在第一个ISO PDF规范ISO 32000-1中尚未公开,因此许多验证器可能不知道如何处理这些信息。优点是不需要对该字典进行签名,因此可以在签名后检索该信息。在某些用例中可能需要这样做。