provared 0.4.0 → 0.6.0

package/spec/provared-format.md

@@ -87,7 +87,7 @@ method was used. Because it is part of the signed bytes, a signature made
 for one kind of record can never pass as another kind.
 
 In this draft the protected header, once decoded, MUST be **exactly** one
-of these twenty-two texts, byte for byte. A checker compares the bytes and does
+of these twenty-six texts, byte for byte. A checker compares the bytes and does
 not interpret anything else.
 
 | Record | Method | Protected header |
@@ -114,6 +114,10 @@ not interpret anything else.
 | Withdrawal | ML-DSA-87 | `{"typ":"vnd.provared.withdrawal.v0+json","alg":"ML-DSA-87"}` |
 | Pass | Ed25519 | `{"typ":"vnd.provared.pass.v0+json","alg":"Ed25519"}` |
 | Pass | ML-DSA-87 | `{"typ":"vnd.provared.pass.v0+json","alg":"ML-DSA-87"}` |
+| Denial | Ed25519 | `{"typ":"vnd.provared.denial.v0+json","alg":"Ed25519"}` |
+| Denial | ML-DSA-87 | `{"typ":"vnd.provared.denial.v0+json","alg":"ML-DSA-87"}` |
+| Witness statement | Ed25519 | `{"typ":"vnd.provared.witness.v0+json","alg":"Ed25519"}` |
+| Witness statement | ML-DSA-87 | `{"typ":"vnd.provared.witness.v0+json","alg":"ML-DSA-87"}` |
 
 `typ` is the media type of the record (RFC 7515, section 4.1.9), used as
 explicit typing (RFC 8725, section 3.11). `alg` names the signing method
@@ -204,7 +208,25 @@ written in only one way. RFC 8032 does not say to refuse such keys, and
 libraries differ in whether they do; a checker refuses them itself
 (`bad-key`), so that two checkers cannot disagree. For the same reason,
 an Ed25519 signature whose first 32 bytes (the point R) are such a point,
-or hold a y not less than p, is invalid, whatever the key.
+or hold a y not less than p, is invalid, whatever the key; and so is one
+whose last 32 bytes, read as a little-endian number S, are not less than
+L = 2^252 + 27742317777372353535851937790883648493, the order of the
+base point. RFC 8032, section 5.1.7, requires the check of S; libraries
+differ in whether they make it, so a checker makes it itself. A key of
+mixed order (a point of large order with a small-order part) is not
+refused, and a signature under it is checked with the equation
+S·B = R + k·A, without the cofactor, k being the SHA-512 hash of R, A and
+the message, read as a little-endian number and reduced modulo L before
+the multiplication. The cases of the paper "Taming the many EdDSAs"
+(Chalkias, Garillot, Kondi and Nikolaenko, 2020) are in the shared test
+files (`test-vectors/ed25519-signatures.json`), each with the answer
+these rules give.
+
+An ES256 key MUST be a point on the curve P-256: each half a number less
+than the prime of the curve, and the two satisfying the curve's equation.
+A checker refuses any other (`bad-key`) before it tries any signature
+under it: such a key can check no signature, and libraries report it in
+different ways.
 
 A key is named for people by its **thumbprint**: the JSON Web Key
 Thumbprint with SHA-256 (RFC 7638; for ML-DSA keys, RFC 9964 section 6).
@@ -440,7 +462,10 @@ checker keeps no state.
 | `pass` | For a helper agent: the pass it acts under. Optional | The fingerprint of the pass (section 25) |
 | `when` | When it was done | A time |
 
-A stub holds fingerprints of documents, never the documents.
+A stub holds fingerprints of documents, never the documents. A document
+`name` is a label chosen by whoever wrote the stub, except that names
+that begin `provared.` are reserved (section 27). The same label MAY
+appear more than once; section 27 says which reserved names may.
 
 ### 5.2 Signing and checking
 
@@ -532,18 +557,24 @@ in place of the narrowed content), and is one of:
 - `{"refusal": refusal record}`
 - `{"terms": terms record}`
 - `{"seal": seal record}`, which MAY also hold `"stamps": list of 1 to 4
-  time-stamps` (section 21)
+  time-stamps` (section 21) and `"witnesses": list of 1 to 4 witness
+  statements` (section 29)
 - `{"cancellation": cancellation record}`, which MAY also hold `"stamps"`
   (section 22)
 - `{"acknowledgement": acknowledgement record}` (section 26)
 - `{"vouching": vouching record}` and `{"withdrawal": withdrawal record}`
   (section 23)
 - `{"pass": pass record}` (section 25)
+- `{"denial": denial record}` (section 28)
 
 A slip MUST come before the entries that rely on it, and a set of terms
 before the stubs that rely on it. A book MUST NOT hold
 the same slip twice, nor more than 100,000 entries. A line MUST NOT be
-longer than 131,072 bytes.
+longer than 131,072 bytes. Those two limits together allow a book of
+about 13 gigabytes, so a checker SHOULD bound the total size of a book it
+accepts (`too-large`), and MAY stop at the first problem it finds. This
+library takes a book as one text, so it can check no book larger than one
+text the device can hold.
 
 ## 10. The tree and the top fingerprint
 
@@ -583,7 +614,7 @@ of RFC 6962, section 2.1.1).
 ```
 
 A Show MAY also hold `"seal"`: an entry of the form `{"seal": seal
-record}`, with or without `"stamps"`. The Show is then of the book as it
+record}`, with or without `"stamps"` and `"witnesses"` (section 29). The Show is then of the book as it
 stood when that seal was made: the seal's `size` and `root` MUST equal the
 Show's (`seal-mismatch`), and a checker checks the seal and its
 time-stamps as section 21 sets out. Its `id` MUST NOT be that of a
@@ -622,6 +653,11 @@ block time-stamp where the whole book sets that time-stamp aside and
 passes. The last two need a block that states a time far behind the
 true time.
 
+A checker does not use seals held elsewhere (section 21.5) with a Show,
+and MUST say so where any are handed over: single pages cannot show what
+the book holds at the place a seal states, nor that the book goes on to
+it.
+
 Nothing fixes the time-stamps beside the seal that comes with a Show.
 They stand outside the tree and outside the seal's signatures, so
 whoever hands the Show over can put a later time-stamp in the place of
@@ -633,7 +669,7 @@ the seal's own date (section 21.1, rule 4).
 
 | Missing | What follows |
 |---|---|
-| A public place where seals are kept | The last seal of a book, with everything after it, can be removed unnoticed, unless someone else holds a copy of that seal or of its top fingerprint and number of entries |
+| A public place where seals are kept, which gathers the seals of many books and proves it dropped none | The last seal of a book, with everything after it, can be removed unnoticed, unless someone else holds a copy of that seal, and hands it to the checker (section 21.5), or holds its top fingerprint and number of entries. A witness (section 29) holds the latest seal it signed for, and can be asked for it; nothing obliges a recorder to show its seals to a witness |
 | A quantum-safe time-stamp | Time-stamp services sign with methods of today's kind |
 | Covered fields outside a slip's names and purpose | Every other field of an entry is visible to whoever holds it |
 | A compact binary form | Records are JSON text only |
@@ -645,6 +681,9 @@ the seal's own date (section 21.1, rule 4).
 - A one-sided stub proves what the agent's side said, not what the other
   side did.
 - A refusal proves what the service's side said, not what the agent did.
+- A denial proves what the agent's side said it did not do, and why. It
+  does not prove that the action was not taken some other way, and an
+  agent that writes no denial leaves no trace of the refusal.
 - A rule of conduct in a slip, such as "never claim to be a human being",
   is the person's signed instruction. No check can show that the agent
   kept it.
@@ -658,6 +697,16 @@ the seal's own date (section 21.1, rule 4).
   that the organisation checked well.
 - The fingerprints of an agent's software in a slip are a statement of
   what the person approved, not proof of what ran.
+- A reserved identifier that binds a stub to another system's own
+  record of the call (section 27) shows that the two records speak of
+  one call, not that the call did what either says. A matching
+  fingerprint of a request, an answer, arguments or an error shows only
+  that the content matches, not that it was the same call.
+- A witness statement (section 29) shows that a witness saw a seal, by
+  the time it states, and undertook to sign for no seal of that book that
+  does not extend it. It does not show that the entries are true, when
+  the seal was made, or anything of a book, or the end of one, that was
+  never shown to the witness.
 
 ## 14. Standards used
 
@@ -674,11 +723,13 @@ the seal's own date (section 21.1, rule 4).
 | FIPS 186-5; RFC 7518; RFC 8017 | The signing methods passkeys use (ES256, RS256) |
 | RFC 4648, section 5 | Base64url |
 | RFC 3339 | Times |
-| RFC 6962, section 2.1; RFC 9162, section 2.1.3.2 | The tree and its proofs |
+| RFC 6962, section 2.1; RFC 9162, sections 2.1.3.2 and 2.1.4 | The tree, the proof that one entry is in it, and the proof that one tree extends another (section 29.1) |
 | FIPS 205 | SLH-DSA-SHA2-256s, the third signature on a seal |
-| RFC 3161; RFC 5652; RFC 5280; ITU-T X.690 | Time-stamps: the statement, its signed wrapper, the certificate, and the byte layout (DER) |
+| RFC 3161; RFC 5652; RFC 5035; RFC 5280; RFC 8419, section 3.1; ITU-T X.690 | Time-stamps: the statement, its signed wrapper, how it names the certificate that signed, the certificate, Ed25519 with SHA-512 in a time-stamp, and the byte layout (DER) |
 | The OpenTimestamps proof file, version 1 (an open format; not the work of a standards body) | Block time-stamps: the steps from a fingerprint to the Merkle root of a block |
 | RFC 9901 (Selective Disclosure for JSON Web Tokens) | Covered fields |
+| RFC 9421 (HTTP Message Signatures), section 2.5, only its way of writing a message as text; RFC 9530 (Digest Fields); RFC 9110, section 5.6.2 | The texts that the reserved document names `provared.http-request` and `provared.http-response` stand for (section 27). Nothing is signed with RFC 9421 |
+| W3C Trace Context (a W3C Recommendation) | The trace-id that `provared.trace-id` stands for (section 27) |
 
 ## 15. Choices that go beyond the standards
 
@@ -735,6 +786,29 @@ is frozen.
     pass.
 18. The acknowledgement of section 26 and its label
     `vnd.provared.acknowledgement.v0+json`.
+19. The reserved document names of section 27, and the exact texts their
+    fingerprints are made from: an HTTP address taken exactly as it was
+    sent, never rewritten; a body that is present but empty given a
+    Content-Digest, and an absent body none; no header covered; SHA-256
+    only; only the three identifiers may be named more than once; the
+    form of a trace-id not checked.
+20. Seals held elsewhere, section 21.5: at most 64; compared with the
+    book by the seal's content, its signatures and time-stamps not;
+    counted only for a recorder the person named, and on a device
+    without SLH-DSA on its first two signatures; its time-stamps not used
+    for the entries of the book.
+21. The rules of section 3.8 that go beyond their standards: an Ed25519
+    key of small order, or written in more than one way, is refused as a
+    key, and a signature whose R is such a point is invalid under any key
+    (RFC 8032 leaves both to the implementation); an ES256 key that is
+    not a point on its curve is refused as a key. The check of S against
+    L restates RFC 8032, section 5.1.7, and is made by the checker
+    itself, whatever the library beneath it does.
+22. Where a time-stamp names the certificate that signed it in both
+    forms of RFC 5035 (section 21.2, item 3), the newer form names it
+    and the older is not compared with it. RFC 5035, section 7, lets a
+    reader refuse a time-stamp whose two forms disagree, and leaves the
+    choice to the reader.
 
 ## 16. The shared list: actions, kinds of action, rules of conduct
 
@@ -956,7 +1030,9 @@ record, with its approval and a countersignature, could be longer than a
 line of a book may be (section 9) is not allowed either (`too-large`).
 
 This is a help to whoever runs the agent. It is not evidence: nothing in a
-record shows that the check was made.
+record shows that the check was made. Where the check refuses an action,
+the agent's side MAY write a denial (section 28): its own signed
+statement that the action was not taken, and why.
 
 ## 21. The Seal and the outside time-stamp
 
@@ -975,7 +1051,8 @@ Content:
 | `by` | The recorder | `{"keys": the recorder's three keys, "name": text}` |
 | `size` | How many entries the book held | A whole number, 1 or more |
 | `root` | The top fingerprint of those entries | A fingerprint (section 10) |
-| `previous` | The seal before this one in the book. Absent for the first | That seal's fingerprint |
+| `previous` | The seal before this one in the book. Absent for the first seal of the first book; for the first seal of a later book, the last seal of the book before (section 21.6) | That seal's fingerprint |
+| `book` | The book's number among the books its recorder keeps under one permission (section 21.6). Absent for the first book | A whole number, 2 or more |
 | `when` | When it was made, as the recorder states | A time |
 
 It is signed with the three keys in `by`, with the seal labels of section
@@ -990,7 +1067,11 @@ otherwise report a problem:
 2. `size` is the number of entries before the seal, and `root` is their
    top fingerprint (`seal-mismatch`).
 3. `previous` is the fingerprint of the seal before it in the book, and
-   is absent if there is none (`seal-chain-broken`).
+   is absent if there is none (`seal-chain-broken`). The one exception is
+   the first seal of a book that gives `book`: its `previous` names the
+   last seal of the book before, which is not in this book, and is not
+   compared (section 21.6). Every seal of a book gives the same `book`
+   (`seal-chain-broken`).
 4. `when` is not earlier than the `when` of the seal before it
    (`time-went-backwards`). `when` is also not more than 300 seconds
    earlier than the latest time stated by an entry it covers that passed
@@ -1038,10 +1119,35 @@ signatures failed. For each time-stamp it MUST confirm all of these, and
 otherwise report a problem:
 
 1. It is laid out as RFC 3161 and RFC 5652 set out, in strict DER
-   (`stamp-bad-data`). Every part is read, including parts the checker
-   does not otherwise use: a whole number or an object identifier that is
-   not in its shortest form, a part that does not fill what holds it, or a
-   part the standards do not allow in that place, is refused. The signed
+   (`stamp-bad-data`). Every part the checker can tell apart is read,
+   including parts it does not otherwise use: a whole number or an object
+   identifier that is not in its shortest form, a string of bits that
+   counts more than seven unused bits or whose unused bits are not zero
+   (X.690, section 11.2.1), a string of bits, bytes or characters, or a
+   time, written in parts (the constructed form, which X.690, section
+   10.2, forbids in DER), a set whose items are not in the order of X.690,
+   section 11.6 (their encodings compared as bytes, the shorter padded at
+   its end with zeros; equal items may stand side by side), a part that
+   does not fill what holds it, or a part the standards do not allow in
+   that place, is refused. The order of a set is held only where a
+   standard requires DER: the signed attributes, which RFC 5652, section
+   5.3, requires to be DER, and every set inside them; the statement
+   (TSTInfo), which RFC 3161, section 2.4.2, requires to be DER, and
+   every set inside it; and each certificate, which RFC 5280, section
+   4.1, requires to be DER, and every set inside it. The signed data's
+   own sets (the list of fingerprint methods, the list of certificates,
+   the list of withdrawn certificates and the list of signers), and the
+   parts of a signer outside its signed attributes, may be in any order:
+   CMS does not require DER of them, and services in use list their
+   certificates in chain order, the signing certificate before its
+   issuer. What a part holds as bytes (the value of an octet string, such
+   as an extension's) is read as bytes only, so a string of bits inside
+   one is not held to these rules; the statement, which sits in an octet
+   string, is read in full as DER. A part under a tag that hides its kind
+   (a context tag) that is written in parts has the parts inside it read
+   like any other, but is itself neither refused as a string written in
+   parts nor held to the order of a set, since its tag does not say which
+   it is; written in one piece, its value is read as bytes only. The signed
    data is of version 3, with exactly one signer. The public key in the
    certificate that signed is written exactly as its own standard sets
    out, with no unused bits: RSA as RFC 3279, section 2.3.1 (the
@@ -1053,7 +1159,14 @@ otherwise report a problem:
 3. Its signed attributes name a time-stamp statement, hold the
    fingerprint of the statement, and name the certificate that signed, by
    the "signing certificate" attribute that RFC 3161, section 2.4.2,
-   requires (in the form of RFC 5035, or the older form of RFC 2634). The
+   requires (in the form of RFC 5035, or the older form of RFC 2634). Each
+   of the two forms appears at most once, as RFC 5035 requires (section 3
+   for the newer form; section 5, which writes section 5.4.2 of RFC 2634,
+   for the older): a time-stamp in which either form appears twice is
+   refused (`stamp-invalid`). Where both forms appear once each, the
+   newer form names the certificate and the older is not compared with it:
+   a choice of this format (section 15, item 22), where RFC 5035, section
+   7, lets a reader refuse a time-stamp whose two forms disagree. The
    time-stamp carries that certificate, and the signature over the
    attributes fits its public key (`stamp-invalid`). A certificate with
    the same key and other contents is another certificate.
@@ -1063,8 +1176,15 @@ otherwise report a problem:
    The signing methods are RSA (PKCS #1 version 1.5; keys of 2,048 to
    8,192 bits, with an odd public number from 3 to 2^32 - 1: never 1,
    under which anyone can make a signature that checks), ECDSA on the
-   curves P-256 and P-384, and Ed25519 (not a key of small order, as
-   section 3.8 sets out). A key of any other kind, or on another curve,
+   curves P-256 and P-384, and Ed25519 (not a key of small order, and
+   not a signature whose S is not below L, as section 3.8 sets out; the
+   signer MUST name SHA-512 as the fingerprint method, with no
+   parameters, and MUST give the signing method no parameters, as RFC
+   8419, section 3.1, requires, so a time-stamp signed with Ed25519 that
+   names SHA-256 or SHA-384, or gives either method parameters, is
+   refused, `stamp-invalid`, in words that say so; the list of
+   fingerprint methods in the signed data is read for its form only). A
+   key of any other kind, or on another curve,
    is refused (`stamp-invalid`). The checker does not try to find out
    whether an RSA modulus can be factored: a service's key is the
    service's business, and a checker trusts a service only by the
@@ -1078,7 +1198,13 @@ otherwise report a problem:
    seconds after the time it states (`dated-after-stamp`). A block
    time-stamp that section 21.3 sets aside is the one exception.
 
-The time a time-stamp states is taken to the second, rounded down.
+The time a time-stamp states is read to the millisecond: a fraction of a
+second, where it states one, is kept to three decimal places, rounded
+down, and the rest dropped. A checker shows the time to the second,
+rounded down, and compares it in milliseconds: with a record's `when`,
+which is whole seconds, and with the time of another time-stamp under
+section 21.3. So two time-stamps 300.5 seconds apart are more than 300
+seconds apart.
 
 **Whom to trust is the checker's choice.** The person checking gives the
 fingerprint (SHA-256, in base64url) of the certificate of each time-stamp
@@ -1134,7 +1260,8 @@ Show that comes with a seal (section 11).
 
 The earliest time that a counted time-stamp from a service gives a seal
 MUST NOT be more than 300 seconds earlier than the latest such time that
-a service gave any seal before it (`time-went-backwards`). So the times
+a service gave any seal before it (`time-went-backwards`; both times in
+milliseconds, as section 21.2 sets out). So the times
 cannot step backwards a little at a time. A block time-stamp is never
 reported under this rule: it is made hours after its seal, and one that
 states an earlier time is set aside (the second case above).
@@ -1179,8 +1306,8 @@ entries after it are not time-stamped.
 What a seal and a time-stamp do not fix: the last seal of a book, with
 everything after it, can be removed, and what is left still checks. Only
 a copy of that seal, or of its top fingerprint and number of entries,
-held by someone else shows it. And a time-stamp service signs with a
-method of today's kind.
+held by someone else shows it (section 21.5). And a time-stamp service
+signs with a method of today's kind.
 
 ### 21.4 A block time-stamp
 
@@ -1304,6 +1431,258 @@ its fingerprint with sources they trust. A proof is complete only one to
 several hours after it is asked for, so it is an addition to a
 time-stamp from a service, not a replacement.
 
+### 21.5 Seals held elsewhere
+
+Whoever keeps a book can cut off its end, the last seal with it, and
+what is left still checks (section 21.3). A copy of a seal kept out of
+the recorder's reach shows it: by the person, an auditor, a second copy
+of the book, or any party the recorder handed the seal to.
+
+A checker MAY be handed, beside a book, up to 64 seals held elsewhere,
+each as the entry it is in a book: `{"seal": seal record}`, with or
+without `"stamps"` and `"witnesses"` (sections 9 and 29.2). More than 64, or anything that is not a
+list, is refused (`bad-field`). An empty list is none. The same seal MUST
+NOT be handed over twice (`bad-field`).
+
+Each seal handed over is checked as a seal in a book is: its three
+signatures (`signature-invalid`), its recorder against the recorders the
+person expects (`sealer-not-expected`, rule 5 of section 21.1), and its
+time-stamps as section 21.2 sets out. Its `size` and `root` are not
+worked out again here: the book's own seal at that place is (rule 2 of
+section 21.1). A seal handed over that does not pass its own check is a
+problem with the check as a whole: it is never set aside silently.
+
+A seal handed over **counts** only where all of these hold:
+
+1. it passed its own check;
+2. the person named the recorders they expect, and its recorder is one
+   of them. Otherwise anyone could make a seal with keys of their own and
+   have a sound book reported; a checker MUST say that it was not used;
+3. the device checked its Ed25519 and ML-DSA-87 signatures. Where the
+   device does not have SLH-DSA (the Python version, and browsers that
+   have ML-DSA, such as Edge and Brave 155 when tested), the seal counts
+   on those two, and a checker MUST say that its third signature was not
+   checked. On a device without ML-DSA, or without Ed25519, it is not
+   used. A seal held elsewhere can only show a problem with a book, never
+   excuse one.
+
+For a seal that counts, at entry n (its `size`), a checker MUST report a
+problem with the book:
+
+- `book-cut-short`, where the book has n entries or fewer: it ends
+  before the place where the seal stands, so its end was cut off after
+  the seal was made;
+- `seal-not-in-book`, where the entry at n is not a seal with the same
+  content: the same fingerprint (section 3.5), which fixes `size` and
+  `root`, and so the entries before it. The book was changed after the
+  seal was made, or the seal is of another book.
+
+Nothing in a seal names its book. So a seal of another book by the same
+recorder (a book it kept before, when it started a new one) is reported
+as `seal-not-in-book` where it stands, or as `book-cut-short` where the
+other book was longer: hand over only seals of the book being checked.
+Where the seals give book numbers (section 21.6) and the book holds a
+seal, a seal handed over whose number is not the book's is not compared
+by its place: section 21.6 says what is done with it.
+
+Where the book holds the seal at entry n, the checker MUST say so. Where
+that entry did not pass its own check, it MUST say that too. The same
+content with other signatures is the same seal: only someone who holds
+the recorder's keys can sign it again, and it fixes the same entries. It
+is not a fault of the book, and a checker MUST say that the signatures
+differ. (So a copy whose third signature was changed, on a device that
+cannot check that signature, agrees with the book; on a device that can,
+it does not pass its own check.) The time-stamps of the copy stand
+outside the seal's signatures (section 11), so they may differ from
+those beside the same seal in the book; a checker MUST say where they
+do. The copy's own time-stamps are shown,
+and are not used for the entries of the book: the time by which an entry
+existed (section 21.3) comes from the book alone.
+
+A checker that is carried on (one that reads a book and then more lines)
+applies this to the book as it stands at each answer. What rests on a
+seal handed over alone (its signatures, its recorder, its time-stamps)
+it MAY check once and keep.
+
+What this closes: the end of a book cut off after a seal that someone
+else holds, back to any place before that seal; and a second history of
+a book, shown to someone who holds a seal of the first, since the seal
+does not fit it. What it does not close: a book cut back after the
+latest seal anyone holds; a book, or the part of one, never shown to
+anyone who keeps a seal; and a recorder that hands its seals to nobody.
+Witnesses (section 29), which sign for each seal and keep the latest
+they signed for, narrow the last two: a seal a witness signed for is one
+anyone who names that witness can ask it for. Statements that witnesses
+signed for a seal MAY be handed over with it, as `{"seal": seal record,
+"witnesses": [...]}` (section 29.2).
+
+### 21.6 The books of one permission
+
+A recorder may keep the record of one permission in several books, one
+after another: it seals a book, and starts a new one that begins with the
+same permission as its first line. A seal MAY say which book it is of, in
+`book`: 2 for the second book of that permission, 3 for the third, and so
+on. The first book carries no number, so every seal written before this
+member existed reads as the seal of a first book, exactly as before; `1`
+is not written (`bad-field`), so that there is one way to write each
+number. A seal that gives `book` MUST give `previous` (`bad-field`).
+A recorder numbers in one sequence all the books it keeps for one person
+and one agent, whichever of their permissions each book starts from, a
+renewal included: that is how a witness knows them (section 29.3).
+
+The first seal of book n names, as `previous`, the last seal of book
+n − 1. A checker that holds only book n cannot see that seal: it MUST NOT
+report the `previous` of that first seal, MUST say that it was not
+compared, and keeps it. Every later seal of book n names the seal before
+it in book n, and gives the same `book` (rule 3 of section 21.1). Among
+the pages of a Show, seals that give different numbers cannot be of one
+book (`seal-chain-broken`).
+
+Where a book holds a seal, its number is that of its first seal, and a
+seal held elsewhere (section 21.5) whose number is another is not
+compared with the book at all. It is not used, and a checker MUST NOT
+count it as compared: where any seal handed over was not compared, the
+check gives no pass, as where no recorder was named (section 21.5), even
+for an honest book: a reader who hands the seal of book n − 1 over
+beside book n gets no pass for book n, and should check book n − 1 with
+it instead. The
+number is the recorder's own word, so a book cut short could be sealed
+again under another number; the reader learns that the seal they hold
+was not compared, not that the book is whole. A checker MUST then say
+which of these the seal is:
+
+- **the last seal of the book before**, which the first seal of this
+  book names: where it is signed with the same key set as that first
+  seal, and not dated after it, a checker says that this book follows on
+  from it; where it is signed with another key set
+  (`seal-chain-broken`), or dated after that first seal
+  (`time-went-backwards`), it reports a problem;
+- **a seal of the book before that the first seal of this book does not
+  name**: this book then does not show whether the book before was cut
+  short, nor that this book follows on from it, and a checker MUST say so;
+- **a seal of the next book that names a seal of this book** as the seal
+  before it: the next book follows on from this one there;
+- a seal of a later or an earlier book: this book does not show whether
+  that book was cut short.
+
+In every case it does not show whether the book of the seal held was
+cut short: check that book with it.
+
+To compare book n − 1 with the seal that book n starts from, check book
+n − 1 with that seal handed over beside it: it must hold that seal at its
+place, as section 21.5 sets out.
+
+What the numbers do not show: that a book is the whole of its number; a
+checker of one book cannot tell whether the seal the next book starts
+from is the last of this book, or a seal of the next book handed over is
+its first. Nor does a checker count a limit across books: it counts within the
+book it checks.
+
+### 21.7 A seal made by a sealer that sees only fingerprints
+
+The recorder's keys need not sit beside the agent. A seal MAY be signed
+by a **central sealer**: a party that holds the recorder's keys and is
+sent, for each line of the book, only its leaf fingerprint (the SHA-256
+of the byte 0x00 and the line, without its line feed, as section 10
+sets out), never the line. From these it builds the same tree as a
+checker builds from the lines, and signs a seal over its own number of
+entries and its own top fingerprint. Nothing in any record changes: such
+a seal is the same record, byte for byte in its content, as one signed
+over the book itself, and it is checked exactly as section 21.1 sets
+out. A sealer sent a wrong fingerprint signs a seal the book does not
+pass (`seal-mismatch`).
+
+A sealer SHOULD sign only over a tree it built itself from the
+fingerprints it was sent, never over a number of entries and a top
+fingerprint handed to it; SHOULD take each line's fingerprint once, at
+its place, so that no line it has sealed can be replaced; SHOULD name,
+as `previous`, the latest seal it signed of that book (for the first
+seal of a later book, the last seal of the book before, section 21.6);
+SHOULD treat every book that starts with the same first line as one
+chain, so that a book whose first line it already holds starts only as
+the next book after the latest book with that first line, following it;
+SHOULD, where it serves several recorders with one key set, keep one
+record of every book for all of them, each book, and every book after
+it, belonging to the recorder that started it; SHOULD, where it serves
+recorders that do not trust each other, start a book only from its
+first line itself, a permission (section 4) for an agent that the
+recorder was named for, each agent named for one recorder only, so that
+no recorder can start a book whose first line is a permission for
+another recorder's agent; SHOULD limit the books each recorder may hold;
+SHOULD keep, of a seal entry it is handed, only what it checks, the
+seal, and what is bounded, its time-stamps, read for their form only
+(sections 21.2 and 21.4: how many, how long, in base64url, none
+twice; a sealer that checks no time-stamp's signature vouches for
+none), and
+refuse an entry
+longer than a line of a book may be, so that no recorder can make its
+record too large to keep; and MUST keep what it has signed safely
+before it gives a seal out.
+
+What such a sealer shows, and what it does not. With its record kept, it
+never signs two different histories of one first line: each line is
+taken once at its place, and the books of one first line follow one
+another. Where it starts books only from permissions for each
+recorder's own agents, one recorder cannot have a book sealed whose
+first line is a permission for another recorder's agent (a renewal that
+stands in that recorder's book, say), and so cannot hold that
+permission back from the recorder whose book it is; nor, with its
+record begun again, bring another recorder's book in first. It sees
+only fingerprints after the first line, so it cannot tell that a book
+which starts from another first line (another permission for the same
+agent, or, where it does not read first lines, any record the agent's
+side can sign) repeats lines of a book it has sealed; nor that a later
+book repeats lines of the book before (section 21.6).
+
+In particular, a recorder, through its own calls alone, can start a book from a permission for one of its own agents and copy into
+it permissions and stubs of another recorder's agent, leaving out any
+it chooses, and the sealer seals it. Where one person's passkey signed
+the permissions for agents of both recorders, a reader who names that
+passkey and the sealer's key set finds that book intact and within its
+slips, and nothing reports the copy. A seal of the other recorder's own
+book held elsewhere (section 21.5), handed to the checker with the
+copied book, shows a problem with it (`book-cut-short` or
+`seal-not-in-book`); where the two books' numbers differ, it cannot be
+compared (sections 21.5 and 21.6), and a checker says so and gives no
+pass. A
+witness statement on such a seal is never
+counted, because the seal covers a permission for another agent than
+the first line's (section 29.2, "When a statement counts"), so the seal does not read as
+witnessed; but nothing reports why. Readers of books from a sealer that
+serves recorders which do not trust each other SHOULD hold each
+recorder's own seals elsewhere and hand them to the checker; an
+organisation MAY instead run a sealer, with a key set of its own, for
+each recorder.
+
+A sealer that loses its record, or is put back to an older copy, can be
+made to sign a second history of a book, as a witness can (section
+29.3), and two records kept with one key set are two sealers. Witnesses
+(section 29) are the outside check for these: a witness knows a
+sequence by the recorder's keys, the person's passkey and the agent, so
+a second history shown to it would need it to sign for it too, and a
+book that does not start from a permission of the passkey the reader
+named is never read as witnessed. A checker cannot tell whether a seal
+was made by a central sealer or beside the agent: who holds the
+recorder's keys is not in the record.
+
+The library's `openSealer` is such a sealer. Its record keeps, for each
+book, the first line's leaf fingerprint, the book's number, the recorder
+it belongs to, the book it follows, whether a later book follows it, and
+its latest seal with the tree at that seal; a book with no seal yet is
+kept at its first line. Lines that no seal covers are not kept: a sealer
+opened again asks for them again. A recorder may be named with the
+fingerprints of the key sets of its agents (section 21.1 gives the
+form), and with the most books it may hold; where any recorder is named
+with agents, every book is started with its first line itself, which
+the sealer reads as a permission and does not check further (the
+passkey's signature is the book's own check), and the sealer so learns
+that permission. A book that holds no seal can be released: nothing was
+signed for it. It keeps at most 1,000 books, and its record is written
+whole at each change that must last, so its size grows with the number
+of books (about 52 KB for each sealed book, most of it the latest
+seal's three signatures).
+
+
 ## 22. Cancelling a slip
 
 The person who signed a slip can end it early, with the same passkey.
@@ -1718,6 +2097,413 @@ section 22. Nothing obliges an agent's side to acknowledge: a
 cancellation with no acknowledgement shows nothing about whether the
 agent's side was told.
 
+## 27. Reserved document names
+
+Where the other side of an action will not countersign, the next best
+binding is the other system's own identifier for the call, named in the
+stub by its fingerprint. An investigator who holds that system's own log
+can then work out the fingerprint again and match the two records,
+without either side's help. Only an identifier is meant to pick out one
+call. A stub may also name fingerprints of some of what was sent and
+received (the arguments; an HTTP request's method, address and body; an
+answer's status and body); those show that the content matches, not
+that it was the same call.
+
+So document names (section 5.1) that begin `provared.` are reserved. A
+document name that begins `provared.` and is not in this list MUST be
+refused (`bad-field`), in a stub, an approval (section 17) and the
+check before acting (section 20). The comparison is exact: a name in
+other letters, such as `Provared.invoice`, is a label like any other.
+`provared.trace-id`, `provared.request-id` and `provared.event-id` MAY
+each appear more than once in one stub (identifiers from two systems,
+say); every other name in the list MUST appear at most once, and a
+record that names one of them twice MUST be refused (`bad-field`), in
+the same places. The `sha256` of each is the SHA-256, in base64url, of
+exactly this text, in UTF-8:
+
+| Name | The text whose SHA-256 is given |
+|---|---|
+| `provared.arguments` | The call's arguments, written in the one form of RFC 8785 |
+| `provared.http-request` | The request, written as below, over `"@method"`, `"@target-uri"` and, where there is a body, `"content-digest"` |
+| `provared.http-response` | The answer, written as below, over `"@status"` and, where there is a body, `"content-digest"` |
+| `provared.trace-id` | The trace-id of the W3C Trace Context `traceparent` header that the agent's side sent, exactly as sent. That standard writes it as 32 lower-case hexadecimal characters; this format does not check the form, and a checker cannot |
+| `provared.request-id` | An identifier that the agent's side chose and sent with the call, exactly as sent |
+| `provared.event-id` | An identifier that the platform gave for the call, exactly as it gave it |
+| `provared.error` | The error text that the agent's software was given, exactly as given |
+
+An identifier or an error text MUST be one character or more, and
+well-formed Unicode.
+
+**How a request or an answer is written.** As the signature base of RFC
+9421 (HTTP Message Signatures), section 2.5, with no signature
+parameters. RFC 9421 is used only for this exact way of writing a
+message as text; nothing is signed with it. For each component, in the
+order given: a line `"<component>": <value>` and a line feed (0x0A);
+then the line `"@signature-params": (` with the components, each in
+double quotation marks and separated by one space, and `)`, with no line
+feed after it. The values:
+
+- `"@method"`: the method exactly as sent, a token of RFC 9110, section
+  5.6.2. Its letters are not changed, as RFC 9421, section 2.2.1, sets
+  out.
+- `"@target-uri"`: the absolute address exactly as sent. It MUST begin
+  `http://` or `https://`, hold only the visible characters of ASCII
+  (0x21 to 0x7E), and hold no fragment (`#`). It is never rewritten:
+  two spellings of one address (`%2F` and `%2f`, a host in capitals, a
+  port written or left out) give two fingerprints. Whoever writes the
+  stub MUST give the address in the form that was sent.
+- `"@status"`: the status code of the answer, a whole number from 100 to
+  599, written in digits.
+- `"content-digest"`: present only where the message has a body; a body
+  that is present and empty has one. The value is the field value of RFC
+  9530 with SHA-256 only: `sha-256=:`, the SHA-256 of the body's bytes,
+  in base64 with padding (RFC 4648, section 4), and `:`. The body's
+  bytes are what RFC 9530 digests: the content after any content coding
+  (such as gzip) and before any transfer coding. A system that keeps
+  the decoded body, where the body was sent compressed, will not match.
+
+No header is covered, and nothing else of the message: two messages
+that differ only in their headers give one fingerprint.
+
+For example, the request `POST https://example.com/foo?param=Value&Pet=dog`
+with the body `{"hello": "world"}` is written as these four lines:
+
+```
+"@method": POST
+"@target-uri": https://example.com/foo?param=Value&Pet=dog
+"content-digest": sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:
+"@signature-params": ("@method" "@target-uri" "content-digest")
+```
+
+**What a binding shows, and what it does not.**
+
+- An identifier binds the two records only where the other system writes
+  the same identifier into its own log. Which one a system keeps differs
+  from one system to another, and is for whoever relies on it to find
+  out. Recording both kinds, one the agent's side chose and sent
+  (`provared.trace-id`, `provared.request-id`) and one the platform gave
+  back (`provared.event-id`), gives the better chance of a match.
+- The platform's identifier is the platform's word. A matching
+  identifier shows that the two records speak of one call, not that the
+  call did what either says.
+- Only `provared.trace-id`, `provared.request-id` and `provared.event-id`
+  are meant to pick out one call. `provared.arguments`,
+  `provared.http-request`, `provared.http-response` and `provared.error`
+  show only that the content matches: identical requests, and identical
+  answers (many a `200` with the body `{}`), share one fingerprint, so a
+  match with one of them does not show that it was the same call.
+- A fingerprint of an identifier, or of arguments, that is short or easy
+  to guess can be guessed: it hides nothing from someone who can try
+  the likely values.
+- A checker cannot see whether a fingerprint was made from the text this
+  section names: only someone who holds that text can work it out again.
+- Records written before this section was added may use names that
+  begin `provared.` that are not in the list, or name one of the four
+  once-only names twice; such records are refused, so a book that holds
+  one no longer passes its check. A checker that does not know this
+  section reads a reserved name as a label.
+
+## 28. The denial
+
+A record shows what the agent did, not how often it was stopped. A
+denial closes part of that gap from the agent's own side: the agent's
+software states that it did not take an action that was asked for, and
+who said no. It is the agent's side's own word, like a one-sided stub.
+
+Content:
+
+| Member | Meaning | Form |
+|---|---|---|
+| `type` | The kind of content | `provared.denial.v0` |
+| `id` | A unique number | Section 3.7 |
+| `slip` | The slip the agent acts under | A fingerprint |
+| `pass` | Optional. For a helper agent: the pass it acts under | A fingerprint |
+| `action` | What was asked for | Text in the form of an action name. As in a refusal (section 18), a name that begins `provared.` need not be on the shared list here: what was asked for is written down as it was asked |
+| `amount` | Optional | As in a stub (section 5.1) |
+| `with` | Optional. The service asked for, as asked | The form of a service's `id`; it need not be one the slip names |
+| `details` | Optional. Documents, by their fingerprints only | As in a stub, with the reserved names of section 27 |
+| `source` | Who said no | `check`, `person` or `rule`, as below |
+| `codes` | Why, where `source` is `check`; absent otherwise | A list of 1 to 16 finding codes from the list below, none repeated |
+| `when` | When the action was refused, as the agent's side states it | A time |
+
+| Source | Meaning |
+|---|---|
+| `check` | The check before acting (section 20) did not allow the action. |
+| `person` | The person refused, or gave no approval when asked. |
+| `rule` | A rule of the software around the agent, outside the slip. |
+
+The format's own list of finding codes, from which `codes` is drawn, is
+every code a checker or the check before acting gives: `not-json`, `bad-envelope`, `bad-base64url`, `too-large`, `unknown-type`, `bad-signatures-layout`, `payload-not-canonical`, `payload-type-mismatch`, `bad-field`, `bad-key`, `signature-invalid`, `passkey-wrong-type`, `passkey-challenge-mismatch`, `passkey-origin-mismatch`, `passkey-rpid-mismatch`, `passkey-user-not-present`, `passkey-user-not-verified`, `passkey-bad-data`, `issuer-not-expected`, `slip-missing`, `slip-unusable`, `chain-broken`, `time-went-backwards`, `duplicate-id`, `duplicate-slip`, `countersignature-invalid`, `countersignature-wrong-stub`, `countersignature-not-possible`, `line-not-canonical`, `unknown-entry`, `approval-mismatch`, `approval-reused`, `approval-invalid`, `approval-not-found`, `approval-dated-after-stub`, `terms-not-found`, `terms-unusable`, `terms-mismatch`, `pass-missing`, `pass-mismatch`, `pass-too-deep`, `cover-invalid`, `cancellation-invalid`, `cancellation-not-found`, `acknowledgement-mismatch`, `vouching-missing`, `seal-mismatch`, `seal-chain-broken`, `sealer-not-expected`, `book-cut-short`, `seal-not-in-book`, `witness-invalid`, `dated-after-stamp`, `stamp-bad-data`, `stamp-wrong-data`, `stamp-invalid`, `headers-invalid`, `record-not-sound`, `proof-invalid`, `root-mismatch`, `check-failed`, `action-not-allowed`, `party-not-allowed`, `outside-valid-time`, `amount-missing`, `over-limit`, `over-each-limit`, `over-count-limit`, `over-period-limit`, `countersignature-missing`, `approval-missing`, `prohibited`, `pass-not-allowed`, `pass-wider`, `after-cancellation`, `outside-terms`.
+A code not on this list MUST be refused (`bad-field`), as MUST `codes`
+where `source` is not `check`, and its absence where it is.
+
+It is signed as a stub is (section 5.2), with the denial labels of
+section 3.2: with the two keys of the agent the slip names or, where it
+holds `pass`, with the `to.keys` of that pass (`signature-invalid`),
+exactly as an acknowledgement is (section 26). It speaks for one agent.
+
+**In a book.** The slip MUST be earlier in the book (`slip-missing`),
+and so MUST the pass, under the same slip (`pass-missing`,
+`pass-mismatch`); among the pages of a Show, both MUST be among the
+pages. A denial is in no chain (section 7): it changes no stub's `seq`
+or `previous`, and adds to no running total, count or period. It is
+compared with nothing: no rule ties its `when` to the slip's time or to
+any stub, and a checker does not judge whether the refusal was right.
+
+**What a checker says about it.** A checker MUST show a denial as the
+agent's side's own statement that it did not take the action, with who
+said no and the codes it gives, and MUST count it (`denials` among the
+counts). It MUST NOT count a denial against the agent, nor take it as
+evidence that the action was not taken in some other way. A denial
+whose signatures this device could not check, or under a slip it could
+not confirm, is not shown as fact.
+
+**How it differs from a refusal.** A refusal (section 18) is signed by
+the service and is the other side's word; a denial is signed by the
+agent's own keys and is the agent's side's word. A book may hold both
+for one attempt: the agent's side asked, the service refused, and the
+agent's software then wrote a denial with `source` `rule`. A checker
+shows both and links neither.
+
+**Whoever writes denials** SHOULD write one only for an action that was
+not taken, and never both a stub and a denial for one request. A
+denial names what was asked for: its action, its amount and its service
+are in clear, and its documents are fingerprints only; arguments and
+the contents of documents MUST NOT be written into it. A writer SHOULD
+keep to a set number of denials in any hour of its own clock, counting
+each it writes at the time it writes it, so that an agent that asks
+again and again cannot fill its book (section 9) quickly, and SHOULD say
+how many it did not write. At 600 an hour, a book's 100,000 entries
+still fill in about a week.
+
+What a denial does not show: that the action was not taken some other
+way; that the agent was asked at all, beyond its own word; or how often
+an agent was stopped, where it wrote no denial. Nothing obliges an
+agent's side to write one: a book with no denial shows nothing about
+refusals. A checker that does not know this section refuses a book that
+holds a denial (`unknown-entry`).
+
+## 29. Witnesses
+
+A seal fixes everything before it (section 21), but whoever keeps a book
+can show different histories to different readers, each sealed, since a
+reader who holds one copy cannot see another (a "split view"). A
+**witness** is a party, with a key set of its own, that keeps, for each
+recorder, person and agent, the latest seal it has signed for, and signs
+a statement for a new seal only where the new seal extends that one: in
+the same book, or as the first seal of the next book (section 21.6). A
+person and an agent are those the permission on a book's first line
+names: its passkey and the agent's key set.
+
+What a witness can then show is narrow, and is said exactly here: to a
+reader who fixed the start of a book (the permission it starts from,
+signed by a passkey the reader named) and its recorder (a key set the
+reader named), a second history sealed by that same recorder and
+starting from any permission that passkey gave that agent, renewals
+included, would need the witness to sign for it too. It shows nothing
+about a history that is sealed with other keys, or that starts from a
+permission for another agent.
+
+### 29.1 Consistency proofs
+
+The tree of section 10 is the tree of RFC 9162, section 2.1. The proof
+that the tree of the first m entries of a book is the first part of the
+tree of its first n entries (a **consistency proof**) is made as RFC
+9162, section 2.1.4.1, sets out, and checked with the steps of section
+2.1.4.2. Each value of a proof is 32 bytes.
+
+RFC 9162 defines a proof for 0 < m < n. Where m is larger than n, the
+proof does not check. Where m equals n, the proof is empty and the two
+top fingerprints MUST be the same. Where m is 0 (no seal is), the proof
+is empty and the earlier top fingerprint MUST be that of the empty tree,
+the SHA-256 hash of nothing. Anything that is not a proof of the two
+sizes it is checked for, including an empty proof for 0 < m < n, does
+not check.
+
+### 29.2 The witness statement
+
+Content:
+
+| Member | Meaning | Form |
+|---|---|---|
+| `type` | The kind of content | `provared.witness.v0` |
+| `id` | A unique number | Section 3.7 |
+| `seal` | The seal it speaks of | That seal's fingerprint (section 3.5) |
+| `size`, `root` | Repeated from the seal, so that the statement stands alone | As in the seal (section 21.1) |
+| `by` | The witness | `{"keys": the witness's two keys, "name": text}`; the name is a label |
+| `when` | When the witness signed, as the witness states | A time |
+
+It is signed with the two keys in `by`, with the witness labels of
+section 3.2. It means: "I saw this seal by this time; for the recorder
+that signed it, and the person and agent of the permission its book
+starts from, it extends every earlier seal I signed for; I will sign for
+no seal of that recorder, person and agent that does not extend it."
+
+**Beside a seal.** An entry that holds a seal MAY hold, in `witnesses`,
+1 to 4 statements, beside `stamps` (section 9). A line of a book is a
+leaf of its tree, so the statements on it are those the line held when
+it was written. Statements that came later MAY be handed to a checker
+with a copy of the seal, as a seal held elsewhere (section 21.5):
+`{"seal": seal record, "stamps": [...], "witnesses": [...]}`. A seal is
+about 52,000 bytes and a statement about 12,000, so a seal with four
+statements and four of the largest time-stamps would pass the longest a
+line may be (section 9): whoever writes such a line keeps fewer on it,
+and hands the others over beside the book.
+
+A checker MUST confirm, for each statement, and otherwise report a
+problem:
+
+1. the list holds 1 to 4 statements (`bad-field`);
+2. its envelope and content, as for any record (section 3);
+3. both its signatures check against `by.keys` (`witness-invalid`);
+4. its `seal`, `size` and `root` are the fingerprint, `size` and `root`
+   of the seal it stands beside (`witness-invalid`);
+5. its `when` is not more than 300 seconds earlier than the seal's own
+   `when` (`witness-invalid`): a witness cannot have seen a seal before
+   it was made;
+6. no two statements beside one seal are signed with the same key set
+   (`bad-field`);
+7. on a line of a book, its `id` is that of no other record in the book
+   (`duplicate-id`), as for every record (section 7).
+
+A statement on a seal's line that does not pass is a problem with that
+entry. A statement handed over with a seal held elsewhere that does not
+pass is a problem with the check as a whole, and is not used; the seal
+is used all the same, as an acknowledgement is (section 26).
+
+**When a statement counts.** A witness knows which books are one
+sequence only by the passkey and the agent of the permission on their
+first line and the keys of their recorder (section 29.3), and the
+recorder chooses both the first line and its keys. So a
+statement counts only where the reader fixed both. All of these must
+hold:
+
+1. it passed its check, and both its signatures were checked on this
+   device;
+2. the person checking named its witness among the witnesses they
+   trust, by the fingerprint of its key set (section 21.1); a statement
+   from any other witness is shown, with that fingerprint, and not
+   counted;
+3. the person named the passkeys they trust, and the book's first line
+   (for a Show: its page 0) is a permission that passed its check,
+   signed by one of them;
+4. the person named the recorders they expect, so that a seal by any
+   other recorder is a problem (rule 5 of section 21.1);
+5. every permission among the entries the seal covers names the same
+   passkey key and the same agent's key set as the permission on the
+   first line. A witness keeps the books of each person and agent apart
+   (section 29.3), so a book that starts with a permission for one agent
+   and holds a permission for another, or from another passkey, further
+   on could be the first book of a sequence the witness never saw, and so
+   a fork of the other's. A renewal by the same person for the same agent
+   meets this rule. Among the pages of a Show, the pages MUST hold every
+   entry the seal covers: single pages cannot show that no other
+   permission stands between them, and a Show never counts a statement
+   that the whole book would not;
+6. the seal it stands beside passed its own check, and its Ed25519 and
+   ML-DSA-87 signatures were checked on this device. As for a seal held
+   elsewhere (section 21.5), its third signature (SLH-DSA) may be one
+   the device cannot check: the statement speaks of the seal's content,
+   which its fingerprint fixes;
+7. for a statement handed over with a seal held elsewhere: that seal
+   counts (section 21.5), and the book holds the same seal at its place;
+   the statement then counts for the book's seal there.
+
+Where a statement from a witness the person trusts is not counted
+because of rule 3, 4 or 5, a checker MUST say why. A witness cannot
+apply rule 5 itself: it sees a book's first line, not its entries. A checker MUST say,
+for the book, the latest seal for which a statement counts, the entries
+it covers, the witnesses whose statements count for it, and every seal
+for which one counts; and where none does, that none does. Where a
+problem was found, nothing is said to be witnessed.
+
+**What being witnessed changes in the answer: nothing else.** It never
+excuses a fault, never makes a record pass that does not, and is not
+needed for a pass. It gives no time: a statement's `when` is the
+witness's own word, and is not used as a time-stamp (section 21.2). A
+statement that does not pass is a problem like any other.
+
+### 29.3 What a witness SHOULD check before it signs
+
+A checker cannot test how a witness behaved: a person names a witness
+they trust to do the following.
+
+1. **Know a sequence of books** by the fingerprint of the recorder's key
+   set (section 21.1) with the thumbprint of the passkey key (RFC 7638)
+   and the fingerprint of the agent's key set that the permission on the
+   book's first line names. So every permission one person gives one
+   agent, under one recorder, is one sequence, renewals included: a book
+   that starts with a later permission must follow on from the seal the
+   witness holds, as any new book. This is written into no record. A book
+   whose first line is not a permission (an entry that holds only a slip)
+   is not one a witness keeps. One recorder key set therefore keeps one
+   sequence for each person and agent: books kept side by side for one
+   agent need recorder keys of their own, and are then other sequences.
+2. **Check the seal** as a seal that stands alone: its envelope, its
+   content and all three of its signatures. A witness on a device that
+   cannot check one of the three signs nothing.
+3. Where it holds no seal of that sequence: confirm that the audit path
+   of the book's first line, at place 0, leads to the new seal's top
+   fingerprint (RFC 9162, section 2.1.3.2), so that the first line it was
+   given is the book's.
+4. Where it holds a seal of that sequence, of book k (section 21.6):
+   - a seal of book k: confirm that it covers more entries; that its
+     `previous` names the seal it holds (a seal it was not shown is shown
+     to it first, in order); and that a consistency proof (section 29.1)
+     from the size and top fingerprint of the seal it holds to those of
+     the new seal checks;
+   - a seal of book k + 1: confirm that its `previous` names the seal it
+     holds, and that the audit path of the book's first line leads to its
+     top fingerprint, as in item 3. From then on, book k is closed to it;
+   - a seal of an earlier book than k, or of a book after k + 1: refuse
+     it;
+   - in every case, that its `when` is not earlier than that of the seal
+     it holds.
+5. **Never sign two different seals of one book at one size**, nor a
+   seal that does not extend the one it holds. Shown the seal it holds
+   again, give the same statement again.
+6. Refuse a seal dated more than 300 seconds after its own clock, and
+   date its statement by its own clock.
+7. **Keep, before it gives a statement out, that it now holds the new
+   seal.** A witness that loses what it holds, or is put back to an
+   older copy of it, can be made to sign a fork. Opened again from what
+   it kept, it SHOULD sign nothing new until it has been brought up to
+   date from a copy, kept apart, of the statements it gave out.
+
+### 29.4 What a witness shows, and what it does not
+
+For a book whose first line is a permission signed by a passkey the
+reader named, sealed by a recorder the reader named, whose every
+permission before the seal is from that passkey for the same agent: the
+witness saw the
+seal, and so the entries before it by their top fingerprint, by the time
+it states; and a second history of those entries, sealed by the same
+recorder and starting from any permission that passkey gave the same
+agent, shown to someone else, needs that witness to sign for it too,
+which a witness that keeps section 29.3 does not. That holds across the
+books of that person and agent: a new book cannot start from an earlier
+seal than the latest the witness holds. Two witnesses need two to fail. With the latest seal a witness
+holds, handed over beside the book it is of (section 21.5), the end of
+that book cannot be cut off back to before that seal unnoticed.
+
+It does not show:
+
+- anything about a history sealed with another key set, even one the
+  reader also named (a reader who names two recorders should know that a
+  fork sealed with the second reads as witnessed), or one that starts
+  from a permission for another agent: to a witness, each is another
+  sequence;
+- that a later book does not repeat or leave out what an earlier book
+  holds: each book is checked on its own;
+- anything that was never shown to it: a book, or the end of a book
+  after the latest seal it signed for. Nothing obliges a recorder to
+  show its seals to a witness;
+- that the entries are true: a witness sees fingerprints, not entries;
+- when the seal was made: its `when` is its own word;
+- that what a witness keeps was not changed. Whoever can change it can
+  make a witness forget a sequence, and it then signs again for that
+  sequence from any seal.
+
 ---
 
 Copyright 2026 Pavel Izmaylov. This document is licensed under the