Who States the Date of a Record? RFC 3161 Timestamping

There is a date on an evidence file. Who is stating that date? The answer is usually the clock of the server that keeps the record, and that is the weakest link an auditor is expected to accept. This article is about why the question matters and how RFC 3161 timestamping answers it.

A Server Clock Is Not Evidence

A signature shows where a file came from. It does not show when. The date field inside the file is covered by the signature too, so it cannot be changed afterwards, but the value written into it was read from the server clock at the moment of production.

Someone who can change the server clock can produce a backdated evidence file. The signature verifies, the digests match, every check passes. Only the date is false. There is no way for an auditor to detect this from inside the package.

In practice this surfaces in two places. First, the temptation to produce evidence after the fact: if an action was taken outside the record, creating an entry later and backdating it is an attractive shortcut. Second, arguments about which regulatory period an event falls into: the date can change the scope of a sanction.

How RFC 3161 Works

RFC 3161 is a long standing timestamping standard and the flow is only three steps.

1. A SHA-256 digest is computed over the manifest of the evidence file.
2. That digest is sent to a timestamp authority. The authority signs the digest together with its own time and returns the result.
3. The response is placed inside the evidence package as a file.

The package then carries this: "this content already existed on this date, and the party saying so is not the organisation but a third one." The auditor verifies that file with the authority's public key and confirms the date without ever consulting the organisation's clock.

What Actually Leaves the Network

This is the first question a security team asks, and the answer is clear: only a digest. The evidence file itself, script text, query results and personal data never go to the authority under any circumstances.

A digest is one way: the content cannot be reconstructed from it. The only thing the authority learns is that you had something stamped at a given moment. It does not learn what.

It is still an outbound call, and in an installation that claims to need no internet access that has to be known. The right design is a single master switch, with no network call at all when it is off. There should be no half open state.

Which Authority: External, Internal, Free

There are three options, and the choice is an organisational decision rather than a technical one.

• A contracted external authority. The right choice for production. It is a contracted service with commitments on continuity and speed, and its stamp stands stronger in a legal dispute.
• An internal authority. For organisations that will not leave the network. Independence is weaker because the authority is the organisation too, but the clock is at least separated from the application server, and that is a gain.
• A free public authority. Useful for showing an installation works end to end on day one. It makes no commitment and ties your evidence chain to the continuity of an outside service; it should not be left in place in production.

The configuration that ships with SQL Change Guard has the feature on and points at a free public authority. That is a deliberate installation choice: a stamped evidence package can be produced on day one. Moving to production means repointing that address at the organisation's own authority, or switching the feature off.

When the Authority Cannot Be Reached

The most critical design decision sits here. There are two options: the work stops, or it continues without a stamp.

The right answer is the second. Timestamping is a layer that strengthens evidence, not the evidence itself. Failing to produce an evidence file because an outside service is unreachable would tie the organisation's audit capability to the availability of a third party.

But the gap must not be hidden. If no stamp was obtained there is no stamp file in the package, the stamp field in the anchor envelope stays empty and a warning is written to the log. When the auditor picks up that package they can see the date is the organisation's own assertion. A package produced without a stamp that does not say so is worse than one produced without a stamp.

Should You Switch It On

The decision depends on your threat model. In these three situations timestamping should be on.

• If the evidence may be used in a legal dispute. Once the date is contested, a claim resting on the organisation's own clock is weak.
• If a regulatory framework asks you to demonstrate when records were produced.
• If the authority to change the server clock sits in the same team as the authority to produce evidence. This is a segregation of duties overlap most organisations miss.

If none of those apply and the organisation runs on a fully closed network, switching the feature off is a defensible decision. What matters is that the decision is deliberate and stated to the auditor. An auditor who knowingly accepts that it is off is far better than one who assumed it was on and finds out later.

Frequently Asked Questions

Is evidence invalid without a timestamp?

No. An unstamped package still shows that its content has not changed and where it came from. All a stamp adds is moving the date out of the organisation's own assertion. Anchors delivered outside on a schedule provide separate support for the date; the two do not replace each other, but if one is missing the other partly covers the gap.

We run on a closed network, can we still use timestamping?

You can run an internal timestamp authority, and from the client's point of view nothing differs; only the address changes. Independence is not as strong as with an external authority, but separating the clock from the application server is still a real gain: the team producing evidence is no longer the system stating the time.

If the authority shuts down, do old stamps become invalid?

Verification does not require the authority to be online; the signature inside the stamp is checked against the authority's certificate. That certificate and its chain do need to have been archived, though. So the authority's certificate should be kept as part of the evidence archive. This is one of the reasons free public authorities are not recommended for production.

Is every record stamped separately?

No, and it would be expensive. Stamps are taken at the points the records hang from: the daily anchor and the manifest of an exported evidence file. Because of the chain structure, stamping a single point shows that every record up to that point already existed on that date.