Network Working Group Y. Nam Internet-Draft Keysingate Intended status: Informational 1 October 2026 Expires: 4 April 2027 Keysingate Journal Export: Pages under a Portable Seal draft-nam-ksg-journal-export-00 Abstract A Keysingate container keeps a work journal: pages without signatures, closed by one portable seal that covers every page before it and is moved forward by each new record. This document specifies the journal's pages, records and seals, the two forms of a journal (unanchored and anchored), the two exports a third party receives -- one page with its proof, or the whole journal once -- and how a verifier checks them without contacting anyone. It also specifies a profile for anchoring seals in Solana with a blind memo that shows outsiders only the fact of a write. The core documents, time format and anchor rule it relies on are those of draft-nam-ksg-core-00. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 4 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights Nam Expires 4 April 2027 [Page 1] Internet-Draft KSG-Journal-Export October 2026 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 2 3. Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Bodies . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Seals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Further Seals . . . . . . . . . . . . . . . . . . . . . . 5 6. Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Exports . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Final Export . . . . . . . . . . . . . . . . . . . . . . 6 7.2. Pointwise Export . . . . . . . . . . . . . . . . . . . . 6 8. Verification . . . . . . . . . . . . . . . . . . . . . . . . 6 9. Solana Seal Profile . . . . . . . . . . . . . . . . . . . . . 7 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 13. Normative References . . . . . . . . . . . . . . . . . . . . 9 14. Informative References . . . . . . . . . . . . . . . . . . . 9 Appendix A. Implementation Status . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction A page carries no signature; a *record* of up to 99 content pages and a service page is closed by one *seal*; the seal covers the whole chain of pages up to it; an anchor gives a record its time bound and its force. One verifier procedure reads both exports. The container itself -- how it is built, who presses what, how its keys are held -- is not specified here. A verifier sees only pages, seals and anchors. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Nam Expires 4 April 2027 [Page 2] Internet-Draft KSG-Journal-Export October 2026 The canonical form, document hash, signatures, time, limits and the Bound Rule are those of [KSG-CORE]. All documents here carry "@context": "urn:keysingate:core:v3" and "v": 3; v is the journal format's version, which today equals the core's and may move separately. Page: Room for content, up to 2 048 bytes; no signature. Record: The unit of writing: content pages and, when there is more than one page, a service page; one time mark; one seal. Seal: A signed statement that closes a record and covers all pages before it. Agent, owner: The two parties of a journal, each known by keys pinned in the journal itself. 3. Layout A journal has 1 + 1000 + 100 + 2 places: page 0 (the opening); 1 000 working pages; 100 pages of the transfer zone (changes of owner); 2 coupling pages. All zones form *one* chain of pages in the order of writing. 4. Pages { "@context": "urn:keysingate:core:v3", "type": "BoundPage", "v": 3, "seq": 7, "zone": "work", "slot": 7, "batch": { "id": 3, "index": 0, "of": 2 }, "offset_ms": 86400000, "body": { ... }, "prev": "1220..." } * seq -- the page's place in the one chain; page 0 is the opening; * zone -- opening, work, transfer or coupling; slot -- the place within the zone, from 1 (0 for the opening); * batch -- the record the page belongs to: its number (id, the opening is record 0), the page's place in it (index) and the record's page count (of); * offset_ms -- one value for the whole record; * prev -- the hash of the previous page; for page 0, the container identifier [KSG-CORE]. The page hash is the core document hash of the page. 4.1. Bodies +=====================+=======================================+ | Body | Content | +=====================+=======================================+ | opening | container, mode (the form the journal | | | opens in), agent and owner as {id, | | | keys} -- pins both parties' keys | Nam Expires 4 April 2027 [Page 3] Internet-Draft KSG-Journal-Export October 2026 +---------------------+---------------------------------------+ | content | kind (work, artifact_or_rights, | | | shares_declared_lost, hash_binding), | | | content (inline base64url bytes or | | | digest), optional content_type URI | +---------------------+---------------------------------------+ | manifest | the service page of a multi-page | | | record; always its last page | +---------------------+---------------------------------------+ | transfer | a hand-off between agents (work zone) | | | or a change of owner (transfer zone) | +---------------------+---------------------------------------+ | coupling | one of the two coupling places | +---------------------+---------------------------------------+ | rule | the rule of two seals, set or lifted | +---------------------+---------------------------------------+ | form | to: the form after this page | +---------------------+---------------------------------------+ | repeat_confirmation | the journal's confirmation of ten | | | identical records | +---------------------+---------------------------------------+ Table 1 A content piece commits as SHA-256("ksg:bound:inline:v1" || bytes) or SHA-256("ksg:bound:digest:v1" || digest) -- plain concatenation, the label being fixed. A record's hash is SHA- 256(F("ksg:bound:record:v1") || F(c1) || ... || F(cn)) over the commitments of its pieces in order, with F (length-prefixed field) as in [KSG-CORE]. A record is at most 99 content pages and 204 800 bytes. 5. Seals { "@context": "urn:keysingate:core:v3", "type": "JournalSeal", "v": 3, "container": "1220...", "number": 8, "batch": 3, "head": "1220...", "root": "1220...", "counts": { "work": 7, "transfer": 0, "coupling": 0 }, "agent": "did:example:agent", "owner": "did:example:owner", "mode": "pro", "prev": "1220...", "offset_ms": 86400000, "signatures": [ ... ] } * number -- the seq of the record's last page: every page written; * head -- the hash of that page; * root -- the Merkle tree head [RFC6962] over *all* pages from page 0, each leaf being SHA-256(0x00 || page hash); Nam Expires 4 April 2027 [Page 4] Internet-Draft KSG-Journal-Export October 2026 * prev -- the hash of the previous seal; absent only on the opening's seal; * rule -- present while the rule of two seals is in force: its hash; * signatures -- by the current agent, Ed25519: a seal passes only if it is present and valid under a key pinned in the journal (page 0 or the latest transfer page), never a key the presenter brings. The post-quantum signature is not on the seal: it is on the container as a whole, outside this export (see Security Considerations). Every seal covers the whole chain before it, so a later seal confirms the pages of every earlier record. 5.1. Further Seals * *Transfer seal* (TransferSeal: page, subject, signatures): a hand- off is sealed by both agents; a change of owner by agent and owner on both sides. Never removed. The new agent replaces the old one; the old one seals nothing afterwards. * *Co-seal* (CoSeal: batch, subject, signatures): the owner's second seal on a record. Required in the anchored form for artifact_or_rights, and for every record while the rule of two seals is in force; a record that needs it waits, and nothing else is written meanwhile. * *Coupling*: each of the two places is written once; place 2 names the coupled container and its last seal. 6. Forms +=======+===================================+ | Form | Anchors | +=======+===================================+ | local | none; a seal MUST NOT be anchored | +-------+-----------------------------------+ | pro | every seal MUST be anchored | +-------+-----------------------------------+ Table 2 The form changes only by a form page sealed by the owner as well, in either direction, as long as pages last. Going to pro, the seal of that page is the first anchored one; an anchor made before the owner's seal on the change MUST be rejected. Without the owner, a journal stays local. Nam Expires 4 April 2027 [Page 5] Internet-Draft KSG-Journal-Export October 2026 *Force.* A record has force when its seal is anchored. Two records' link is confirmed when both are anchored and no unanchored record lies between them. A report names the runs of consecutive anchored records. 7. Exports 7.1. Final Export The whole journal, once; the container works no more after it. { "@context": "urn:keysingate:core:v3", "type": "BoundJournalExport", "pages": [ ... ], "seal": { ... }, "anchors": [ { "batch": 3, "anchor": { ... } } ], "transfers": [ ... ], "coseals": [ ... ] } Empty arrays are omitted. 7.2. Pointwise Export One page with its inclusion proof [RFC6962] under the current seal and, in the anchored form, the seal's anchor: { "@context": "urn:keysingate:core:v3", "page": { ... }, "proof": { ... }, "seal": { ... }, "anchor": { ... } } At most 12 pointwise exports per journal. 8. Verification Input: the export, the container identifier, the class (or the channel it derives from, [KSG-CORE]), the agent's keys from the verifier's own source, a profile, network readers. *Final export.* The verifier replays the journal from page 0 by the same rules that wrote it: 1. limits, then strict parsing of every document; 2. page 0 is the opening, prev is the container identifier, its pinned agent keys equal the ones the verifier holds, its form agrees with the class; 3. every page links to the previous one; zones, slots and records are in place; every record's pages and service page agree; 4. every seal is recomputed from the pages (number, head, root, counts, parties, form, rule, prev) and its signatures verified under the pinned keys; transfer seals and co-seals where the rules require them; Nam Expires 4 April 2027 [Page 6] Internet-Draft KSG-Journal-Export October 2026 5. in pro, every seal has an anchor, read by the Bound Rule; in local, no anchor is accepted; 6. the report: number of pages, the current agent and owner, the form, transfers, co-sealed records, each record with its seal and whether it is anchored, the anchored runs with their bounds, and an explicit list of what is not established. *Pointwise export.* The page's hash is included under the seal's root at seq; the seal's signatures verify under the agent keys the verifier holds; in pro, the anchor is read by the Bound Rule. A pointwise export proves the page and its time bound; it does not prove the pages around it. 9. Solana Seal Profile A seal is anchored as the memo of an ordinary Solana transaction (the SPL Memo program). The anchor's type is urn:ksg:anchor:solana:seal:v1; its proof names the transaction signature, slot and cluster. The memo is *blind* and of fixed length: ksg:bs:v1 link = PRF(K, "ksg:bs:link:v1" || prev) commit = PRF(K, "ksg:bs:commit:v1" || seal) PRF(K, x) = HKDF-SHA256(salt = "ksg:bs:v1", IKM = K, info = x), 16 bytes, lowercase hex seal is the seal's hash (32 bytes); prev is the seal's own prev -- the previous seal's hash, whether or not that seal was anchored -- or the container identifier for the opening's seal, which has no prev. *Scan key.* K is the holder's scan key for the calendar month (UTC) in which the seal was made: K(YYYY-MM) = HKDF-SHA256(salt = "ksg:bs:v1", IKM = master, info = "ksg:bs:period:v1" || len64(label) || label) with len64 the label's length as 8 bytes big-endian. A key handed out reads its month's seals and no other's. *Scan keys are not part of any export or of this document's public material*: the holder gives one to a verifier together with an export. Without it, an observer sees that a memo exists and nothing else. Nam Expires 4 April 2027 [Page 7] Internet-Draft KSG-Journal-Export October 2026 *Reader.* The reader recomputes the memo from the seal and the key and finds it in the named transaction; a different memo is a rejection. It asks the node for its genesis hash and accepts only the cluster the verifier named. The moment it returns is the block time -- a stake-weighted estimate at one-second grain -- and it says so. A fork (two memos with one link and different commit) is visible only to a holder of the key. *Status records* of [KSG-CORE] are anchored with an *open* memo, because the status section is the part of a container that is meant to be read: ksg:st:v1 link = SHA-256("ksg:st:link:v1" || prev) commit = SHA-256("ksg:st:commit:v1" || record hash) prev is the record's own prev; both values are written as multihashes. anchor type urn:ksg:anchor:solana:status:v1. 10. Security Considerations *Signatures.* Every seal carries Ed25519; a verifier MUST require it. Keys come from the journal's own pinned pages and the verifier's source, never from the presenter. The post-quantum signature (ML- DSA-65) is on the stored container as a whole, not on each seal: an export, once it has left the container, is protected by its recipient. Against a future forger able to break Ed25519, an anchored seal is held by its anchor: a page that differs from the anchored one does not hash to the anchored value. *Time.* Only an anchor read by the Bound Rule gives a bound; offset_ms and anchor statements are not evidence. In the local form a journal proves authorship and order, not time. *Replay.* A verifier replays the journal by the rules that wrote it; a journal accepted by a verifier is one the writing rules would have produced. *Blind anchors.* The blind memo hides the chain from outsiders and with it the visibility of forks: a fork is found only by someone holding the key. The paying account remains visible and groups its memos. Nam Expires 4 April 2027 [Page 8] Internet-Draft KSG-Journal-Export October 2026 11. Privacy Considerations Pages may carry a digest instead of content, so an export can prove a record without revealing it. The blind memo keeps a journal's existence and pace from becoming a public time series; status memos are open by design. 12. IANA Considerations This document has no IANA actions. The anchor types urn:ksg:anchor:solana:seal:v1 and urn:ksg:anchor:solana:status:v1 and the memo tags ksg:bs:v1 and ksg:st:v1 are opaque, byte-compared strings; no URN namespace is registered by this document. 13. Normative References [KSG-CORE] Nam, Y., "Keysingate Core: Channel Documents, Status Records and Anchored Time", Work in Progress, Internet- Draft, draft-nam-ksg-core-00, October 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, June 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . 14. Informative References [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", RFC 7942, DOI 10.17487/RFC7942, July 2016, . Appendix A. Implementation Status Per [RFC7942]. ksg-core-v2 (Rust) writes and verifies the journal; ksg-verify-v2 verifies both exports and reads seal and status anchors from Solana. The workspace runs 752 tests; the test vectors are regenerated and compared byte for byte by the reference build. Nam Expires 4 April 2027 [Page 9] Internet-Draft KSG-Journal-Export October 2026 Author's Address Yevhenii Nam Keysingate Email: nam@keysingate.com URI: https://github.com/keysingate Nam Expires 4 April 2027 [Page 10]