Stamper Timestamping Service – Changes due to 2025 upgrades

Since Stamper was first setup in 1995, it has not had any significant software upgrades. It used PGP 2.6.2, which has for some time been rather out of date. It also operated by email only (originally having been on polled dialup), and nowadays HTTPS would be more ususal for a service of this sort. The intention of these upgrades is to put it onto a modern operating system, with a modern version of GnuPG, both of which can be maintained and updated on an ongoing basis.

There are no radical design changes. The service continues with the daily and weekly feeding back of signatures, and the publication of all signatures made. Specifically, it is a continuation of the existing service, and at the point of upgrade, the signing feedback chain and Stamper Id numbering will be maintained.

The specific changes comprise:-

• Signatures made with a modern version of GnuPG, and using modern keys. This requires the generation of new keys suitable for use with GnuPG 2.
• Addition of an HTTPS interface for timestamping.
• Addition of an RFC3161 timestamping authority via HTTPS, where the returned stamps are in turn timestamped by Stamper using GnuPG. The serial number of the RFC3161 timestamp matches the Stamper-ID of the GnuPG signature.
• Addition of an HTTPS interface to retrieve details of a specfic Stamper-ID.
• A Git repository containing all signatures and associated files, which is updated daily and with the commits being signed with Stamper's management key.
• For email timestamping, there will only be a single "mode" which will take the whole inbound message (including headers), sign it, and return it as an EML attachment together with the Stamper signature.
• Discontinuation of email "proof of posting" certificates, which are not really workable with modern email systems featuring SPF, DKIM and DMARC.
• Discontinuation of the email "list server" methods of accessing Stamper instructions and data.
• Discontinuation of the posting of weekly summaries to Usenet.
• A slight change to the email behaviour in certain uncommon situations, namely only if the email sender SMTP "envelope" address and the "From:" header address are different. Prior to the upgrade, the email was returned to the "From:" address, but following the upgrade, the "envelope" address will be used.