我正在尝试使用 rsa_sha1(Adobe.PPKLite > adbe.x509.rsa_sha1) 签署 PDF,我有两个问题/疑问:
- 不知道 ByteRange 指定的实际 PDF 内容是否应该签名,或者该内容的摘要值?
- 如果将证书放在签名字段之前或之后,是否有区别?
我正在尝试使用 rsa_sha1(Adobe.PPKLite > adbe.x509.rsa_sha1) 签署 PDF,我有两个问题/疑问:
我正在尝试使用 rsa_sha1(Adobe.PPKLite > adbe.x509.rsa_sha1) 签署 PDF
您确定要使用此子过滤器吗?所有有关集成 PDF 签名的进一步开发都使用集成的 CMS 容器,而不是裸露的 PKCS#1 签名...
不知道 ByteRange 指定的实际 PDF 内容是否应该签名,或者该内容的摘要值?
与adobe.pkcs7.sha1样式签名相比,就像adobe.pkcs7.detached样式签名一样,整个字节范围都以adobe.x509.rsa_sha1样式签名进行签名,而不仅仅是该内容的摘要值。在这方面adobe.x509.rsa_sha1 比 adobe.pkcs7.sha1更可取,因为(尽管名称中出现了sha1)它不会强制您使用 SHA1,但您可以使用更好的摘要算法。
(话虽这么说,签名过程当然包括创建签名数据的摘要值,但这完全是另一回事......)
如果将证书放在签名字段之前或之后,是否有区别?
证书和签名都是 PDF 字典对象中的元素,根据定义,此类字典中元素的顺序无关紧要。显然,一旦创建签名,顺序必须保持固定(实际上不仅是顺序,还有确切的位置和内容)。
字典中的条目代表一个关联表,因此即使在写入文件时可能对它们施加任意顺序,它们也应该是无序的。该排序应被忽略。
( ISO 32000-1中的第 7.3.7 节 )
PS:规范说签名
应在文件中的字节范围内计算,应由签名字典中的 ByteRange 条目指示。该范围应该是整个文件,包括签名字典但不包括签名值本身(内容条目)。可以使用其他范围,但由于它们不会检查文档的所有更改,因此不建议使用它们。
( ISO 32000-1中的第 12.8.1 节 )
这似乎也允许其他字节范围而不是推荐的字节范围(除了实际签名字节之外的所有字节)。不过其实你也会发现
对于字节范围签名,内容应为带有“<”的十六进制字符串 和“>” 分隔符。它应该精确地适合 ByteRange 指定的范围之间的空间。
( ISO 32000-1中的第 12.8.3.3.2 节 )
如果需要互操作性,这会should
在实际引用之前进行。shall
例如,Adobe Reader 需要这种范围定义。
较新的标准,例如 ETSI PAdES 技术规范文件,甚至更明确地要求它。