timestamping : Java Glossary

In general, timestamping is just marking something with a date and time. You can do that easily in Java with java.lang.System.currentTimeMillis() Such timestamps can easily be forged. If you wanted to timestamp a jar proving that its contents existed at such as such a time, you would create a digest of the jar (e.g. by signing it) then send the digest to a signing authority who would add a timestamp to it and digitally sign it with their private key and return it to you to prove the jar existed in that state at the timestamped time.

Java jarsigner.exe has a feature to make such a request right while signing to get an accurate timestamp. You use the -tsa url or -tsacert alias to to connect to a timestamp service. The url is the url of a RFC 3161 timestamp server and alias is the alias/id of a certificate in .keystore not .cacert as you would expect. Both your code signing cert and the root certificate for the time stamp service must live in your .keystore. Oracle delivers the certificates in the .cacerts file. I am quite baffled how the -tsacert method could possibly work. How does it find the server? It does not appear to be embedded in the cert. Yet it must be. In ANT (A Neat Tool), the command is called signjar with parameters tsaurl and tsacert.

You could do something similar with a backup CD (Compact Disc) to prove you had composed all those works by the backup date, which might come in handy later in a patent or copyright lawsuit.

You send the Certificate Authority a *.tsq file, mime type application/timestamp-query and get back a *.tsr file application/timestamp-reply. The protocol could not be simpler. You send a file using standard HTTP (Hypertext Transfer Protocol). You get a file. The DER-base64 formats of the files are defined by  RFC 3161 which is part of X.509. As usual the RFC (Request For Comment) is written in Greek. I suggest snooping on a timestamping conversation with a protocol sniffer to understand better how it works.

RFC 3161 covers timestamping signatures. RFC 3628 covers timestamping management. RFC 5126 covers long term electronic signatures.

If you don’t timestamp when you sign your jars, you must re-sign your code after the expiration of the certificate. Timestamping also gets rid of jar.exe’s verbose warning message.

TSA (Time Stamping Authority) Signing

Gotchas

There is no easy way to tell if a jar is timestamped or what the timestamp is.

jarsigner.exe -verify -verbose -certs

should tell you some basic facts such as

• What certificate signed the jar.
• What service timestamped the jar and when.

Under the Hood

How do jar signing and timestamping work?

jar.exe prepares a digest of each element in the jar and puts in MANIFEST.MF. jarsigner.exe signs each element with your code signing certificate (i.e. encrypts each digest with your code-signing private key) and puts them in XXX.SF. It then prepares a digest of all the digests (I don’t know if it uses unsigned or signed versions) and digitally signs that and puts it in XXX.SF. Then it sends that super digest to the time stamping service. The timestamping service appends the time and digitally signs it with their private key and immediately sends you back a certificate. In a way I don’t understand, jarsigner.exe includes the certificate in the jar.

Jarsigner also puts the public key for the code signing certificate and the public key for the time stamping service in XXX.DSA along with the signature for the file as a whole.