使用iText与OCSP签名 [英] Signing with OCSP by using iText

查看：108
本文介绍了使用iText与OCSP签名的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我可以毫无问题地签署pdf文档.我的应用程式逻辑是； 1-创建一个空白字段以供pdf签名 2-将字段的哈希码发送到签名Web服务 3-获取签名对象 4-将此对象嵌入到字段中.

这是我的代码签名对于PDF无效带有iText的文件
感谢@mlk，帮助我解决了这个问题.

但是我意识到撤消存在问题.

从图像中可以看出，我的签名不包含OCSP.并在信任"部分中，验证文档"选项失败(红叉)

Web服务的响应已经包含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时，我会看到此窗口.

瑞士电信

这是我的测试pdf

可以看到，在验证方面存在区别..因此，我单击了签名"字段并进行了验证，所以我得到了此窗口.

这与swisscom原始签名文件相同.但我需要做额外的验证".我需要验证的签名中缺少什么?

由Swisscom签名 https://app.box.com/s/ju7xgkxucw0rwif7k3052rx5n8f9omwq

解决方案

实际上，您的问题有两个不同的方面，一方面，您想知道为什么这两个文档(您创建的一个文档和Swisscom提供的一个文档)行为在Adobe Reader中有所不同，另一方面，您问如何将CRL和OCSP嵌入到pdf中.

签名文件之间的差异

关于Adobe Reader版本

首先，您在两个文档中观察到的不同Adobe Reader行为仅在旧版本的Adobe Reader上发生，您在Adobe Reader DC中的两个文件都立即进行了验证并带有绿色的勾. >

因此，不仅阅读器的行为不再不同，而且现成的签名被认为是有效的！信任锚是从Adobe批准的信任列表中获得的.

此外，您可以看到两个签名均被视为启用LTV".因此，包括了Adobe Reader验证所需的所有信息，尤其是吊销信息(CRL和OCSP响应).

不同的签名过滤器值

两个签名之间的主要区别是PDF签名的过滤器，

  • 5.PDF_1_.pdf具有签名过滤器值 ETSI.RFC3161 和
  • Reference_Guide-All-in-Signing-Service-en.pdf具有签名 Filter 值 Adob​​e.PPKLite .

您签名的文件中的 Filter 值 ETSI.RFC3161 没有意义:该值是保留的 SubFilter 文档时间戳的值！ SwissCom签名的文件中的 Filter 值 Adob​​e.PPKLite 确实是一个过滤器名称，它是Adobe签名处理程序的名称.

根据PDF规范ISO 32000-1和ISO 32000-2:

验证此签名时要使用的首选签名处理程序的名称.如果 Prop_Build 条目不存在，则它也应该是用于创建签名的签名处理程序的名称.如果存在 Prop_Build ，则可以使用它来确定创建签名的处理程序的名称(通常与 Filter 相同，但不需要).符合条件的阅读器可以在验证签名时替换其他处理程序，只要它支持指定的 SubFilter 格式即可.示例签名处理程序为 Adob​​e.PPKLite ， Entrust.PPKEF ， CICI.SignIt 和 VeriSign.PPKVS . /p>

过滤器值的含义随着时间的推移而减弱.早期的Adobe Reader版本(以及其他签名验证器的版本)仅自动处理具有某些 Filter 值的签名，而如今， Filter 值实际上已被忽略.

因此，您观察到的Adobe Reader版本必须是较旧的版本，该版本仍旧只能立即处理具有已知过滤器的签名，而仅根据需要处理具有未知过滤器的签名.

您参考此问题以了解您的源代码，尤其是其中包含的

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 ...

将CRL和OCSP嵌入pdf

由于您的签名被识别为启用了 LTV ，因此在您所处的环境中，这个问题实际上已经成为一个争论的焦点，特别是包括您的签名验证器所要求的所有吊销信息(CRL，OCSP响应) Adobe Reader.因此，我将仅以一般性的术语进行介绍.

基本上有两个地方可以将撤销信息放入PDF中:

  • 签名容器中Adobe定义的特殊属性，或者
  • 由ETSI定义的特殊字典，在以后的增量更新中
    • .

adbe吊销信息属性

有关属性已在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.该应用程序应该能够通过查看相关的对象标识符来确定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文档安全存储(DSS)词典

此字典及其处理方式由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 词典 该文件.该词典中每个条目的关键字是 签名的基本16编码(大写)SHA1摘要 它适用的值是Signature VRI字典 其中包含与验证相关的信息 签名. (请参阅其他要求a，b，c.).

证书数组(可选)分别指向流的间接引用的数组 包含一个DER编码的X.509证书(应为 在IETF RFC 5280 [4]中定义).该数组包含证书 可用于验证 文档.

OCSP 数组(可选)分别指向流的间接引用的数组 包含DER编码的在线证书状态 协议(OCSP)响应(应在IETF中定义) RFC 6960 [5]).该阵列包含可用于 文件中所有签名的验证.

CRL 数组(可选)一个间接引用流的数组，每个 包含DER编码的证书吊销列表(CRL) (应按照IETF RFC 5280 [4]的定义).这个数组 包含可用于验证任何内容的CRL 文档中的签名.

由于在第一个ISO PDF规范ISO 32000-1中尚不知道这种嵌入方式，因此许多验证器可能不知道如何处理这些信息.优点是此字典不需要签名，因此可以在签名后检索信息.在某些用例中，这可能是必需的.

I can sign a pdf document without problem. My app logic is; 1- create an empty field for signature in pdf 2- send the hash code of the field to the signature webservice 3- get signature object 4- embedded this object into the field.

Here is my code Signature is Invalid for PDF File with iText
Thank to @mlk, helped me regarding it.

But I i realize that I have problem with Revocation.

As can bee seen in the image, my signature does not contain OCSP. and in the trust section, 'Certify documents' option is failed (red cross)

The response of the webservice already contains crl and ocsp

<sc:RevocationInformation>
 <sc:CRLs>
  <sc:CRL> .... CRL .... </sc:CRL>
 </sc:CRLs>
 <sc:OCSPs>
  <sc:OCSP> ..... ocsp content..... </sc:OCSP>
 </sc:OCSPs>
</sc:RevocationInformation>

But I only use signature object.

My question is that how I can embed CRL and OCSP into the pdf.

As I see some examples, SignDetached method has been used instead of SignDeferred method. If I have to use also SignDetached method then should I create a field in the pdf file. Because I will need this field's hash code. How the process works.

Edit: When I open my test pdf file and a pdf which has been signed by swisscom, I see this windows.

For swisscom

And this is my test pdf

As can bee seen, there is a difference regarding validation.. So I click the signatue field and validate so I got this window.

This is the same to swisscom original signed file. but I need to do extra 'validate'. What is missing in my signature that I need to validate?

Edit 2:

Signed by Swisscom http://documents.swisscom.com/product/1000255-Digital_Signing_Service/Documents/Reference_Guide/Reference_Guide-All-in-Signing-Service-en.pdf

and my signed test file

https://app.box.com/s/ju7xgkxucw0rwif7k3052rx5n8f9omwq

解决方案

There actually are two separate aspects to your question, on one hand you want to know why the two documents (the one you created and the one the Swisscom provided) behave differently in your Adobe Reader, and on the other hand you ask how to embed CRL and OCSP into the pdf.

Differences between the signed documents

A matter of Adobe Reader versions

First of all, the different Adobe Reader behavior you observed for the two documents only occurs on old Adobe Reader versions, both your files in Adobe Reader DC are validated immediately with green ticks.

So, not only does the Reader not behave differently anymore, the signatures now out of the box are considered valid! The trust anchor is obtained from the Adobe Approved Trust List.

Furthermore, you can see that both signatures are considered "LTV-enabled". Thus, all information required for validation by Adobe Reader, in particular revocation information (CRLs and OCSP responses), are included.

Different signature Filter values

The major difference between the two signatures is the Filter of the PDF signature,

  • 5.PDF_1_.pdf has a signature Filter value ETSI.RFC3161 and
  • Reference_Guide-All-in-Signing-Service-en.pdf has a signature Filter value Adobe.PPKLite.

The Filter value ETSI.RFC3161 in the file you signed does not make sense: This value is a reserved SubFilter value for document time stamps! The Filter value Adobe.PPKLite in the file signed by SwissCom is indeed a filter name, it's the name of the Adobe signature handler.

According to the PDF specifications ISO 32000-1 and ISO 32000-2:

The name of the preferred signature handler to use when validating this signature. If the Prop_Build entry is not present, it shall be also the name of the signature handler that was used to create the signature. If Prop_Build is present, it may be used to determine the name of the handler that created the signature (which is typically the same as Filter but is not needed to be). A conforming reader may substitute a different handler when verifying the signature, as long as it supports the specified SubFilter format. Example signature handlers are Adobe.PPKLite, Entrust.PPKEF, CICI.SignIt, and VeriSign.PPKVS.

The meaning of the Filter value has diminished over time. Earlier Adobe Reader versions (and also versions of other signature validators) only handled signatures with certain Filter values automatically while nowadays the Filter value is essentially ignored.

Thus, the Adobe Reader version with which you observed that differing behavior must be an older version which still only handles signatures with known filters immediately and such with unknown filters only on demand.

You reference this question for your source code which in particular contains

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

Apparently you created your signature using the code from an attempt for which you tried also PdfName.ETSI_RFC3161...

Embedding CRL and OCSP into the pdf

This question in your context actually has become a moot point as your signature is recognized as LTV enabled, i.e. in particular as including all revocation information (CRLs, OCSP responses) required by the signature validator of Adobe Reader. Thus, I'll cover it only in general terms.

There essentially are two places to put revocation information in PDFs:

  • a special, Adobe defined attribute in the signature container or
  • a special, ETSI defined dictionary in a later incremental update.

The adbe Revocation Information attribute

The attribute in question is already specified in the PDF specification ISO 32000-1:

The PKCS#7 object should contain the following:

[...]

  • Revocation information as an signed attribute (PDF 1.6): This attribute may include all the revocation information that is necessary to carry out revocation checks for the signer's certificate and its issuer certificates. Since revocation information is a signed attribute, it must be obtained before the computation of the digital signature.

[...]

The adbe Revocation Information attribute:

adbe-revocationInfoArchival OBJECT IDENTIFIER ::=
                              { adbe(1.2.840.113583) acrobat(1) security(1) 8 }

The value of the revocation information attribute can include any of the following data types:

  • Certificate Revocation Lists (CRLs), described in RFC 3280 (see the Bibliography): CRLs are generally large and therefore should not be embedded in the PKCS#7 object.

  • Online Certificate Status Protocol (OCSP) Responses, described in RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol—OCSP (see the Bibliography): These are generally small and constant in size and should be the data type included in the PKCS#7 object.

  • Custom revocation information: The format is not prescribed by this specification, other than that it be encoded as an OCTET STRING. The application should be able to determine the type of data contained within the OCTET STRING by looking at the associated OBJECT IDENTIFIER.

adbe's Revocation Information attribute value has ASN.1 type 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
   }

This way of embedding has been known even before the first ISO PDF specification ISO 32000-1 and, therefore, should be usable for most validators. The drawback is that this attribute is signed, so the information have to be retrieved early. This might not always be possible.

By the way, this also is how these information are embedded in your document, SwissCom embeds this attribute into the signature container for you.

The ETSI Document Security Store (DSS) dictionary

This dictionary and its handling is specified by ETSI, e.g. in ETSI EN 319 142-1, and has been copied into the PDF specification update ISO 32000-2:

The Document Security Store (DSS) shall be a dictionary that shall have the value DSS as key in the document catalog dictionary. This dictionary is used to provide a single place where all of the validation-related information for some or all signatures in the document should be placed.

The DSS dictionary, if present, shall contain validation-related information only for document and time-stamps signatures represented in PKCS#7 and CMS (and its derivatives) format or for XAdES signatures of forms signing dynamic XFA [i.7].

NOTE: See ETSI EN 319 142-2 [i.11] for specification of XAdES signatures of forms signing dynamic XFA.

Entries in a DSS Dictionary

Type Name (Optional) It shall be DSS for a document security store dictionary.

VRI Dictionary (Optional) This dictionary contains Signature VRI dictionaries in the document. The key of each entry in this dictionary is the base-16-encoded (uppercase) SHA1 digest of the signature to which it applies and the value is the Signature VRI dictionary which contains the validation-related information for that signature. (See additional requirements a, b, c.).

Certs Array (Optional) An array of indirect references to streams, each containing one DER-encoded X.509 certificate (that shall be as defined in IETF RFC 5280 [4]). This array contains certificates that can be used in the validation of any signatures in the document.

OCSPs Array (Optional) An array of indirect references to streams, each containing a DER-encoded Online Certificate Status Protocol (OCSP) response (that shall be as defined in IETF RFC 6960 [5]). This array contains OCSPs that can be used in the validation of any signatures in the document.

CRLs Array (Optional) An array of indirect references to streams, each containing a DER-encoded Certificate Revocation List (CRL) (that shall be as defined in IETF RFC 5280 [4]). This array contains CRLs that can be used in the validation of any signatures in the document.

As this way of embedding has not been known in the first ISO PDF specification ISO 32000-1, a number of validators might not know how to handle these information. The advantage is that this dictionary need not be signed, so the information can be retrieved after signing. This might be necessary in some use cases.

这篇关于使用iText与OCSP签名的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
C#/.NET最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆