Time Stamping: Sometimes an extra step makes all the difference
For software developers Code Signing Certificates are a must. It's the difference between the code you're writing being seen as safe or not. Time Stamping is equally as important.
With an SSL Certificate, you make a new secure connection every time you visit a website. It occurs this way because it's feasible. However, with executables—it's not.
A programmer writes code, they compile it into an executable and they use a Code Signing Certificate to attach their identity. Then they upload it to a website and users download it. In turn, that executable sits on a user's computer until it's installed. That could be within minutes of downloading it or a year after the fact. They may keep it and later install it on another computer.
But if the Code Signing Certificate that was used to sign the executable has expired, the user will get an alarming warning. That's a pain and it could potentially dissuade the user from using the software.
The way to avoid this is via Time Stamping.
Think of Time Stamping as a way to permanently preserve the signature. When a programmer is compiling the code into the executable they have the option of adding a time stamp. This is not required, but there's really no downside to it—you should always time stamp your software.
This adds another step, albeit a worthwhile one, to the code signing process.
Before the Code Signing Certificate is used to sign the program, the software handling the signing will securely check for the current date and time. It does so by talking to a Time Stamping server via URL.
DigiCert's Time Stamping URL: http://timestamp.digicert.com
But, once the executable is Time Stamped, no matter when it's used, it will not get an "author unknown" message as long as the executable was downloaded within the certificate's lifespan.
So there you have it. Time Stamping is an extra step in the Code Signing process, but sometimes an extra step makes all the difference.