A common issue in the web is "accountability" -- whether or not a publisher is accountable for the work they present, and the means for tracking that accountability. This page is not about the legal or moral aspects of accountability, nor is it about enforced accountability by third parties; this page is about technical solutions for providing one's own accountability.
You are a publisher of a weblog. You stand by your work even as you mold and develop it. While most people trust your final work, others expect you to be accountable for all of your work. You choose to present the version history of your work, but since you control the version history as well as the work, there's still a question of accountability. As the publisher of both the work and the history, how can you still choose to guarantee accountability?
When thinking about solutions, most people's first thoughts go to signing a work (EntrySigning), but signing a work only guarantees the source of the work, not its content. The second thought is to put a timestamp in the work, and then sign that too, but the source still has control over the content. The correct solution is to have someone else sign the work with a timestamp in it.
Although it's entirely possible to have someone else timestamp an entire work, it turns out that that is not necessary. In the world at large it's considered a risk to provide confidential trade secret work to a third party to timestamp. It turns out that timestamping a cryptographic checksum of the work is all that's needed, and that's what they do.
RFC3161, Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) lays out all the technical details, but luckily folks have made it easy for us.
time.certum.pl also provides a simpler interface to requesting a timestamp, all one needs to do is POST or GET a form field 'sha1' to retrieve a timestamp:
GNU Textutils is one source of a 'sha1sum' command to generate the SHA1 checksums. The response is a binary file with MIME type 'application/timestamp-reply' which can simply be saved alongside the version of a work. The timestamp file is an ASN1-formatted file per RFC3161, but publishers themselves need not read or understand the file. Only readers who choose to authenticate the timestamp need to read the file (standalone tools to do so will surely be written).
The most difficult aspect of timestamping is figuring out what format to checksum and making that format available with each version. The checksum and timestamp need only be generated once, when publishing first occurs. Histories just keep the format and timestamp. If the publishing system stores "markup text" (either plain-text markup or a markup language), the checksum can be made on the text as long as the text and timestamps are made available. Others may choose to checksum the output format, using some form of "canonical" reading of the format (like Canonical XML).
See also TORSEC Time Stamp reference page (home of the Time Stamping Protocol spec, with lists of tools and providers).
Original author: KenMacLeod