2

我们的 TSA 最近升级了他们的 TSA 服务器，但这导致在我们尝试对 PDF 进行数字签名和时间戳（使用 C# 代码）时出现“存在冲突的签名证书属性”错误。

如果我使用 TSA 的旧服务器或 SignFiles 测试服务器，那么一切都会按预期工作，但是一旦我切换到新服务器，就会出现问题。

我们正在使用 SignFiles，它看起来是 BouncyCastle 的简单包装器。错误发生在 Bouncy Castle "Validate(...)" 方法中。

VS 代码显示错误

我相信错误是由于下面突出显示的调用而发生的。

BouncyCastle 代码 - 验证（...）发生错误的位置

在这一点上，我有点迷茫，因为我不知道上面的代码正在检查什么值，但我认为它可能是“增强的密钥用法”值。

如果是，那么我看到旧时间戳（左侧）和新时间戳（右侧）之间存在以下差异。

TSA 退回的工作和非工作证书

谁能建议这是否是它正在检查的正确值？

谁能告知为什么会发生此错误，以及 TSA 是否可以在其设置中纠正它以及时间戳是如何生成的，或者是否需要更新 Bouncy Castle 以与新的 TSA 服务器一起使用？

我们将继续使用旧版服务器，但需要修复此问题以利用新的更快的服务器。

我只在以下位置发现了另一个问题： http ://bouncy-castle.1462172.n4.nabble.com/Time-Stamp-with-both-SigningCertificate-and-SigningCertificateV2-td3457605.html

谢谢，

抢

4

1 回答 1

2

您的客户端库似乎在内部使用早于 1.8 的 BouncyCastle，它错误地处理了时间戳。正如您正确地发现这个问题（由我）在JIRA 问题 85中报告并在 BouncyCastle 1.8 中修复。

原始符合RFC3161 的时间戳仅包括SigningCertificate(OID 1.2.840.113549.1.9.16.2.12) CMS 属性和 TSA 证书的 SHA-1 哈希。但是由于全世界都放弃了 SHA-1，RFC5035更新了 RFC3161 并允许使用SigningCertificateV2(OID 1.2.840.113549.1.9.16.2.47) CMS 属性和 TSA 证书的 SHA-256（或任何其他）哈希值。它还允许同时使用这两个属性来支持可能不支持新哈希算法的旧客户端。所以 IMO 完全可以让 TSA 包含这两个属性。

你有两个选择：

  1. 要求您的客户端库的提供者将其升级到已修复问题的 BouncyCastle 1.8 。IMO 这会更容易。
  2. 要求您的时间戳提供者重新配置其 TSA 服务器，使其生成的时间戳中不包含这两个 CMS 属性。IMO 这会更难。

如果有什么不够清楚或者您需要更多详细信息，请告诉我。

于 2017-11-26T07:56:43.520 回答