What a qualified timestamp is: RFC 3161 and eIDAS article 42

A timestamp token is a signed statement from a timestamp authority: the hash in this token existed at this time. RFC 3161 calls it a proof-of-existence, indicating that a datum existed before a particular time. Nothing in the token announces who the data belongs to — by design, the authority signs only the digest it received.

The qualified electronic time stamp, defined in eIDAS article 3(34), is a timestamp meeting article 42; under article 41(2) it enjoys the presumption of the accuracy of the date and time it indicates and the integrity of the data to which date and time are bound. That presumption is what raises it above an unqualified stamp in a legal argument.

policy: an object identifier stating the conditions under which the token may be used — also how a later auditor figures out which policy applied. Yes, that is policy-driven; the token records which one.

messageImprint: the hash the client submitted, and the response token MUST carry the same value as the request. This is what makes the binding mechanical: the token does not describe the data, it is cryptographically tied to exactly the data you sent.

serialNumber: an integer unique to the issuing authority — RFC 3161 requires users to be ready to accommodate integers up to 160 bits, and that the authority's name plus this serial identify a unique token. genTime: the token's creation time, expressed in UTC.

nonce: if the client sends one, the server MUST return it unchanged in the response — the only optional field RFC 3161 requires implementations to support. It ties the response to this exact request. tsa: the authority's name, carried optionally.

The token contains exactly one signature: the TSA's. The certificate identifier of the TSA's own certificate (ESSCertID) must ride inside the token's signing attributes — a verifier can identify which key signed the token without guessing.

The imprint duty runs in one direction: whichever bytes were submitted get the token, and the response must echo them. A token over a different digest fails the check on its face — that is how the authority cannot quietly bind something else.

Article 42(1) sets three requirements. First, the stamp must bind date and time to the data so that undetectable change is reasonably precluded — that is the integrity half of the article 26(d) standard, applied to the stamping of it. Second, it must be based on an accurate time source linked to Coordinated Universal Time. Third, it must be signed or sealed by the qualified trust service provider.

Article 42(2) adds the standards presumption: where the binding and the time source follow standards referenced in a Commission implementing act, compliance with those requirements is presumed. Article 41(3) completes the frame: a qualified stamp issued in one member state is recognised as qualified in every member state.

It does not sign. No one agreed to anything by possessing a hash of their data — authorship and consent live in the signature and the ceremony evidence, not in the stamp.

It does not tell the future. A stamp certifies what existed before its genTime; it says nothing about events after it. Proving content is the same years later is the job of the signature level (B-LT and B-LTA), not of the stamp alone.

It is not a notarisation. No stamp certifies that the data is truthful; it certifies existence before a time. Whether the content is right is a matter for the document and its readers, not the authority.