当前位置: 首页 > 知识库问答 >
问题:

iText分离签名意味着

佟和安
2023-03-14

你能详细解释一下吗?最后给我举个例子(一个是附加的,一个是分离的),说明iText分离签名的确切含义?

我发现了这个精彩的留档: iText数字签名pdf关于iText数字签名,但我仍然不确定我是否理解iText分离签名的概念。

阅读文档(参见链接),我发现了以下定义:

在PDF中,我们有时指的是分离的签名。根据维基百科的说法,分离签名是一种“与签名数据分离”的数字签名,而不是“捆绑在一起形成一个文件”。此定义在PDF环境中并不完全正确:签名包含在PDF文件中,但签名的属性是“签名的一部分”,而不是“存储在签名字典中”。

我不清楚“签名的属性”是什么意思(它指的是什么签名属性?)

请注意,本文作者(iText文档)正在处理签名PDF文件的以下片段:

%PDF-1.4
%âãÏÓ
3 0 obj
<</F 132/Type/Annot/Subtype/Widget/Rect[0 0 0 0]/FT/Sig
/DR<<>>/T(signature)/V 1 0 R/P 4 0 R/AP<</N 2 0 R>>>>
endobj
1 0 obj
<</Contents <0481801e6d931d561563fb254e27c846e08325570847ed63d6f9e35 ... b2c8788a5>
/Type/Sig/SubFilter/adbe.pkcs7.detached/Location(Ghent)/M(D:20120928104114+02'00')
/ByteRange [0 160 16546 1745 ]/Filter/Adobe.PPKLite/Reason(Test)/ContactInfo()>>
endobj
...
9 0 obj
<</Length 63>>stream
q
BT
36 806 Td
0 -18 Td
/F1 12 Tf
(Hello World!)Tj
0 0 Td
ET
Q
endstream
endobj
...
11 0 obj
<</Type/Catalog/AcroForm<</Fields[3 0 R]/DR<</Font<</Helv 5 0 R
/ZaDb 6 0 R>>>>/DA(/Helv 0 Tf 0 g )/SigFlags 3>>/Pages 10 0 R>>
endobj
xref
0 12
0000000000 65535 f
...
0000017736 00000 n
trailer
<</Root 11 0 R/ID [<08ed1afb8ac41e841738c8b24d592465><bd91a30f9c94b8facf5673e7d7c998dc>]/Info 7 0 R/Size 12>>
startxref
17879
%%EOF

共有1个答案

司徒河
2023-03-14

尽管您引用的Bruno Lowagie的《PDF文档数字签名》白皮书确实是任何试图使用iText创建集成PDF签名的人的必读资料(即使您不使用iText,这也是一个很好的信息来源),我同意其中对“分离的PDF签名”中使用“分离的”一词的解释并没有真正达到目的:

注意:在PDF中,我们有时指的是分离的签名。根据维基百科的说法,分离签名是一种“与签名数据分离”的数字签名,而不是“捆绑在一起形成一个文件”。此定义在PDF环境中并不完全正确:签名包含在PDF文件中,但签名的属性是“签名的一部分”,而不是“存储在签名字典中”。

首先,将这些签名称为“分离”并不是任何当前规范强制使用的术语。我们之所以这样做,是因为这些签名的签名字典(adbe.pkcs7.detached或ETSI.CAdES.detached)中使用的标识符包含该单词。

因此,问题实际上应该是:为什么这些标识符包含“分离”一词?

要理解这一点,我们需要知道,最初有两种集成的PDF签名,它们将PKCS#7签名容器嵌入到PDF中,分别由adbe识别。pkcs7。超脱的和阿德贝。pkcs7。sha1。

这两种签名的区别在于

  • 为了阿德贝。pkcs7。sha1签名计算PDF签名字节范围的sha1摘要,并将其嵌入签名容器的ContentInfo结构中,该嵌入数据包以PKCS#7方式签名
  • 为了阿德贝。pkcs7。另一方面,分离的签名,签名容器的ContentInfo结构保留为空,外部文档的签名数据范围以PKCS#7方式签名

因此,在adbe的情况下。pkcs7。sha1签名在adbe情况下,实际签名的数据嵌入到容器中。pkcs7。分离的签名实际签名的数据不是。

因此,在PKCS#7签名容器的级别上,签名数据和签名在后一种情况下彼此分离。

(事实上,PKCS#7方式的签名可以——通常也确实如此——包括计算要签名的数据的散列,将该散列添加到一些所谓的已验证属性中,并最终对这些特殊属性进行签名,这不应该让我们分心。)

另一种类型的分离签名(ETSI. CADES. disache)的构造类似于adbe.pkcs7.detached容器。它们之间的区别主要是容器的附加属性的分析。

白皮书关于属性是签名容器的一部分的论述实际上说明了前面提到的所有签名类型与adbe之间的区别。x509。rsa_sha1签名是第三种原始的集成PDF签名类型。这种类型不是基于签名容器,而是基于相当裸露的签名;因此,在这种情况下,任何额外的信息都必须存储在PDF中自己的结构中

 类似资料:
  • 问题内容: 假设我们在A包中有A类,在B包中有B类。如果类A的对象引用了类B,则称这两个类之间具有耦合。 为了解决耦合问题,建议在包A中定义一个接口,该接口由包B中的类实现。然后,类A的对象可以引用包A中的接口。这通常是“依赖倒置”的一个例子。 这是“在接口级别将两个类解耦”的示例。如果是,当两个类耦合时,它如何消除类之间的耦合并保持相同的功能? 问题答案: 让我们创建一个虚拟的例子。 套餐类别:

  • 我这里需要帮助,有人能帮我吗?

  • 我想实现PDF的“并行”签名过程,这样用户就可以不是“一个接一个”地进行数字签名,而是同时进行数字签名。为了实现这一点,我决定为所有用户创建初始文档的单独副本,并在它们上获得签名。最终,所有签名都应该连接到单个PDF中。 让我们假设,PDF在签名过程中没有变化,除了签名字段创建(所有acroForms、signaturecontainer、可视签名等都是在之前创建的,并且对所有这些都是相似的)。

  • 我想实现PDF的“并行”签名过程,这样用户就可以对文档进行数字签名,而不是“一个一个”,而是同时进行。为了实现这一点,我决定为所有用户创建初始文档的单独副本,并在其上获得签名。最终,所有签名都应该连接到单个PDF中。 让我们假设,除了签名字段创建(所有的acroForms、signatureContainers、可视签名等都是在之前创建的,并且都是类似的),在签名过程中PDF没有改变。 在进一步的

  • 我正在尝试用Itext 5.4和BouncyCastle 1.49验证PDF签名(它是通过Adobe Reader X用我的数字证书手动签名的)。 但是验证结果总是出乎意料的,下面是我的Java代码: 控制台显示:完整性检查OK?真

  • 我使用PdfWriter setEncryption对PDF文档进行了加密/解密。一切正常,解密也正常。 当我为数字签名的PDF文档做同样的事情时,我的数字信息与消息一起损坏(SigDict/Contents非法数据) 是否可以在不影响数字签名信息的情况下加密PDF?