使用ESIG/DSS将数字签名添加到带有可见时间戳和原因字段的PDF中

Question

我试图理解并实现一个基于欧盟委员会赞助的数字签名服务项目的解决方案。在Nowina NexU客户端软件的帮助下，我目前已经成功地使用了上述github链接中提到的DSS-DEMO应用程序提供的抽象。我希望使用以下配置对PDF文档进行数字签名：

• 没有容器
• PAdES签名表
• 笼罩着
• PAdES_BASELINE_LT签名级别
• SHA256摘要算法

我希望签名有一个可见的部分，即在文件的第一页上可以看到。这在这里得到了一些证明。就我个人而言，我需要实际的签名时间戳和签名者证书上的姓名。在上面的演示中，这是通过向签名函数提供“参数”来实现的。

我还想填写签名的原因字段——随后，当您使用Adobe Acrobat Reader之类的程序查看签名属性时，它会显示出来。

到目前为止，我的问题如下，我似乎既找不到例子，也找不到其他关于它们的信息。

1. 如果我想显示我将从时间戳授权服务获得的签名时间戳，我将如何获得它，因为与时间戳服务器的通信是在签名过程中完成的，即在指定了我上面提到的参数之后。我想我必须深入研究DSS代码，并亲自完成所有步骤

代码的组织大致如下——两台机器之间有一个REST通信——一台服务器和一个安装了NexU的客户端。NexU与智能卡或客户端机器上的任何其他证书存储库进行所有通信——它与服务器交换摘要值和签名摘要值。服务器代码中有两个特定的阶段：

• getDataToSign——此处根据PDF内容计算摘要

我为这两个阶段提供了大量参数，其中包括指定签名时间戳、原因以及我希望出现在第一页的文本的视觉参数。我在这两个阶段使用相同的参数（因为我不确定我应该给出哪个阶段）

我的签名日期——它尽可能接近时间戳权威服务器的时间戳，这难道不合乎逻辑吗？好吧——我在签名过程开始时将它设置为我自己服务器的当前时间戳。

我正在使用PAdESSignatureParameters设置原因。原因。任何有用的见解都将不胜感激——谢谢。

Answer 1

1. 我已经用签名的原因字段解决了这个奇怪的问题。
2. 我似乎看不出签署日期与时间戳管理局提供的时间戳有什么不同。

解释如下。

至于第一个案子，那是我的错。为了详细说明，根据我的理解，签名参数使用SigningService提供给DSS方法两次。fillParameters（）方法。

1. 在SigningService.getDataToSign（...）中，然后
2. 在SigningService.sign文档（...）

这在两种方法中都很重要，因为在第一次计算待签名文档的哈希/摘要。由于我选择了要封装的签名，即包含在将要签名的文档中，我们需要首先应用签名，然后根据“最终”文档计算摘要。

就我在DSS代码中看到的（大约），上传的PDF的内存表示形式在getDataToSign期间被签名，其摘要被计算-但结果被丢弃。

在实际的signDocument方法中（在这两种方法之间，摘要已返回到安装了NexU的客户端，并返回到已签名的服务器），上传的PDF将再次签名，其摘要将再次计算，但这一次，实际的签名摘要（我们从客户机获得）也应用于该文档，并且该操作的内存结果将作为签名的PDF文档发送回客户机。

我做错了的是，在第一次，我丢失了我要添加的变量作为原因（它丢失在模型属性中的某个地方——我没有在请求之间传递它），由于传递给getDataToSign的第一个参数映射的结果与第二个参数映射的结果不同，所以文档的实际哈希/摘要与保存的签名中的摘要不同是合乎逻辑的（因为在计算要签名的摘要时，我没有传递原因）。这就是为什么当我传递一个硬编码的值时，因为它是硬编码的，所以在两次调用fillParameters时它都存在。我知道这是个愚蠢的错误。我应该知道这一点，因为向签名传递原因（或其他字段，如位置）绝对没有任何困难。

顺便说一句，签名是使用ApachePDFBox完成的，并且是增量完成的。

至于第二件事，我们决定保持原样，尽管签名时间戳和授权时间戳之间有一个相对令人印象深刻的差距。我真的不知道在这种情况下，允许的差距应该是多少。我猜这是因为

1. 我的服务器可能会稍微偏离正常的本地时间
2. 因为整个签名过程是在两台机器（安装了NexU的服务器和客户端，以及智能卡）之间进行的，而且出现了不同的对话框窗口，要求输入密码等等——这一切都推迟了实际的签名，并在最后一步完成了对时间戳授权机构的调用。当然，我不确定这是否是一个问题，因为从理论上讲，时间戳机构不知道正在更改的实际内容——在这种情况下会触发之前的错误

更像是这样——当然，我对其他评论和答案持开放态度。非常感谢。