srakatrading.blogg.se

1. #Comodo and other free digital signature archive#
2. #Comodo and other free digital signature software#
3. #Comodo and other free digital signature code#
4. #Comodo and other free digital signature download#

You validate the global time-stamp on-line.Now the signature validation process is the following:

#Comodo and other free digital signature archive#

This time-stamp is called archive time-stamp And after having fetched all these objects, you must put a time-stamp on it. This is not an endless process since you are going to eventually reach one or several trustfully root CA but it may be quite complex (Note that a good X.509 validation algorithm should output all these items along with the certificate validity status). It includes all intermediate CA certificates and CRLs.

#Comodo and other free digital signature download#

being able to validate the certificate without having to download any additional object). Some signature standards (like CAdES) have proposed a better solution: along with the signature time-stamp, you should collect every items required to validate the signature off-line (i.e. So, should we also get the CRL which proves that the signature time-stamp has been signed by a valid certificate? Short answer: Yes, things seems to get more complicated.

It will prove that the certificate was not revoked when the signature was produced.īut time-stamp tokens and CRL are also signed objects. But it does not solve the second problem: what if the certificate has been revoked? Second solutionĪlong with the signature time-stamp you can also attach a copy of the CRL (or an OCSP response) to the signature.

It prooves that the signature has been computed before the expiration of the certificate. This time-stamp provides a proof that the signature existed at a given date. This time-stamp is called signature time-stamp.

#Comodo and other free digital signature software#

First solutionĪdding a time-stamp to the software signature. You can also note that, even if the certificate has not been revoked, a signature done after the certificate expiration should not be considered valid. Your scenario is correct: if you do not have a proof of the date/time of the signature you cannot be sure it has not been done after the revocation and expiration of the certificate.

#Comodo and other free digital signature code#

So to answer your question - yes, the malware can run again if the CRL for code signing certs isn't managed properly.ĭealing with digital signatures is more complex than we can suppose at first sight. For this reason, administrators should dedicate a CA for the sole purpose of handling code-signing production certificates. However, the CA does not distinguish between code-signing certificates and other certificates. Microsoft Certificate Server enables administrators to configure the CA to keep all revoked certificates in the CRL. This paper recommends always revoking compromised certificates that were used to sign publicly released software and maintaining these entries in the CRL indefinitely. As a result, revoked code-signing certificates should not be removed from the CRL. However, timestamping allows Authenticode signatures to remain valid indefinitely. This means that when a revoked certificate expires, it is eventually removed from the CRL. In most PKI deployments, only certificates that have not yet expired are placed on the CRL. Thus the revocation status of code signing certs must be tracked forever.įrom Microsoft's Code Signing Best Practices document: If they can remain undiscovered past cert expiry, then the cert won't get added to the CRL even on discovery, and their malware will never get blocked. An alternative scenario: attacker signs their malware before cert expiry. This is why Microsoft recommends to never remove expired code signing certs from CRLs. Starting in J2SE 5.0, jarsigner can generate signatures that include a timestamp, thus enabling systems/deployer (including Java Plug-in) to check whether the JAR file was signed while the signing certificate was still valid." Is this possible, or am I misunderstanding something about the way code signing works? Am I making an assumption in step 4? Sources such as the Java documentation seem to imply that this is how it works - " Because signing certificates typically expire annually, this caused customers significant problems by forcing them to re-sign deployed JAR files annually. Malware will be prevented from running by systems that check CRLs.ģ1st December 2014 - certificate expires and is removed from CRLs as suggested by this answer - "certificates which are expired are removed from the CRL".ġst January 2015 - malware can now be run again, as the signing timestamp indicates that the certificate was valid at the time of signing, and this is what systems use when determining whether to trust a signature. 1st December 2014 - a certificate is stolen and used to sign malware with timestamp.ġ5th December 2014 - the certificate is revoked.