Sources

Every source below was fetched and read at the document itself on 2026-08-14, not quoted from memory or from a search snippet. Where the document’s status differs from how such things are usually described, the difference is recorded — one such difference required a correction to the essay before publication.

Primary sources

RFC 8032 — Edwards-Curve Digital Signature Algorithm (EdDSA)

• URL: https://www.rfc-editor.org/rfc/rfc8032 — fetched, HTTP 200
• Stream / status: Internet Research Task Force (IRTF), Category: Informational, ISSN 2070-1721
• Authors: S. Josefsson (SJD AB), I. Liusvaara (Independent)
• Date: January 2017
• Used for: the description of Ed25519 as the signature scheme
• ⚠️ Correction made because of this check. A draft of the essay described all three components as “a published standard”. RFC 8032 is IRTF Informational, not IETF standards-track. The essay now says “publicly specified, with implementations nobody here controls”, and names the status where it cites the document. A specification with wide independent implementation is a different thing from a standard, and the difference is exactly the sort a technical reader checks.

RFC 3161 — Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)

• URL: https://www.rfc-editor.org/rfc/rfc3161 — fetched, HTTP 200
• Stream / status: Network Working Group, Category: Standards Track
• Authors: C. Adams (Entrust), P. Cain (BBN), D. Pinkas (Integris), R. Zuccherato (Entrust)
• Date: August 2001
• Used for: the timestamp mechanism, and the claim that the authority receives only a fingerprint
• ⚠️ Correction made because of a review. An earlier version of this page listed three of the four authors, omitting R. Zuccherato. On a page whose opening sentence is “fetched and read at the document itself”, the author list is the one line that tests that sentence — and it failed. The masthead was re-read byte-for-byte to correct it.

Regulation (EU) No 910/2014 (eIDAS)

• URL: https://eur-lex.europa.eu/eli/reg/2014/910/oj — fetched, HTTP 200
• Used for: Article 41 (legal effect of electronic time stamps — a qualified time stamp enjoys a presumption of accuracy)
• ⚠️ Correction made because of a review. Earlier drafts also cited Article 14 as authority that the Article 41 presumption “does not extend to New Zealand”. Article 14 is titled International aspects and runs INBOUND — recognition of third-country trust services WITHIN the Union, where an Article 218 TFEU agreement exists. It says nothing about an EU presumption reaching outward. The citation was dropped rather than replaced: the package now says only that these tokens are not qualified, and that what a New Zealand tribunal would make of one is a question for a lawyer there
• ⚠️ Scope of the claim. The essay, brief, Q&A and glossary all state that this is a description of the instruments and not legal advice. No opinion is offered on how a New Zealand tribunal would treat a non-qualified token. That question belongs to the organisation and its own advisers.

SHA-256

Named but not cited as a document. It is specified in NIST FIPS 180-4 (Secure Hash Standard). The essay makes no claim about the publication beyond using the algorithm’s name, so no citation is offered — naming an algorithm is not the same as citing a specification, and a reference added for appearance would be the thing this page exists to prevent.

What is NOT cited, and why

No academic literature. There is a substantial scholarly literature on digital evidence, trusted timestamping and the legal status of electronic records. None of it is cited here, because none of it was read for this piece. Citing work one has not read — even work that certainly exists and probably supports the point — is fabrication with a bibliography.

No case law. The essay makes no claim about how any tribunal has treated a timestamp. It says what the Regulation says about qualified timestamps and stops.

No vendor comparisons. The essay says “most products in this space stop at the first and describe it as though it were the third”. That is an assertion about a market and it is deliberately unattributed, because attributing it would require naming products and a survey that was not conducted. A reader is entitled to treat it as the author’s impression rather than a finding, and it is phrased so it reads that way.

Internal source of the mechanism description

The description of what the system does — sign at save, refuse rather than store unsigned, send only the fingerprint, export a bundle with canonical bytes and verification commands — is taken from the implementation and from the verification document the export itself generates, not from marketing copy or a specification of intent. The relevant claims were each traced to the code that performs them before publication.

Method note

The URL checks above are one method — an HTTP fetch confirming the document resolves and reading its header block for title, stream and status. That is sufficient for “this document exists and is what I say it is”. It is not sufficient for a claim about what a document argues, which would need the relevant section read in full. No such claim is made in this package: every citation here is to a document’s identity and to the specific article or algorithm named, both of which the header and the article text establish directly.