Timestamping and Longevity
Key pairs, as used for creating digital signatures, become less secure the older they are. The older they are, the more likely that the private key has been compromised. There is also more signed material with which to attack them and more time in which to execute the attack. Certificates are therefore assigned expiration dates to limit the lifespan of the keys they are associated with.
The expiration date doesn't apply to the time at which the signature is validated, but rather the time at which the signing occurs. So long as a signature is created while the certificate is valid, the resulting signature should not itself expire. Adobe AIR signing tools obtain a secure timestamp during the signing process. The timestamp, which itself contains yet another verifiable signature, proves the time at which the signature was created. Tools for creating AIR files won't permit signing with an expired certificate and, by default, won't permit signing if a secure timestamp cannot be created. Similarly, Adobe AIR installs an application only if its signature was created while the signing signature was valid.
Obtaining a secure timestamp requires contacting a timestamp server made available for this purpose. Adobe has partnered with Geotrust (www.geotrust.com) to make such a service freely available, and it is used by default by our tools.
If obtaining the timestamp fails then signing typically fails, but you can override this behavior and force signing to occur anyway. If you package using the adt command-line tool, you can also specify an alternate timestamp server using the -tsa <url> options. When encountering signatures without timestamps, however, Adobe AIR compares the current time—not the signing time—against the certificate expiration dates. If the certificate has expired, the AIR file will not be installable, even if it was signed while the certificate was still valid. So while this workflow may be useful, if you're unavoidably offline for a short period, you should also avoid ever releasing an application signed without a time-stamped signature.
Revocation Lists
Certificates are sometimes compromised. For example, they might be stolen or even issued to the wrong party. In these circumstances, the certification authority revokes the certificate by adding it to a revocation list. The revocation listed is hosted at a URL that was already embedded in the issued certificate. If you have a certificate, you already know where to go to check the correct revocation list.
Adobe AIR performs a revocation check when signing and when installing. When online, this generally prevents revoked certificates from being used. Certificate revocation lists cannot be checked directly when offline. Two steps are taken to reduce the chances of a revoked certificate being accepted merely because the user is offline while installing.
- If the developer is online while signing, the certificate revocation list for the signing certificate is embedded in the AIR file. In nearly all, cases this is sufficient to establish that a certificate was not revoked at the time it was signed, even if the installation happens offline.
- Adobe AIR caches revocation lists. When off-line, it consults this cache for the CRL required. Because most commercial signing certificates come from a small number of vendors with a small number of revocation lists, there is a reasonably good probability that the cache contains useful data.
Revocation, like signing, is also impacted by time. If a timestamp is available, then the revocation list is checked to see if the certificate was revoked at the time signing occurred. If no timestamp is available, the revocation check is applied to the time at which the application is being installed.
Finally, Adobe AIR's revocation checks are best-effort based. If no relevant CRL can be obtained—whether through the cache, AIR file, or CRL server—the installation is allowed to proceed.
