签名PDF与rsa_sha1

Question

我试图签署rsa_sha1（Adobe.PPKLite> adbe.x509.rsa_sha1）PDF，我有两个问题/问题：

1. 不知道实际的PDF内容由ByteRange指定应该签名，还是摘要值的内容？
2. 如果证书放置在签名字段之前或之后有区别吗？

Answer 1

我试图签署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技术规范文件，甚至更明确地要求它。