C# 使用iText与OCSP进行签名

C# 使用iText与OCSP进行签名,c#,pdf,itext,digital-signature,ocsp,C#,Pdf,Itext,Digital Signature,Ocsp,我可以毫无问题地签署pdf文档。我的应用程序逻辑是; 1-在pdf中为签名创建空字段 2-将字段的哈希代码发送到签名Web服务 3-获取签名对象 4-将此对象嵌入到字段中 这是我的代码 感谢@mlk,在这方面帮助了我 但我意识到我有撤销的问题 如图所示,我的签名不包含OCSP。在信托部分,“证明文件”选项失败(红十字会) Web服务的响应已经包含crl和ocsp <sc:RevocationInformation> <sc:CRLs> <sc:CRL>

我可以毫无问题地签署pdf文档。我的应用程序逻辑是; 1-在pdf中为签名创建空字段 2-将字段的哈希代码发送到签名Web服务 3-获取签名对象 4-将此对象嵌入到字段中

这是我的代码
感谢@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内容。。。。。
但我只使用签名对象

我的问题是如何将CRL和OCSP嵌入到pdf中

正如我看到的一些示例,使用了SignDetached方法而不是SignDeferred方法。如果我还必须使用SignDistached方法,那么我应该在pdf文件中创建一个字段。因为我需要这个字段的散列码。这个过程是如何运作的

编辑:当我打开我的测试pdf文件和SWISCOM签署的pdf文件时,我看到这个窗口

瑞士电信

这是我的测试pdf

正如我们所见,在验证方面存在差异。。所以我点击signatue字段并进行验证,所以我得到了这个窗口

这与SWISCOM原始签名文件相同。但我需要做额外的“验证”。我需要验证的签名中缺少什么

编辑2:

瑞士电信签署

还有我的签名测试文件


您的问题实际上有两个不同的方面,一方面您想知道为什么这两个文档(您创建的文档和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.rfc3116
  • Reference_Guide-All-in-Signing-Service-en.pdf有一个签名过滤器Adobe.PPKLite
您签署的文件中的过滤器ETSI.rfc3116没有意义:此值是文档时间戳的保留子过滤器值!SwissCom签署的文件中的过滤器Adobe.PPKLite实际上是一个过滤器名称,它是Adobe签名处理程序的名称

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

验证此签名时要使用的首选签名处理程序的名称。如果Prop_Build条目不存在,则它还应是用于创建签名的签名处理程序的名称。如果存在Prop_Build,则可以使用它来确定创建签名的处理程序的名称(通常与过滤器相同,但不需要)。合格读取器在验证签名时可以替换不同的处理程序,只要它支持指定的子过滤器格式。签名处理程序的示例有Adobe.PPKLite、authote.PPKEF、cicii.SignIt和VeriSign.PPKVS

过滤器值的含义随着时间的推移而减弱。早期的Adobe Reader版本(以及其他签名验证器版本)仅自动处理具有某些过滤器值的签名,而现在基本上忽略了过滤器

因此,您观察到不同行为的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_rfc3116

将CRL和OCSP嵌入pdf 在您的上下文中,这个问题实际上已经成为一个没有实际意义的问题,因为您的签名被认为是启用LTV的,即特别是包括Adobe Reader的签名验证程序所需的所有撤销信息(CRL、OCSP响应)。因此,我将仅概括地介绍它

基本上有两个地方可以在PDF中放置吊销信息:

  • 签名容器中的特殊Adobe定义属性或
  • 在以后的增量更新中,一个特殊的ETSI定义的字典
adbe吊销信息属性 该属性已在PDF规范ISO 32000-1中指定:

PKCS#7对象应包含以下内容:

[……]

  • 作为签名属性的吊销信息(PDF 1.6):此属性可能包括对签名者证书及其颁发者证书执行吊销检查所需的所有吊销信息。由于吊销信息是一个签名属性,因此必须在
    adbe-revocationInfoArchival OBJECT IDENTIFIER ::=
                                  { adbe(1.2.840.113583) acrobat(1) security(1) 8 }
    
       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
       }