Conflicting signing certificate attributes present - Timestamp from TSA for PDF

user_3435311 0
Viewed 779

Our TSA recently upgraded their TSA servers, but this is causing the "Conflicting signing certificate attributes present" error to occur when we attempt to Digitally Sign and Timestamp our PDFs (using C# code).

If I used the TSA's old server or SignFiles test server, then everything works as expected, but once I switch to the new server, then issues occur.

We are using SignFiles which looks to be a simple wrapper around BouncyCastle. The error occurs within the Bouncy Castle "Validate(...)" method.

VS Code Showing Error

I believe the error is happening as a result of the highlighted calls below.

BouncyCastle Code - Validate(...) where error happens

At this point, I am a bit lost as I do not know what values the above code is checking, but I am thinking it might be the "Enhanced Key Usage" values.

If yes, then I see the following differences between the old Timestamp (left side) and the new one that does not work (right).

Working and Non-Working Certificates Returned by TSA

Can anyone advise if this is the correct values that it is checking?

Can anyone advise why this error is happening and if its something that the TSA can correct within their settings and how the Timestamp is generated OR does Bouncy Castle need to be updated to work with new TSA servers?

We are continuing to use the legacy servers, but need to get this fixed to take advantage of the new faster servers.

I only found one other question regarding this at: http://bouncy-castle.1462172.n4.nabble.com/Time-Stamp-with-both-SigningCertificate-and-SigningCertificateV2-td3457605.html

Thank you,

Rob

trusted-timestamp bouncycastle x509certificate
1 Answers

It seems that your client library is internally using BouncyCastle older than 1.8 which was incorrectly processing timestamps. As you have correctly found out this problem was reported (by me) in JIRA issue 85 and fixed in BouncyCastle 1.8.

Original 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 updated RFC3161 and allowed the usage of SigningCertificateV2 (OID 1.2.840.113549.1.9.16.2.47) CMS attribute with SHA-256 (or any other) hash of TSA certificate. It also allowed the usage of both attributes at the same time to support legacy clients that may not support new hash algorithms. So IMO it is perfectly OK for TSA to include both attributes.

You have two options:

  1. Ask the provider of your client library to upgrade it to BouncyCastle 1.8 where the issue has been fixed. IMO this would be easier.
  2. Ask your timestamp provider to reconfigure their TSA server so it does not include both CMS attributes in timestamps it generates. IMO this would be harder.

Let me know if something is not clear enough or you need more details.

user_33257040
Related