Add RFC 3161 Trusted Timestamps (*.tsr) for all primary build artifacts

[ChrissW-R1]

To improve supply chain integrity and provide a verifiable proof of existence for released artifacts, we should generate RFC 3161 trusted timestamps for all primary build outputs during the Maven build process.

Scope

Timestamp generation should apply to all primary artifacts, including:

• *.pom
• *.jar (including -sources, -javadoc and -jar-with-dependencies)
• *.zip
• *.exe (if applicable)

The following should be excluded:

• *.asc (GPG signatures)
• checksum files (*.md5, *.sha1, *.sha256, *.sha512)
• attestations (e.g. *.intoto.jsonl)
• already generated *.tsr files

Proposed approach

1. After packaging, compute a digest (e.g. SHA-256) for each primary artifact
2. Send the digest to a RFC 3161 Time Stamping Authority (TSA)
3. Receive the signed timestamp response (TimeStampToken)
4. Store the response as a sidecar file: artifact.ext → artifact.ext.tsr
5. Attach each *.tsr file as a Maven artifact
6. Let the existing GPG signing step sign all attached artifacts (including *.tsr)
7. Let the publishing process generate checksums for all artifacts (including *.tsr)

Result

For each released artifact, we will have:

• original artifact (e.g. .jar, .pom, .zip)
• detached GPG signature (.asc)
• file hashes (.md5, .sha1, .sha256, .sha512)
• trusted timestamp (.tsr)
• GPG signature of timestamp (.tsr.asc)
• hashes of timestamp (.tsr.md5, .tsr.sha1, .tsr.sha256, .tsr.sha512)

This ensures:

• integrity (via GPG)
• verifiable existence time (via TSA)
• long-term validation independent of key expiration

Implementation notes

• Use a pure Java approach (e.g. Bouncy Castle + GMavenPlus) to avoid OpenSSL dependency
• Integrate timestamp generation in the verify phase before GPG signing
• Attach *.tsr via Maven artifact attachment mechanism