2

Curious to know what the standard practice is to maintain old/revoked certificates that were previously used to sign documents that must be verified in the future.

For example, suppose there is a service that signs documents and they have a valid SSL certificate valid for one year. The service signs documents 0-1000 during the first year, 1000-2000 the second year, etc. (to keep things simple). After ten years, there will be a new certificate used for documents 9000-10000, however customers need to verify any/all of the previous documents signed with old keys. At this point they will have 10 certificates/public keys total.

So, the private key can be taken off the server to protect it from compromise, but the public key will need to remain for verification through the service itself (and the customers can also keep a copy of the public key for their own verification). In this case, does the service either:

a. loop through all the previous public keys to see if one fits
b. re-sign all of the old signatures each time a new private key is purchased
c. keep track of which documents were signed with which particular key?
d. another option not mentioned here

Also included is the possibility that in year 5, the private key used to sign documents 4000-4500 has been revoked, so a new key was needed for 4500-5000 (after any security issues were resolved).

migrated from serverfault.com Jan 11 at 13:17

This question came from our site for system and network administrators.

  • Elaborate on your use case. It is very much not standard practice to sign documents and throw away any metadata about the keys used for that operation. – anx Jan 11 at 2:49
2

Neither of mentioned options are correct. Why? Because public part of the signing certificate is attached to each particular signature. If anyone (say, client) needs to validate the signature, client reads signature data and extracts signature value and signing certificate. Client uses public key to validate the signature.

The only requirement here is that signing certificate must be trusted, that is, its chain ends in one of the root certificates trusted by client. Some applications require explicit trust to signing certificate, so client compares whether the attached (to signature) certificate is explicitly trusted by client.

Also, SSL certificate is not suited for data signing (does not include Code Signing or Document Signing value in the EKU extension), because it is intended for server authentication. During TLS communication only handshake data is signed to prove the private key possession.

I believe, this blog post (mine) will be helpful: https://www.sysadmins.lv/blog-en/digital-signatures.aspx

  • Sorry for the delay, I wanted to digest all the info. A question: for my question I am the TSA for the rfc3161 timestamps. I believe there is only one date in the rfc3161 structure, but it sounds like from your post there may be two: one timestamp for when the TSA is stating existence, and a second timestamp stating the time of creation for the actual timestamp (i.e. the TSA affirms today that you had something a week ago, I know this is bad practice). With only one timestamp in rfc3161, if a private key is compromised they can use utilities to create a timestamp with any date they want. – user58446 Jan 21 at 21:10
  • Considering they can create an rfc3161 timestamp with any date they want, how can someone trying to validate the timestamp (which was granted before revocation) know for sure it was created during the validity period? – user58446 Jan 21 at 21:11
  • Also, in the cases where you discuss timestamped signatures, I am guessing you are referring to something like rfc3161. But in this case the time authority (TSA) is the same party that had their certificate compromised, so how can anything still be trusted? I imagine a scenario where a TSA might have a secondary timestamp from a "4th party" TSA, but this seems incorrect/redundant. – user58446 Jan 21 at 21:15
  • Where did you get the information about second timestamp? Signed blob carries only one timestamp per signature. And this timestamp assures that the content (content proof is made via content hash) existed at specified date and time. – Crypt32 Jan 22 at 5:32
  • If TSA certificate is compromised and revoked, the signature is considered not timestamped. This is shown in the summary table (in the article). – Crypt32 Jan 22 at 5:34

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.