4 ms·

Remember folks, if code signing, countersign with a timestamping service[1] so when your code signing cert expires, your older signed code will still work. [1]h

Remember folks, if code signing, countersign with a timestamping service[1] so when your code signing cert expires, your older signed code will still work. [1]https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=INFO1119&actp=LIST https://search.thawte.com/support/ssl-digital-certificates/i...

hughes 9y ago
What happens when the countersigning service's cert expires?
- Kikawala 9y ago
  By adding a timestamp to digital signatures, trust conditions are changed to the following list: * data is not tampered * signing certificate was time valid at signing time: signing time is within signing cert's validity * Neither certificate was revoked before signature generation * both, signing and timestamp certificates chain up to trusted root CAs (regardless of their time validity, just must be in trust store). https://serverfault.com/a/878950 https://serverfault.com/a/878950
  - cxseven 9y ago
    That's weird. The blog post that answer links to implies that even if the timestamp certificate AND signing certificates are revoked on a date following the purported timestamp, then the signature is still trusted. That doesn't make sense to me: If the certificates are compromised, an attacker could backdate the timestamp to whatever he wanted and sign anything. What's the thinking here?
    - Kikawala 9y ago
      Take a look at the "Digital signature lifecycle table" here: https://www.sysadmins.lv/blog-en/digital-signatures.aspx https://www.sysadmins.lv/blog-en/digital-signatures.aspx
    - moefh 9y ago
      > implies that even if the timestamp certificate AND signing certificates are revoked on a date following the purported timestamp, then the signature is still trusted. That's not how I read it. The "lifecycle table" doesn't mention the case of both signing and timestamping certificates going bad at the same time, only what happens if one of them expires or is revoked. The only mention about both certificates going bad is in the text below the table: > But timestamped signature remains considered as a valid even if all certificates in the signing and timestamping chains are expired. Note that it doesn't say anything about certificates being revoked.
    - lsaferite 9y ago
      As an outsider my guess is that by having a signer and counter-signer you are accepting that the chance of both certs being compromised is minimal enough. Of course this sorta falls apart if you consider large bad actors could have legit timestamp certs over a period of time and then use those historic certs on backdated servers to counter-sign a stolen signing cert. It would appear as a legit signed and counter-signed cert done when the signing certs were valid.

hughes 9y ago

What happens when the countersigning service's cert expires?

Kikawala 9y ago
By adding a timestamp to digital signatures, trust conditions are changed to the following list: * data is not tampered * signing certificate was time valid at signing time: signing time is within signing cert's validity * Neither certificate was revoked before signature generation * both, signing and timestamp certificates chain up to trusted root CAs (regardless of their time validity, just must be in trust store). https://serverfault.com/a/878950 https://serverfault.com/a/878950
- cxseven 9y ago
  That's weird. The blog post that answer links to implies that even if the timestamp certificate AND signing certificates are revoked on a date following the purported timestamp, then the signature is still trusted. That doesn't make sense to me: If the certificates are compromised, an attacker could backdate the timestamp to whatever he wanted and sign anything. What's the thinking here?
  - Kikawala 9y ago
    Take a look at the "Digital signature lifecycle table" here: https://www.sysadmins.lv/blog-en/digital-signatures.aspx https://www.sysadmins.lv/blog-en/digital-signatures.aspx
  - moefh 9y ago
    > implies that even if the timestamp certificate AND signing certificates are revoked on a date following the purported timestamp, then the signature is still trusted. That's not how I read it. The "lifecycle table" doesn't mention the case of both signing and timestamping certificates going bad at the same time, only what happens if one of them expires or is revoked. The only mention about both certificates going bad is in the text below the table: > But timestamped signature remains considered as a valid even if all certificates in the signing and timestamping chains are expired. Note that it doesn't say anything about certificates being revoked.
  - lsaferite 9y ago
    As an outsider my guess is that by having a signer and counter-signer you are accepting that the chance of both certs being compromised is minimal enough. Of course this sorta falls apart if you consider large bad actors could have legit timestamp certs over a period of time and then use those historic certs on backdated servers to counter-sign a stolen signing cert. It would appear as a legit signed and counter-signed cert done when the signing certs were valid.