使用rsa_sha1签署PDF

我正在尝试使用rsa_sha1（Adobe.PPKLite>adbe.x509.rsa_sha1）签署PDF，我有两个问题：

不知道ByteRange指定的实际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字典对象中的元素，根据定义，这样的字典中元素的顺序并不重要。然而，很明显，一旦签名被创建，顺序必须保持不变（实际上不仅仅是顺序，而是确切的位置和内容）

词典中的条目代表一个关联表，因此应无序，即使在写入文件时可能对其施加任意顺序。该命令应被忽略

（中的第7.3.7节）

PS:规范中说签名

应在文件中的字节范围内进行计算，该范围由签名字典中的ByteRange条目表示。此范围应为整个文件，包括签名字典，但不包括签名值本身（内容条目）。可以使用其他范围，但由于它们不会检查文档的所有更改，因此不建议使用它们

（中的第12.8.1节）

这似乎还允许使用推荐范围以外的其他字节范围（除了实际签名字节之外的所有字节）。事实上，你也会发现

对于字节范围签名，内容应为带“”分隔符的十六进制字符串它应精确适合ByteRange规定的范围之间的空间

（中的第12.8.3.3.2节）

如果需要互操作性，则在实际的

应

之前，引用中的

应

。例如，Adobe Reader需要这种范围定义

较新的标准，例如ETSI PAdES技术规范文件，更明确地要求它