Inclusion Proof for the Public Extract

Every other document in this extract asks to be believed. This one does not. It publishes a single hash over the bytes of the whole public extract, and the means to check any one document against it. The check takes nothing on trust except the root itself; what that exception costs is the first entry in section 5.

NC-TN-0147 sets out what hash linkage establishes about order and what it does not. This instrument is the narrower claim in that note made checkable from outside: that a given sequence of bytes was one of the leaves under a stated root at a stated date.

The leaves are the documents of the public extract, in the order they appear in the sitemap, hashed as the bytes served rather than as text. The hash is SHA3-256 (FIPS 202). Two one-byte prefixes separate the domains, following RFC 6962 section 2.1:

Without the prefixes a leaf could be presented as an interior node, and a proof of inclusion for a document nobody wrote could be assembled from a document somebody did. An odd node at any level is promoted to the next level unhashed rather than paired with itself; the leaf count is therefore part of the proof, because the length of an audit path does not by itself fix the shape of the tree.

RFC 6962 splits a level at the largest power of two below the leaf count, which keeps successive roots consistent with one another. This construction promotes instead. It is easier to check by hand and it is what the verifier implements. Consistency proofs between roots are not offered here, so nothing depends on the difference.

This page is a sitemap entry and is deliberately not a leaf. A document cannot carry a commitment to its own bytes: writing the root into this page changes this page, which changes the root. The verifier is told which route to exclude, and will not silently agree with itself about it.

One leaf is published in full, so that the instrument can be exercised without fetching the whole extract. Fetch the document yourself, from whatever you trust to fetch it.

The verifier is verify.py. It is Python 3.6 or later, standard library only, and makes no network request of its own. It holds no root, no hash and no path: everything it compares against is given to it on the command line, from the table above. Read it before you run it.

To check the root itself rather than one path through it, fetch every URL in sitemap.xml into one directory, named for its route with .html appended and the front page as index.html, and run verify.py --all against it. That rebuilds the tree from the documents in your hands and compares the result to the root above. It is the stronger check, and it does not require this page to have told the truth about the path.

A pass means those bytes were a leaf under that root. The list of things it does not mean is longer, and none of it is hedging:

• Not identity across parties. Nothing here shows that the root you hold is the root anyone else was given. A root published by the party that computed it, on the origin that serves the leaves, is a checksum with a letterhead. Independent identity requires a second party who saw the same root and has no interest in it, and there is none.
• Not time. The effective date is asserted by this office, not witnessed. Nothing in the construction prevents the root from having been computed later and dated earlier.
• Not the witness chain. This root is over the served documents. It is not over the append-only chain those documents describe, it is not linked to it, and a proof here is not a proof there.
• Not authorship or authority. There is no signature over this root, composite or otherwise, and so nothing binds it to the office named on this page. NC-TN-0203 §6.6 makes the same point about the chain: a commitment fixes content and order, and says nothing about who produced the node carrying it.
• Not correctness. A document that is wrong hashes exactly as well as one that is right. Inclusion is a claim about bytes, not about what they assert.
• Not completeness. Three holdings are served but kept out of the sitemap, so they are not leaves and this root says nothing about them either way. Their absence from it is not evidence about them.

A root commits to bytes, so any change to any served document invalidates it. When that happens the root is recut and this revision is superseded under NC-REC-0003, with the prior root and its effective date retained in the register. A root that quietly changed while keeping its date would be worse than no root, and the register is what stops that.