关于PDF数字签名的查询
Queries regarding digital signature in PDF
我正在浏览官方 PDF spec. I came across a digitally signed PDF here。当我分析它的目录字典时，我看到了这个：
我对此有一些疑问：
根据规范的第 736 页，FieldMDP 没有 P 参数，属于 DocMDP（第 733 页）。当然，PDF 可能已被某些向字典添加无关键的第三方修改。但我只是想确认一下，如果在FeldMDP中找到一个P键，是忽略它，还是有一定的意义？
根据规范的第 725 页，有两种可重现的方法来计算内容的摘要 - 通过字节范围数组，或通过递归对象摘要计算，如 TransformParams 签名参考词典中的条目。问题是，在本文档中，两者都存在。 FieldMDP 条目的目的是什么？
如果我没理解错的话，Contents键的值是内容的加密摘要，不包括内容价值流（本身）。所以我首先要解密它。然后我必须计算不包括内容流的实际内容的摘要，并比较两个摘要以查看它们是否匹配。那正确吗？如果是这样，我该怎么做？我怀疑 Filter 和 SubFilter 键表示方法，但我无法理解具体的方法。
FieldMDP 字典中 DigestLocation 和 DigestValue 键值对的用途是什么？摘要值已经在 V 字典的 Contents 键中提供了，对吧？加上这是一个数组（Reference），这里只有一个条目，如果有多个条目怎么办？
根据规范第 1131 页，摘要长度为 16 字节或 20 字节。一个巨大的 PDF 怎么能被压缩成这么小的摘要？ 16 是不是太小了，不能保证两个不同的 PDF 不会有相同的摘要？
我了解到上述 PDF 中的数字签名是通过签名字段进行的。数字签名是否可能不是是签名字段，即Fields数组条目中没有关联的Rect条目？
Filter键的具体作用是什么？我可以看到 SubFilter 密钥决定了解密内容时使用的方案，Filter 密钥表示什么？规范说它是一个签名处理程序。那到底是什么？另外说 SubFilter 值没有什么意思？
##PDF 规范
首先，文档上的一些文字指定了 PDF 格式。
最初 PDF 是一种专有的 Adobe 格式。他们很早就发布了 PDF 参考文献，使其他公司能够创建和处理 PDF 文件，但他们明确表示他们不认为参考文献 具有规范性 ；据 Adobe 的 PDF 传播者 Leonard Rosenthol 所说：
the PDF References aren't "normative" in nature - they don't (usually) make final, definitive statements - just sort of general ones.
（in an answer 在 2008 年 12 月 15 日制作的 iText 邮件列表中）
不过，在 2008 年，Adobe 最终将 PDF 格式交到了 ISO 手中，使其真正标准化为 ISO 32000-1。
当 PDF 成为 ISO 标准时，向其添加了一项新功能，人们可以为 PDF 格式定义“扩展”，并获得一种标准化的方式来在 PDF 中记录其中使用了此类扩展，cf . ISO 32000-1 第 7.12 节。
最没有table 的扩展是those published by Adobe 本身和 ETSI 的 PAdES 扩展，参见。 ETSI EN 319 142-1 V1.1.1.
去年，2017年，PDF 2.0规范ISO 32000-2已经发布。
##你的问题
###1。 P FieldMDP 转换字典中的值
As per page 736 of the spec, FieldMDP has no P parameter, that belongs to DocMDP (page 733). Of course, the PDF might have been modified by some third party who added an extraneous key to the dictionary. But I just want to confirm, if a P key is found in FeldMDP, is it to be ignored, or it has some meaning?
这是一个艰难的过程...
首先请查看第 696 和 697 页 8.6.3 字段类型下的“签名字段”部分，特别是 [=309] 中的 Lock 条目=] 8.81 的值是一个字典，其值在 table 8.82.
如果 Lock 条目存在于 yet-unsigned 签名字段中，签名期间的 Lock 字典基本上被复制（使用更新的 Type 和 V 值）成为 table 8.106 中第 736 页解释的 FieldMDP 转换参数字典。
现在 Adobe 对 ISO 32000 的补充，扩展级别 3，在 table 8.82 的锁定字典条目中添加了一个新条目，即 P 条目！填写相关签名字段后的此条目可用于降低先前 DocMDP 签名的原始 P 级别。
通过上述使用Lock字典的副本作为FieldMDP转换参数字典的机制， P 值现在位于 FieldMDP 转换参数中。
不幸的是，在那个补充中忘记了更新转换参数规范...
所以不，您不能忽略 P 条目（如果您完全想处理 DocMDP 和 FieldMDP 转换）。
###2。 & 4. 字节范围数组与递归对象摘要
As per page 725 of the spec, there are two reproducible ways to compute digest of the content - via byte range array, or via recursive object digest computation, as prescribed in the TransformParams entry in the signature reference dictionary. Question is, in this document, both are present. What is the purpose of the FieldMDP entry at all?
...
What is the purpose of the DigestLocation and DigestValue key-value pairs in the FieldMDP dictionary? The digest value is already provided in the Contents key of the V dictionary, right? Plus this is present within an array (Reference), here there is only one entry, what if there are multiple entries?
首先查看 PDF 参考勘误表，第六版，1.7 版：
Page 725
Add the following paragraph after the third paragraph
PDF 1.5 specified a method for computing an object digest over a subtree of objects in memory and storing the resulting digest in entries named DigestValue and DigestLocation in the signature reference dictionary. (The digest was documented in Appendix I, "Computation of Object Digests.") This method is deprecated and should not be used. All mentions of objects digests in section 8.7, "Digital Signatures", should be disregarded.
您的文档来自仍然使用旧版 Adobe Reader 的时代，因此存在兼容性对象摘要以及字节范围摘要和 FieldMDP 转换信息的首选组合。
在 ISO 32000-1 中不再提及对象摘要。
###3。签名 Contents 和 SubFilter
If I understand correctly, the value of the Contents key is the encrypted digest of the content excluding the content value stream (itself). So I first have to decrypt it. Then I have to compute the digest of the actual content excluding the content stream, and compare the two digests to see if they match. Is that right? If so, how do I do that? I suspect the Filter and SubFilter keys denote the methods, but I am unable to understand how exactly.
为此，您应该阅读 PDF 参考中的第 8.7.2 节“签名互操作性”。但请注意 SubFilter 值 adbe.x509.rsa_sha1 和 adbe.pkcs7.sha1（和相关机制）已被 PDF 2.0 弃用，而 ETSI.CAdES.detached 和 ETSI.RFC3161 已添加规范其中也可以在 ETSI EN 319 142-1 V1.1.1.
中找到
###5。摘要
As per page 1131 of the spec, the digest length is 16 bytes or 20 bytes. How can a huge PDF be squeezed into such a small digest? Isn't 16 too small a number to guarantee that no two different PDFs will have the same digest?
显然，加密哈希函数永远无法保证不会发生冲突。但是，要被认为是好的，他们必须能够声称这种碰撞是极不可能发生的，并且构造碰撞是困难的。
对于 16 或 20 字节的 MD5 和 SHA-1 算法，随机冲突的可能性很小。那不是问题。
问题是它们同时被认为是不安全的，因为难以构建碰撞。
不过，关于该部分，您在附录 I 中找到了这个，勘误表说：
Page 1131
Add the following sentence after the first sentence in this appendix:
This method for detecting modifications is deprecated and should not be used. Additionally, the description of the algorithm is known to contain significant errors.
特别是根据后一句话，即使尝试实现对象摘要计算也毫无意义。
###6。隐形签名
I understand that the digital signature in the said PDF is through a signature field. Is it possible for a digital signature to not be a signature field, that is, no associated Rect entry in the Fields array entry?
这实际上是两个问题：
a 签名可以是不可见的，即没有 in-document 可视化。您使用的旧参考资料在第 696 页的 8.6.3 字段类型下的“签名字段”部分已经这样说了：
The annotation rectangle (Rect) in such a dictionary gives the position of the field on its page. Signature fields that are not intended to be visible should have an annotation rectangle that has zero height and width.
b甚至还有签名不是某个签名域的值，你年龄权利签名，cf.第 726 页参考资料中的 8.7 数字签名部分：
At most two usage rights signatures (PDF 1.5). Its signature dictionary is referenced from the UR or UR3 (PDF 1.6) entry in the permissions dictionary (not from a signature field);
###7。过滤键
What exactly is the role of the Filter key? I can see that the SubFilter key determines which scheme to use while decrypting the content, what does the Filter key signify? The spec says that it is a signature handler. What exactly is that? What does it additionally say that the SubFilter value does not?
事实上，如今 Filter 条目在可互操作的 PDF 签名处理中变得毫无意义。
虽然在 PDF 签名的早期，过滤器确实很重要，它代表了一个处理程序，PDF 的一个模块 Reader 你需要以任何方式处理签名。一些这样的处理程序与 Reader 一起安装，其他的则必须单独安装。不同的此类签名处理程序支持完全不同的机制。
但随着时间的推移，某些机制被证明是普遍使用的，而另一些则不是，Adobe 处理程序开始支持所有这些普遍使用的机制。这些标准机制是您在 8.7.2 签名互操作性部分中找到的机制。
同时，除 Adobe 之外的其他 PDF 签名软件产品开始不使用自己的处理程序标识符，而是使用 Adobe 处理程序名称。
因此，如今人们通常可以简单地忽略 Filter 值。
###A.如何验证？
在您提问的评论中
What do I do with the MDP information in the above PDF? I have the ByteRange object, from which I can compute the total byte content of the PDF excluding the Contents key. I calculate its hash via MD5, then decrypt the Contents value with the subfilter info. Then I compare. Where exactly do I need the MDP info for? And secondly, the Reference dictionary is optional, if it were optional, how would I know that I need to apply MD5 to compute the hash of the PDF content?
你必须做什么...
检查 ByteRange 条目是否描述了除 Contents 值之外的整个文件。比照。第 740 页，“对于字节范围签名，内容是一个带有“<”和“>”分隔符的十六进制字符串。它必须正好位于 ByteRange 指定的范围之间的 space 范围内。“
SubFilter是adbe.pkcs7.detached，因此[=184=的内容]Contents 值是一个 PKCS#7 签名容器。解析此 PKCS#7 容器并确定在其中的单个 SignerInfo 对象中使用的哈希算法。这里是 SHA-1。
计算由 ByteRange 值描述的范围的 SHA-1 哈希值。
将该散列值与 PKCS#7 容器中 SignerInfo 对象的签名 messageDigest 属性值进行比较。
如果这些哈希值不匹配，则数据在签名后已被篡改。
- 确定SignerInfo签名的签名者证书。
您必须在此处使用的标准可能取决于生成签名的技术和法律环境。例如。在现代环境中，ESS 属性必须存在匹配项。
- 验证SignerInfo对象中的签名属性是否被其中的签名值正确签名。
如果不是，则 PKCS#7 容器自签名后已被操纵。
- 验证签署者证书在适当的验证时间是否有效。
这更具体到 PKI 政策和法律框架。例如。合适的验证时间是当前时间还是确定为签约时间的最佳时间？已签名的 signing-time 属性/PDF 签名字典 M 值是否值得信赖或是否必须存在存在证明？证书链应使用哪种验证模型？您接受的信任锚是什么？吊销信息呢...
- 您的签名有 MDP 字段，其中有一个更严格的 doc MDP 值。因此，您必须检查签名修订后是否有任何增量更新，如果有，它们是否包含对文档内容的不允许更改。
我可能忘记了一些支票...
How do I check if incremental updates have been made to the PDF since the signer signed the document? I know with each incremental update a new trailer and xref entry is added, but how do I know which ones were part of the original content when signed and which ones have been aded since then?
啊，好的，我看到我必须更改上面验证步骤 1 的描述，检查 ByteRange 条目是否描述了整个文件，除了 Contents value. 实际上你必须检查从文件开始到高字节范围部分结束的完整范围是否构成包含签名的有效PDF文件（当然，字节范围间隙是 Contents 值）。
如果实际的 PDF 更大，您可以假设最初签名的 PDF 是已识别的起始部分，之后的所有内容都是对签名文件的增量更新。
And how did you conclude that the hashing algorithm here is SHA1? Doesn't the reference dictionary mention MD5? The subfilter is adbe.pkcs7.detached, how do you know that the hashing algo is not, for example, SHA256? If it was adbe.pkcs7.sha1, I would understand.
是的，参考词典提到了 MD5，但这与字节范围签名无关。它指的是已弃用的对象摘要（参见上面 2. 和 4. 的答案），并且已知其计算的唯一描述无论如何都包含重大错误（参见上面 5. 的答案）。
如上验证步骤2所述，您必须解析此PKCS#7容器并确定哈希算法。在参考资料第 738 页的底部，您会读到“PKCS#7 对象必须符合rm 到 Internet RFC 2315 中的 PKCS#7 规范。”您可以找到此 RFC here. The newer ISO norms instead reference the Cryptographic Message Syntax (CMS) according to RFC 3852 or RFC 5652，它反映了 PKCS#7 容器的进一步发展阶段。
当您提取签名容器并根据上述 RFC 分析其结构时，您会发现其 SignerInfo 部分（使用 ASN.1 转储实用程序解析）是这样开始的：
3867 6086: . . . . SEQUENCE {
3871 1: . . . . . INTEGER 1
3874 75: . . . . . SEQUENCE {
3876 69: . . . . . . SEQUENCE {
3878 11: . . . . . . . SET {
3880 9: . . . . . . . . SEQUENCE {
3882 3: . . . . . . . . . OBJECT IDENTIFIER countryName (2 5 4 6)
: . . . . . . . . . . (X.520 DN component)
3887 2: . . . . . . . . . PrintableString 'US'
: . . . . . . . . . }
: . . . . . . . . }
3891 22: . . . . . . . SET {
3893 20: . . . . . . . . SEQUENCE {
3895 3: . . . . . . . . . OBJECT IDENTIFIER organizationName (2 5 4 10)
: . . . . . . . . . . (X.520 DN component)
3900 13: . . . . . . . . . PrintableString 'GeoTrust Inc.'
: . . . . . . . . . }
: . . . . . . . . }
3915 30: . . . . . . . SET {
3917 28: . . . . . . . . SEQUENCE {
3919 3: . . . . . . . . . OBJECT IDENTIFIER commonName (2 5 4 3)
: . . . . . . . . . . (X.520 DN component)
3924 21: . . . . . . . . . PrintableString 'GeoTrust CA for Adobe'
: . . . . . . . . . }
: . . . . . . . . }
: . . . . . . . }
3947 2: . . . . . . INTEGER 514
: . . . . . . }
3951 9: . . . . . SEQUENCE {
3953 5: . . . . . . OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
: . . . . . . . (OIW)
3960 0: . . . . . . NULL
: . . . . . . }
3962 1733: . . . . . [0] {
3966 24: . . . . . . SEQUENCE {
3968 9: . . . . . . . OBJECT IDENTIFIER contentType (1 2 840 113549 1 9 3)
: . . . . . . . . (PKCS #9)
3979 11: . . . . . . . SET {
3981 9: . . . . . . . . OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
: . . . . . . . . . (PKCS #7)
: . . . . . . . . }
: . . . . . . . }
3992 35: . . . . . . SEQUENCE {
3994 9: . . . . . . . OBJECT IDENTIFIER messageDigest (1 2 840 113549 1 9 4)
: . . . . . . . . (PKCS #9)
4005 22: . . . . . . . SET {
4007 20: . . . . . . . . OCTET STRING
: . . . . . . . . . 3F 00 47 E6 CB 5B 9B B0 ?.G..[..
: . . . . . . . . . 89 25 4B 20 D1 74 44 5C .%K .tD\
: . . . . . . . . . 3B A4 F5 13 ;...
: . . . . . . . . }
: . . . . . . . }
在这里你可以识别CMSVersion INTEGER 1，SignerIdentifier with subject cn=GeoTrust CA for Adobe, o=GeoTrust Inc., c=US 和 序列号 INTEGER 514，然后是 DigestAlgorithmIdentifier for sha1 1 3 14 3 2 26。这是您获取要应用于字节范围的摘要算法的地方。
此后您会看到签名属性的开头，其中包括 messageDigest 3F 00 47 E6 CB 5B 9B B0 89 25 4B 20 D1 74 44 5C 3B A4 F5 13。这是您在验证步骤 4 中比较的值。
So if we exclude the MDP checks, the basic signature validation will involve checking just the byte range entry corresponding to the catalog and comparing it against the hash value, right?
澄清一下：数学签名验证将涉及计算字节范围的哈希值并将其与存储在 CMS 容器中的哈希值进行比较（验证步骤 2..4）并验证签名值是否在CMS SignerInfo 对象对其中的签名属性进行正确签名（这通常意味着计算签名属性的哈希值，确定签名者证书，并将签名值与哈希值和签名者证书中的 public 密钥进行检查）（验证步骤 5 和 6)。
Subsequent changes will go to the incremental update section if I am not wrong. If a strict DocMDP is enforced, any incremental update will invalidate the signature. Is that accurate?
1 的 DocMDP P 值根本不允许增量更新。除非，也就是说，如果您的验证策略应包括 ETSI 扩展或 PDF 2.0：在这些情况下，增量更新仅包括将文档安全存储 (DSS) and/or 文档时间戳添加到文档所需的数据。
##关于向后兼容性
您在评论中强调，为了向后兼容，您还必须支持所有同时弃用的机制，因为那里有太多来自旧时代的 PDF。
即使这很重要，我还是建议至少先实现当前使用的机制，然后再尝试实现对象摘要等。
但实际上，这些旧签名中只有很小一部分仍然可以进行有意义的验证，因为它们通常不附带所需的验证相关信息（CRL、OCSP 响应）和存在证明（时间戳）来认真对待得到积极的验证结果。
我正在浏览官方 PDF spec. I came across a digitally signed PDF here。当我分析它的目录字典时，我看到了这个：
我对此有一些疑问：
根据规范的第 736 页，
FieldMDP没有P参数，属于DocMDP（第 733 页）。当然，PDF 可能已被某些向字典添加无关键的第三方修改。但我只是想确认一下，如果在FeldMDP中找到一个P键，是忽略它，还是有一定的意义？根据规范的第 725 页，有两种可重现的方法来计算内容的摘要 - 通过字节范围数组，或通过递归对象摘要计算，如
TransformParams签名参考词典中的条目。问题是，在本文档中，两者都存在。FieldMDP条目的目的是什么？如果我没理解错的话，
Contents键的值是内容的加密摘要，不包括内容价值流（本身）。所以我首先要解密它。然后我必须计算不包括内容流的实际内容的摘要，并比较两个摘要以查看它们是否匹配。那正确吗？如果是这样，我该怎么做？我怀疑Filter和SubFilter键表示方法，但我无法理解具体的方法。FieldMDP字典中DigestLocation和DigestValue键值对的用途是什么？摘要值已经在V字典的Contents键中提供了，对吧？加上这是一个数组（Reference），这里只有一个条目，如果有多个条目怎么办？根据规范第 1131 页，摘要长度为 16 字节或 20 字节。一个巨大的 PDF 怎么能被压缩成这么小的摘要？ 16 是不是太小了，不能保证两个不同的 PDF 不会有相同的摘要？
我了解到上述 PDF 中的数字签名是通过签名字段进行的。数字签名是否可能不是是签名字段，即
Fields数组条目中没有关联的Rect条目？Filter键的具体作用是什么？我可以看到SubFilter密钥决定了解密内容时使用的方案，Filter密钥表示什么？规范说它是一个签名处理程序。那到底是什么？另外说SubFilter值没有什么意思？
##PDF 规范
首先，文档上的一些文字指定了 PDF 格式。
最初 PDF 是一种专有的 Adobe 格式。他们很早就发布了 PDF 参考文献，使其他公司能够创建和处理 PDF 文件，但他们明确表示他们不认为参考文献 具有规范性 ；据 Adobe 的 PDF 传播者 Leonard Rosenthol 所说：
the PDF References aren't "normative" in nature - they don't (usually) make final, definitive statements - just sort of general ones.
（in an answer 在 2008 年 12 月 15 日制作的 iText 邮件列表中）
不过，在 2008 年，Adobe 最终将 PDF 格式交到了 ISO 手中，使其真正标准化为 ISO 32000-1。
当 PDF 成为 ISO 标准时，向其添加了一项新功能，人们可以为 PDF 格式定义“扩展”，并获得一种标准化的方式来在 PDF 中记录其中使用了此类扩展，cf . ISO 32000-1 第 7.12 节。
最没有table 的扩展是those published by Adobe 本身和 ETSI 的 PAdES 扩展，参见。 ETSI EN 319 142-1 V1.1.1.
去年，2017年，PDF 2.0规范ISO 32000-2已经发布。
##你的问题
###1。 P FieldMDP 转换字典中的值
As per page 736 of the spec, FieldMDP has no P parameter, that belongs to DocMDP (page 733). Of course, the PDF might have been modified by some third party who added an extraneous key to the dictionary. But I just want to confirm, if a P key is found in FeldMDP, is it to be ignored, or it has some meaning?
这是一个艰难的过程...
首先请查看第 696 和 697 页 8.6.3 字段类型下的“签名字段”部分，特别是 [=309] 中的 Lock 条目=] 8.81 的值是一个字典，其值在 table 8.82.
如果 Lock 条目存在于 yet-unsigned 签名字段中，签名期间的 Lock 字典基本上被复制（使用更新的 Type 和 V 值）成为 table 8.106 中第 736 页解释的 FieldMDP 转换参数字典。
现在 Adobe 对 ISO 32000 的补充，扩展级别 3，在 table 8.82 的锁定字典条目中添加了一个新条目，即 P 条目！填写相关签名字段后的此条目可用于降低先前 DocMDP 签名的原始 P 级别。
通过上述使用Lock字典的副本作为FieldMDP转换参数字典的机制， P 值现在位于 FieldMDP 转换参数中。
不幸的是，在那个补充中忘记了更新转换参数规范...
所以不，您不能忽略 P 条目（如果您完全想处理 DocMDP 和 FieldMDP 转换）。
###2。 & 4. 字节范围数组与递归对象摘要
As per page 725 of the spec, there are two reproducible ways to compute digest of the content - via byte range array, or via recursive object digest computation, as prescribed in the TransformParams entry in the signature reference dictionary. Question is, in this document, both are present. What is the purpose of the FieldMDP entry at all?
...
What is the purpose of the DigestLocation and DigestValue key-value pairs in the FieldMDP dictionary? The digest value is already provided in the Contents key of the V dictionary, right? Plus this is present within an array (Reference), here there is only one entry, what if there are multiple entries?
首先查看 PDF 参考勘误表，第六版，1.7 版：
Page 725
Add the following paragraph after the third paragraph
PDF 1.5 specified a method for computing an object digest over a subtree of objects in memory and storing the resulting digest in entries named DigestValue and DigestLocation in the signature reference dictionary. (The digest was documented in Appendix I, "Computation of Object Digests.") This method is deprecated and should not be used. All mentions of objects digests in section 8.7, "Digital Signatures", should be disregarded.
您的文档来自仍然使用旧版 Adobe Reader 的时代，因此存在兼容性对象摘要以及字节范围摘要和 FieldMDP 转换信息的首选组合。
在 ISO 32000-1 中不再提及对象摘要。
###3。签名 Contents 和 SubFilter
If I understand correctly, the value of the Contents key is the encrypted digest of the content excluding the content value stream (itself). So I first have to decrypt it. Then I have to compute the digest of the actual content excluding the content stream, and compare the two digests to see if they match. Is that right? If so, how do I do that? I suspect the Filter and SubFilter keys denote the methods, but I am unable to understand how exactly.
为此，您应该阅读 PDF 参考中的第 8.7.2 节“签名互操作性”。但请注意 SubFilter 值 adbe.x509.rsa_sha1 和 adbe.pkcs7.sha1（和相关机制）已被 PDF 2.0 弃用，而 ETSI.CAdES.detached 和 ETSI.RFC3161 已添加规范其中也可以在 ETSI EN 319 142-1 V1.1.1.
中找到###5。摘要
As per page 1131 of the spec, the digest length is 16 bytes or 20 bytes. How can a huge PDF be squeezed into such a small digest? Isn't 16 too small a number to guarantee that no two different PDFs will have the same digest?
显然，加密哈希函数永远无法保证不会发生冲突。但是，要被认为是好的，他们必须能够声称这种碰撞是极不可能发生的，并且构造碰撞是困难的。
对于 16 或 20 字节的 MD5 和 SHA-1 算法，随机冲突的可能性很小。那不是问题。
问题是它们同时被认为是不安全的，因为难以构建碰撞。
不过，关于该部分，您在附录 I 中找到了这个，勘误表说：
Page 1131
Add the following sentence after the first sentence in this appendix:
This method for detecting modifications is deprecated and should not be used. Additionally, the description of the algorithm is known to contain significant errors.
特别是根据后一句话，即使尝试实现对象摘要计算也毫无意义。
###6。隐形签名
I understand that the digital signature in the said PDF is through a signature field. Is it possible for a digital signature to not be a signature field, that is, no associated Rect entry in the Fields array entry?
这实际上是两个问题：
a 签名可以是不可见的，即没有 in-document 可视化。您使用的旧参考资料在第 696 页的 8.6.3 字段类型下的“签名字段”部分已经这样说了：
The annotation rectangle (Rect) in such a dictionary gives the position of the field on its page. Signature fields that are not intended to be visible should have an annotation rectangle that has zero height and width.
b甚至还有签名不是某个签名域的值，你年龄权利签名，cf.第 726 页参考资料中的 8.7 数字签名部分：
At most two usage rights signatures (PDF 1.5). Its signature dictionary is referenced from the UR or UR3 (PDF 1.6) entry in the permissions dictionary (not from a signature field);
###7。过滤键
What exactly is the role of the Filter key? I can see that the SubFilter key determines which scheme to use while decrypting the content, what does the Filter key signify? The spec says that it is a signature handler. What exactly is that? What does it additionally say that the SubFilter value does not?
事实上，如今 Filter 条目在可互操作的 PDF 签名处理中变得毫无意义。
虽然在 PDF 签名的早期，过滤器确实很重要，它代表了一个处理程序，PDF 的一个模块 Reader 你需要以任何方式处理签名。一些这样的处理程序与 Reader 一起安装，其他的则必须单独安装。不同的此类签名处理程序支持完全不同的机制。
但随着时间的推移，某些机制被证明是普遍使用的，而另一些则不是，Adobe 处理程序开始支持所有这些普遍使用的机制。这些标准机制是您在 8.7.2 签名互操作性部分中找到的机制。
同时，除 Adobe 之外的其他 PDF 签名软件产品开始不使用自己的处理程序标识符，而是使用 Adobe 处理程序名称。
因此，如今人们通常可以简单地忽略 Filter 值。
###A.如何验证？
在您提问的评论中
What do I do with the MDP information in the above PDF? I have the ByteRange object, from which I can compute the total byte content of the PDF excluding the Contents key. I calculate its hash via MD5, then decrypt the Contents value with the subfilter info. Then I compare. Where exactly do I need the MDP info for? And secondly, the Reference dictionary is optional, if it were optional, how would I know that I need to apply MD5 to compute the hash of the PDF content?
你必须做什么...
检查 ByteRange 条目是否描述了除 Contents 值之外的整个文件。比照。第 740 页，“对于字节范围签名，内容是一个带有“<”和“>”分隔符的十六进制字符串。它必须正好位于 ByteRange 指定的范围之间的 space 范围内。“
SubFilter是adbe.pkcs7.detached，因此[=184=的内容]Contents 值是一个 PKCS#7 签名容器。解析此 PKCS#7 容器并确定在其中的单个 SignerInfo 对象中使用的哈希算法。这里是 SHA-1。
计算由 ByteRange 值描述的范围的 SHA-1 哈希值。
将该散列值与 PKCS#7 容器中 SignerInfo 对象的签名 messageDigest 属性值进行比较。
如果这些哈希值不匹配，则数据在签名后已被篡改。
- 确定SignerInfo签名的签名者证书。
您必须在此处使用的标准可能取决于生成签名的技术和法律环境。例如。在现代环境中，ESS 属性必须存在匹配项。
- 验证SignerInfo对象中的签名属性是否被其中的签名值正确签名。
如果不是，则 PKCS#7 容器自签名后已被操纵。
- 验证签署者证书在适当的验证时间是否有效。
这更具体到 PKI 政策和法律框架。例如。合适的验证时间是当前时间还是确定为签约时间的最佳时间？已签名的 signing-time 属性/PDF 签名字典 M 值是否值得信赖或是否必须存在存在证明？证书链应使用哪种验证模型？您接受的信任锚是什么？吊销信息呢...
- 您的签名有 MDP 字段，其中有一个更严格的 doc MDP 值。因此，您必须检查签名修订后是否有任何增量更新，如果有，它们是否包含对文档内容的不允许更改。
我可能忘记了一些支票...
How do I check if incremental updates have been made to the PDF since the signer signed the document? I know with each incremental update a new trailer and xref entry is added, but how do I know which ones were part of the original content when signed and which ones have been aded since then?
啊，好的，我看到我必须更改上面验证步骤 1 的描述，检查 ByteRange 条目是否描述了整个文件，除了 Contents value. 实际上你必须检查从文件开始到高字节范围部分结束的完整范围是否构成包含签名的有效PDF文件（当然，字节范围间隙是 Contents 值）。
如果实际的 PDF 更大，您可以假设最初签名的 PDF 是已识别的起始部分，之后的所有内容都是对签名文件的增量更新。
And how did you conclude that the hashing algorithm here is SHA1? Doesn't the reference dictionary mention MD5? The subfilter is adbe.pkcs7.detached, how do you know that the hashing algo is not, for example, SHA256? If it was adbe.pkcs7.sha1, I would understand.
是的，参考词典提到了 MD5，但这与字节范围签名无关。它指的是已弃用的对象摘要（参见上面 2. 和 4. 的答案），并且已知其计算的唯一描述无论如何都包含重大错误（参见上面 5. 的答案）。
如上验证步骤2所述，您必须解析此PKCS#7容器并确定哈希算法。在参考资料第 738 页的底部，您会读到“PKCS#7 对象必须符合rm 到 Internet RFC 2315 中的 PKCS#7 规范。”您可以找到此 RFC here. The newer ISO norms instead reference the Cryptographic Message Syntax (CMS) according to RFC 3852 or RFC 5652，它反映了 PKCS#7 容器的进一步发展阶段。
当您提取签名容器并根据上述 RFC 分析其结构时，您会发现其 SignerInfo 部分（使用 ASN.1 转储实用程序解析）是这样开始的：
3867 6086: . . . . SEQUENCE {
3871 1: . . . . . INTEGER 1
3874 75: . . . . . SEQUENCE {
3876 69: . . . . . . SEQUENCE {
3878 11: . . . . . . . SET {
3880 9: . . . . . . . . SEQUENCE {
3882 3: . . . . . . . . . OBJECT IDENTIFIER countryName (2 5 4 6)
: . . . . . . . . . . (X.520 DN component)
3887 2: . . . . . . . . . PrintableString 'US'
: . . . . . . . . . }
: . . . . . . . . }
3891 22: . . . . . . . SET {
3893 20: . . . . . . . . SEQUENCE {
3895 3: . . . . . . . . . OBJECT IDENTIFIER organizationName (2 5 4 10)
: . . . . . . . . . . (X.520 DN component)
3900 13: . . . . . . . . . PrintableString 'GeoTrust Inc.'
: . . . . . . . . . }
: . . . . . . . . }
3915 30: . . . . . . . SET {
3917 28: . . . . . . . . SEQUENCE {
3919 3: . . . . . . . . . OBJECT IDENTIFIER commonName (2 5 4 3)
: . . . . . . . . . . (X.520 DN component)
3924 21: . . . . . . . . . PrintableString 'GeoTrust CA for Adobe'
: . . . . . . . . . }
: . . . . . . . . }
: . . . . . . . }
3947 2: . . . . . . INTEGER 514
: . . . . . . }
3951 9: . . . . . SEQUENCE {
3953 5: . . . . . . OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
: . . . . . . . (OIW)
3960 0: . . . . . . NULL
: . . . . . . }
3962 1733: . . . . . [0] {
3966 24: . . . . . . SEQUENCE {
3968 9: . . . . . . . OBJECT IDENTIFIER contentType (1 2 840 113549 1 9 3)
: . . . . . . . . (PKCS #9)
3979 11: . . . . . . . SET {
3981 9: . . . . . . . . OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
: . . . . . . . . . (PKCS #7)
: . . . . . . . . }
: . . . . . . . }
3992 35: . . . . . . SEQUENCE {
3994 9: . . . . . . . OBJECT IDENTIFIER messageDigest (1 2 840 113549 1 9 4)
: . . . . . . . . (PKCS #9)
4005 22: . . . . . . . SET {
4007 20: . . . . . . . . OCTET STRING
: . . . . . . . . . 3F 00 47 E6 CB 5B 9B B0 ?.G..[..
: . . . . . . . . . 89 25 4B 20 D1 74 44 5C .%K .tD\
: . . . . . . . . . 3B A4 F5 13 ;...
: . . . . . . . . }
: . . . . . . . }
在这里你可以识别CMSVersion INTEGER 1，SignerIdentifier with subject cn=GeoTrust CA for Adobe, o=GeoTrust Inc., c=US 和 序列号 INTEGER 514，然后是 DigestAlgorithmIdentifier for sha1 1 3 14 3 2 26。这是您获取要应用于字节范围的摘要算法的地方。
此后您会看到签名属性的开头，其中包括 messageDigest 3F 00 47 E6 CB 5B 9B B0 89 25 4B 20 D1 74 44 5C 3B A4 F5 13。这是您在验证步骤 4 中比较的值。
So if we exclude the MDP checks, the basic signature validation will involve checking just the byte range entry corresponding to the catalog and comparing it against the hash value, right?
澄清一下：数学签名验证将涉及计算字节范围的哈希值并将其与存储在 CMS 容器中的哈希值进行比较（验证步骤 2..4）并验证签名值是否在CMS SignerInfo 对象对其中的签名属性进行正确签名（这通常意味着计算签名属性的哈希值，确定签名者证书，并将签名值与哈希值和签名者证书中的 public 密钥进行检查）（验证步骤 5 和 6)。
Subsequent changes will go to the incremental update section if I am not wrong. If a strict DocMDP is enforced, any incremental update will invalidate the signature. Is that accurate?
1 的 DocMDP P 值根本不允许增量更新。除非，也就是说，如果您的验证策略应包括 ETSI 扩展或 PDF 2.0：在这些情况下，增量更新仅包括将文档安全存储 (DSS) and/or 文档时间戳添加到文档所需的数据。
##关于向后兼容性
您在评论中强调，为了向后兼容，您还必须支持所有同时弃用的机制，因为那里有太多来自旧时代的 PDF。
即使这很重要，我还是建议至少先实现当前使用的机制，然后再尝试实现对象摘要等。
但实际上，这些旧签名中只有很小一部分仍然可以进行有意义的验证，因为它们通常不附带所需的验证相关信息（CRL、OCSP 响应）和存在证明（时间戳）来认真对待得到积极的验证结果。