存在冲突的签名证书属性 - 来自 TSA 的 PDF 时间戳
Conflicting signing certificate attributes present - Timestamp from TSA for PDF
我们的 TSA 最近升级了他们的 TSA 服务器，但这会导致在我们尝试对 PDF 进行数字签名和时间戳（使用 C# 代码）时出现 "Conflicting signing certificate attributes present" 错误。
如果我使用 TSA 的旧服务器或 SignFiles 测试服务器，那么一切都会按预期运行，但是一旦我切换到新服务器，就会出现问题。
我们正在使用 SignFiles，它看起来是 BouncyCastle 的简单包装器。错误发生在 Bouncy Castle "Validate(...)" 方法中。
VS Code Showing Error
我认为该错误是以下突出显示的调用的结果。
BouncyCastle Code - Validate(...) where error happens
在这一点上，我有点迷茫，因为我不知道上面的代码正在检查什么值，但我认为它可能是 "Enhanced Key Usage" 值。
如果是，那么我看到旧时间戳（左侧）和不起作用的新时间戳（右侧）之间存在以下差异。
Working and Non-Working Certificates Returned by TSA
谁能告诉我这是不是正在检查的正确值？
谁能告诉我为什么会发生这个错误，TSA 是否可以在他们的设置中更正它，时间戳是如何生成的，或者 Bouncy Castle 是否需要更新才能与新的 TSA 服务器一起使用？
我们将继续使用旧服务器，但需要修复此问题才能利用速度更快的新服务器。
我只在以下位置发现了一个与此相关的问题：
http://bouncy-castle.1462172.n4.nabble.com/Time-Stamp-with-both-SigningCertificate-and-SigningCertificateV2-td3457605.html
谢谢，
罗布
您的客户端库似乎在内部使用早于 1.8 的 BouncyCastle，它错误地处理了时间戳。你已经正确地发现这个问题是（由我）在 JIRA issue 85 中报告并在 BouncyCastle 1.8 中修复的。
原始 RFC3161 compliant timestamps included only SigningCertificate (OID 1.2.840.113549.1.9.16.2.12) CMS attribute with SHA-1 hash of TSA certificate. But since whole world abandoned SHA-1, RFC5035 更新了 RFC3161 并允许使用 SigningCertificateV2 (OID 1.2.840.113549.1.9.16.2.47) CMS 属性和 TSA 证书的 SHA-256（或任何其他）散列。它还允许同时使用这两个属性，以支持可能不支持新哈希算法的旧版客户端。所以 IMO 完全可以让 TSA 包含这两个属性。
您有两个选择：
- 请您的客户端库提供商将其升级到 BouncyCastle 1.8，其中 the issue has been fixed。 IMO 这会更容易。
- 请您的时间戳提供商重新配置他们的 TSA 服务器，这样它就不会在其生成的时间戳中包含这两个 CMS 属性。 IMO 这会更难。
如果有什么地方不够清楚或您需要更多详细信息，请告诉我。
我们的 TSA 最近升级了他们的 TSA 服务器，但这会导致在我们尝试对 PDF 进行数字签名和时间戳（使用 C# 代码）时出现 "Conflicting signing certificate attributes present" 错误。
如果我使用 TSA 的旧服务器或 SignFiles 测试服务器，那么一切都会按预期运行，但是一旦我切换到新服务器，就会出现问题。
我们正在使用 SignFiles，它看起来是 BouncyCastle 的简单包装器。错误发生在 Bouncy Castle "Validate(...)" 方法中。
VS Code Showing Error
我认为该错误是以下突出显示的调用的结果。
BouncyCastle Code - Validate(...) where error happens
在这一点上，我有点迷茫，因为我不知道上面的代码正在检查什么值，但我认为它可能是 "Enhanced Key Usage" 值。
如果是，那么我看到旧时间戳（左侧）和不起作用的新时间戳（右侧）之间存在以下差异。
Working and Non-Working Certificates Returned by TSA
谁能告诉我这是不是正在检查的正确值？
谁能告诉我为什么会发生这个错误，TSA 是否可以在他们的设置中更正它，时间戳是如何生成的，或者 Bouncy Castle 是否需要更新才能与新的 TSA 服务器一起使用？
我们将继续使用旧服务器，但需要修复此问题才能利用速度更快的新服务器。
我只在以下位置发现了一个与此相关的问题： http://bouncy-castle.1462172.n4.nabble.com/Time-Stamp-with-both-SigningCertificate-and-SigningCertificateV2-td3457605.html
谢谢，
罗布
您的客户端库似乎在内部使用早于 1.8 的 BouncyCastle，它错误地处理了时间戳。你已经正确地发现这个问题是（由我）在 JIRA issue 85 中报告并在 BouncyCastle 1.8 中修复的。
原始 RFC3161 compliant timestamps included only SigningCertificate (OID 1.2.840.113549.1.9.16.2.12) CMS attribute with SHA-1 hash of TSA certificate. But since whole world abandoned SHA-1, RFC5035 更新了 RFC3161 并允许使用 SigningCertificateV2 (OID 1.2.840.113549.1.9.16.2.47) CMS 属性和 TSA 证书的 SHA-256（或任何其他）散列。它还允许同时使用这两个属性，以支持可能不支持新哈希算法的旧版客户端。所以 IMO 完全可以让 TSA 包含这两个属性。
您有两个选择：
- 请您的客户端库提供商将其升级到 BouncyCastle 1.8，其中 the issue has been fixed。 IMO 这会更容易。
- 请您的时间戳提供商重新配置他们的 TSA 服务器，这样它就不会在其生成的时间戳中包含这两个 CMS 属性。 IMO 这会更难。
如果有什么地方不够清楚或您需要更多详细信息，请告诉我。