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

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.