With recent code-signature requirements for Rich Internet Applications, I have received a few good questions from different types of developers
Code signatures allow people who will receive and use your code to determine that you are, in fact, the publisher and that no one else has intentionally or accidentally modified your deliverable. Code signatures protect against these modifications within your supply chain, when moving across a network, or when appearing through 3rd party distribution channels. Code signatures offer a level of repudiation: even though an imposter tries to look like your app, both you and your customers can prove that it isn’t.
There are two concepts for this level of trust:
The way that this information is provided and checked is through industry standard Certificates, which tie together information about the signers (their identity) with the ability to mathematically verify it (through a key).
For a description on why code signatures are taking a more prominent role within the Java Platform, please see our previous entry, Code Signing – Understanding Who and When.
Trusted Timestamping, introduced in Java 5 (2004), allows your customers to validate your signature even after the certificate has expired. When you sign a JAR file, the Timestamp Authority uses their clock to act as a notary and cryptographically write the date and time into your file.
Without this timestamp, users would only be able to validate your signature based on their current date and time. This could be problematic for long-running or embedded systems because the standard X.509 Certificates contain a NotAfter date that typically ranges from one to four years.
You interact with timestamp authorities when signing code with jarsigner’s TSA argument:
jarsigner -tsa http://tsa.starfieldtech.com …
When your signed file provides a timestamp, Java is able to use that information within the PKIXParameters and determine:
If the answer to all questions is yes, then the signature is deemed valid even if the certificate has expired. Therefore, signed code on embedded devices will continue to operate beyond the Certificate’s lifetime.
Certificate revocation may affect the ability to trust a timestamped artifact even if the timestamp occurred before the revocation. Some Certificate Authorities do not currently allow back-dating of revocations, which call to question which happened first: the revocation or the timestamp. Java systems may ignore the timestamp when they identify that the code-signing certificate has been revoked.
Several trusted timestamp authorities are listed in the previous post, “Code signing: Understanding who and when.”
Part of the acceptance criteria for being included in Java’s root certificate authority program is allowing back-dating of certificate revocation in the event that a private key is lost or stolen and continuing to publish revocation information even after a Certificate’s public expiration.