实现PDF中PAdES LTV数字签名的底层流程问询

1. DSS存储的创建时机 #

• 建议在添加带CAdES子过滤器的签名占位符阶段就创建空的DSS（Document Security Store）存储。提前占位能避免后续修改PDF结构时破坏签名完整性，同时符合PDF规范中签名对象与辅助验证存储关联的要求，后续只需向DSS中填充时间戳、OCSP响应、证书等材料即可。

2. 用户私钥签名与证书嵌入的确认 #

• 你当前实现的「用用户私钥签名并将证书嵌入签名、替换签名字典内容」操作是基础签名的核心步骤，没问题。需确保签名字典的/SubFilter字段设置为符合CAdES标准的值，比如/ETSI.CAdES.detached，保证后续LTV扩展的兼容性。

3. 向TSA发送的内容 #

• 要发送的是签名哈希值，而非完整签名或原始字节码。具体流程：
  1. 计算PDF签名域/ByteRange指定区域的哈希值；
  2. 将哈希值封装为RFC 3161标准的TimeStampReq结构；
  3. 发送给TSA后，TSA会对该哈希附加时间戳信息，再用自身私钥签名生成TimeStampResp响应。

4. 时间戳在PDF中的位置 #

• 时间戳不能覆盖原有签名内容，需放在两个指定位置：
  • 签名字典的/Timestamp条目：直接存储TSA返回的TimeStampResp原始字节数据，替换预留的/Timestamp种子值；
  • DSS存储：将时间戳及关联的TSA证书加入DSS的/TimestampValidation集合中，用于LTV验证时的路径追溯。
• 注意：绝对不能修改签名字典的/Contents字段（该字段存储用户的核心签名数据）。

5. TSA证书的存储要求 #

• 正确，必须将TSA的证书（含完整证书链）添加到DSS的/Certificates数组中，并在/TimestampValidation中建立时间戳与对应证书的关联，确保验证工具能自动获取时间戳的验证路径。

6. OCSP响应的存储与验证流程 #

• OCSP响应不需要叠加到/Contents字段，正确处理方式：
  1. 将OCSP响应的原始数据添加到DSS的/OCSPs数组中；
  2. 在DSS的/ValidationReferences里建立OCSP响应与对应签名证书的关联，明确该OCSP响应对应哪个证书的有效性查询；
• LTV验证时，工具会按「用户签名验证 → 读取DSS中OCSP响应确认证书签名时的有效性 → 读取DSS中时间戳确认OCSP响应及签名的时间有效性」的顺序执行，无需反向解密叠加签名，所有验证材料均独立存储在DSS中，与用户核心签名分离。

内容的提问来源于stack exchange，提问作者dragonsdesign