Independent Submission D. Shearer
Internet-Draft LumoSQL
Intended status: Experimental 23 July 2026
Expires: 24 January 2027
Lumion Encoding: Byte Layout for Lumion Objects
draft-shearer-lumion-encoding-00
Abstract
The Lumion [LUMION] is specified as a set of abstract properties.
This document provides the cryptographic construction and byte layout
conforming to the Lumion specification. It specifies: * Lumion
header including magic identification bytes * deterministic signed
body * a flat list of part hashes for redaction * Ed25519 signatures
* optional per-part encryption using Authenticated Encryption with
Associated Data (AEAD), which encrypts content and also authenticates
chosen metadata.
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 24 January 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
and restrictions with respect to this document.
Shearer Expires 24 January 2027 [Page 1]
Internet-Draft Lumion Encoding July 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Status of this document . . . . . . . . . . . . . . . . . 3
1.3. Relationship to the abstract Lumion RFC . . . . . . . . . 3
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overall Structure . . . . . . . . . . . . . . . . . . . . . . 3
4. Optional Text Form . . . . . . . . . . . . . . . . . . . . . 4
5. The Name . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Hash Labels . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Hash Input Framing . . . . . . . . . . . . . . . . . . . 5
6.2. Label Registry . . . . . . . . . . . . . . . . . . . . . 5
7. The Body and Signature . . . . . . . . . . . . . . . . . . . 6
8. Deterministic Encoding . . . . . . . . . . . . . . . . . . . 7
8.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 7
8.2. Field Tables . . . . . . . . . . . . . . . . . . . . . . 8
9. Parts and Part Hashes . . . . . . . . . . . . . . . . . . . . 11
10. Confidentiality . . . . . . . . . . . . . . . . . . . . . . . 12
11. Access Rules . . . . . . . . . . . . . . . . . . . . . . . . 13
12. Links and Version . . . . . . . . . . . . . . . . . . . . . . 13
13. Mapping to the Abstract Lumion . . . . . . . . . . . . . . . 14
14. Security Considerations . . . . . . . . . . . . . . . . . . . 15
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
16.1. Normative References . . . . . . . . . . . . . . . . . . 16
16.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
The Lumion [LUMION] is defined as an abstract self-contained object.
It is a data row that carries its own name, integrity proof,
authorship, and access rules. The encoding in this RFC specifies the
byte layout of one Lumion so independent implementations are
interoperable.
A Lumion encoded by this document is still checkable from its own
bytes by any party, with no server to ask. The encoding sits one
layer below the abstract Lumion in the document suite (see [LUMION],
"Relationship to Other Documents") and above the optional authority
layer [LUMION-AUTHORITY], an external system for guarantees not
carried by one copy of a Lumion.
Shearer Expires 24 January 2027 [Page 2]
Internet-Draft Lumion Encoding July 2026
1.1. Scope
This document defines:
* the byte structure of a Lumion;
* how each abstract part maps to a byte field or region of bytes;
* the rules an encoding MUST follow to keep the name a function of
named content;
* an optional text form for text-only transports.
1.2. Status of this document
This is an experimental (RFC *-00) encoding.
1.3. Relationship to the abstract Lumion RFC
Every field defined here realises a part named in [LUMION], as
explained in Section 13. An encoded Lumion MUST satisfy every
property required by [LUMION]; where this document and the abstract
Lumion may differ, the abstract Lumion takes precedence.
1.4. Requirements Language
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.
2. Terminology
This document uses the terms defined in [LUMION]: Lumion, part, name,
part hash, signature, redaction, confidentiality, role-based access
control, permitted writers, link, and version. It adds:
Field: A named region of the byte layout carrying one piece of a
Lumion.
Region: A contiguous sequence of bytes within a Lumion holding a
group of related fields.
3. Overall Structure
A Lumion is a sequence of regions. The abstract parts of [LUMION]
group into regions as follows.
Shearer Expires 24 January 2027 [Page 3]
Internet-Draft Lumion Encoding July 2026
+------+-------------------+--------------------+--------------+
| name | body metadata | parts | links and |
| | (signature, etc) | (with integrity | version |
| | | values) | |
+------+-------------------+--------------------+--------------+
The first region is a fixed Lumion header. It contains the magic
string Lumion, the encoding version, and the Lumion name. Software
can therefore identify a Lumion and extract its name without parsing
the whole object. A Verifier MUST still recompute the name from the
signed body and reject the Lumion if the carried name does not match.
The region order is fixed:
1. Lumion header;
2. signed-body metadata;
3. parts;
4. links and version;
5. signature.
Only the Lumion header has fixed offsets. All later regions are
length-prefixed.
The mandatory regions are the Lumion header, signed-body metadata,
parts region, and signature region. Prior links, version, access
rules, and each individual part are optional fields inside those
regions.
4. Optional Text Form
The primary Lumion encoding is the binary byte sequence defined by
this document. The binary form is the input to parsing, name
computation, signature verification, part hash verification,
redaction, update checking, and encryption processing.
For transports, logs, command lines, or protocols that require
printable text, an implementation MAY represent an entire binary
Lumion using the base64url alphabet, the URL-safe Base64 alphabet
defined in Section 5 of [RFC4648]. This text form carries Lumion
bytes as text. The binary form remains the canonical Lumion
encoding.
Shearer Expires 24 January 2027 [Page 4]
Internet-Draft Lumion Encoding July 2026
When the Lumion text form is used, it MUST be the unpadded base64url
encoding defined in Section 5 of [RFC4648] of the exact binary Lumion
byte sequence. A decoder MUST restore the original binary bytes
before applying any Lumion verification rule. The Lumion text form
MUST NOT contain whitespace or separators.
5. The Name
The name is a SHA-256 digest derived from the whole body ([LUMION],
"Name"). SHA-256 is the hash function used here; a digest is the
hash output. Future revisions may define other hash functions.
The name is computed over the part hashes and signed public metadata,
not directly over every disclosed byte. A present part proves itself
against its part hash; a removed part leaves that hash behind. For
an encrypted part, the part hash covers ciphertext and encryption
metadata, not plaintext. A party can therefore verify the Lumion
name and signature without decryption keys.
Two Generators encrypting the same plaintext with different keys or
nonces can produce different Lumion names. The encoding does not use
deterministic encryption, which would leak plaintext equality.
6. Hash Labels
Every hash in this encoding is domain-separated by a fixed ASCII
label (Section 14). This section is the normative list of labels and
inputs. An implementation MUST use these exact label byte strings
and input order; any deviation changes the Lumion name and breaks
interoperability.
6.1. Hash Input Framing
Every hash is computed as:
H(label, arg1, arg2, ..., argN)
= SHA-256( lv(label) || lv(arg1) || lv(arg2) || ... || lv(argN) )
where lv(x) is the u32 length of x followed by the octets of x, as
defined in Section 8.1. The label is framed as an lv. There is no
unframed concatenation in hash inputs, so argument boundaries are
unambiguous.
6.2. Label Registry
The complete set of labels for encoding version 0x01:
Shearer Expires 24 January 2027 [Page 5]
Internet-Draft Lumion Encoding July 2026
+========================+========================================+
| Label | Computed over (in order) |
+========================+========================================+
| Lumion-v1:part-content | the part cleartext, or the ciphertext- |
| | and-metadata of an encrypted part |
+------------------------+----------------------------------------+
| Lumion-v1:access-rule | the encoded access-rule structure of a |
| | part |
+------------------------+----------------------------------------+
| Lumion-v1:part-leaf | part-index, part-kind, access-rule |
| | hash, part-salt, part-content hash, |
| | part descriptor |
+------------------------+----------------------------------------+
| Lumion-v1:part-list | the ordered list of part-leaf hashes, |
| | ascending part-index |
+------------------------+----------------------------------------+
| Lumion-v1:name | the public-metadata region, then the |
| | part-list hash |
+------------------------+----------------------------------------+
| Lumion-v1:ToBeSigned | the public-metadata region, the part- |
| | list hash, then every part descriptor |
| | and its part-leaf hash |
+------------------------+----------------------------------------+
Table 1
The part-leaf hash is the part hash referred to throughout [LUMION]
and this document. The part-list hash is computed over the ordered
part-leaf hashes and is covered by the name (Section 5) and signature
(Section 7).
A later encoding version that changes any hash function, input, or
order MUST change the version octet (Section 3) and SHOULD use a
fresh label prefix in place of Lumion-v1:.
7. The Body and Signature
The body is the content covered by one signature ([LUMION],
"Integrity and Authorship"). The signature establishes that the body
is unaltered and identifies the producing key.
Every Lumion MUST carry exactly one Ed25519 [RFC8032] body signature.
Ed25519 is the digital signature scheme used here. Future revisions
may define other signature schemes. A Lumion MUST NOT omit the body
signature.
The signature covers a deterministic ToBeSigned byte string, meaning
the exact bytes covered by the signature, containing:
Shearer Expires 24 January 2027 [Page 6]
Internet-Draft Lumion Encoding July 2026
1. the encoding version;
2. the signed-body metadata;
3. the ordered list of part hashes;
4. every part descriptor;
5. access rules;
6. prior link and version;
7. the signer verification key.
Every field that can change the meaning, access rules, cryptographic
verification, or link structure of a Lumion appears inside
ToBeSigned.
The signed part descriptor contains the part index, part kind, access
rule, and part hash. Redaction changes only the carried state and
disclosed bytes. The signed descriptor and part hash remain
unchanged, allowing redaction without re-signing.
The signer verification key is placed inside signed-body metadata and
is covered by the signature. A Verifier MUST NOT treat it as trusted
until the signature verifies.
8. Deterministic Encoding
For the name to be a function of named content, the encoding MUST be
deterministic: the same named content MUST produce the same bytes in
every implementation.
The serialisation is a flat, length-prefixed binary layout: every
field is a 32-bit length followed by that many bytes, in a fixed
order. Unsigned integers inside fields are 64-bit big-endian values,
meaning most significant byte first. No implementation may choose a
different order, padding, or representation.
A parser MUST reject fields that run past the end of their containing
region and objects exceeding implementation limits. Implementations
MUST enforce documented local limits before allocation.
8.1. Notation
The field tables use the following primitives.
Shearer Expires 24 January 2027 [Page 7]
Internet-Draft Lumion Encoding July 2026
+========+======================================+
| Symbol | Meaning |
+========+======================================+
| u32 | 32-bit unsigned length, big-endian |
| | (most significant byte first) |
+--------+--------------------------------------+
| u64 | 64-bit unsigned integer, big-endian |
| | (most significant byte first) |
+--------+--------------------------------------+
| octet | one 8-bit byte |
+--------+--------------------------------------+
| lv | a length-value field: a u32 length |
| | followed by exactly that many octets |
+--------+--------------------------------------+
Table 2
Every variable-length field in a Lumion is an lv. The single lv rule
is what makes the layout deterministic and self-delimiting: a reader
never guesses a boundary, it reads a length and then that many
octets.
A salt is random data added before hashing to prevent guessing
attacks against removed content.
8.2. Field Tables
Offsets are given only for the header, the sole fixed-offset region;
every later field is located by the u32 length that precedes it.
Header:
+=========+========+==========+===================================+
| Field | Offset | Type | Value / notes |
+=========+========+==========+===================================+
| magic | 0 | 6 octets | ASCII Lumion, not length-prefixed |
+---------+--------+----------+-----------------------------------+
| version | 6 | octet | encoding version, 0x01 for this |
| | | | document |
+---------+--------+----------+-----------------------------------+
| name | 7 | lv | carried name; 32-octet SHA-256 |
| | | | digest for this version |
+---------+--------+----------+-----------------------------------+
Table 3
Body (each field an lv, in this order, immediately after the header):
Shearer Expires 24 January 2027 [Page 8]
Internet-Draft Lumion Encoding July 2026
+=================+======+==================================+
| Field | Type | Contents |
+=================+======+==================================+
| public-metadata | lv | the public-metadata region below |
+-----------------+------+----------------------------------+
| parts-region | lv | the parts region below |
+-----------------+------+----------------------------------+
| signature | lv | Ed25519 signature over |
| | | ToBeSigned, 64 octets |
+-----------------+------+----------------------------------+
Table 4
Public-metadata region:
+============+======+=============================================+
| Field | Type | Contents |
+============+======+=============================================+
| version | u64 | encoding version, inside signature coverage |
+------------+------+---------------------------------------------+
| signer key | lv | Ed25519 verification key, 32 octets |
+------------+------+---------------------------------------------+
| version | u64 | starts at 0, increments by one per update |
| count | | |
+------------+------+---------------------------------------------+
| prior | lv | prior Lumion name, or an empty lv when |
| | | absent |
+------------+------+---------------------------------------------+
Table 5
Parts region:
+=======+======+===================================+
| Field | Type | Contents |
+=======+======+===================================+
| count | u32 | number of part slots that follow |
+-------+------+-----------------------------------+
| slot | lv | one slot-body per part, ascending |
| | | part-index; repeated count times |
+-------+------+-----------------------------------+
Table 6
Slot-body (inside each slot lv):
Shearer Expires 24 January 2027 [Page 9]
Internet-Draft Lumion Encoding July 2026
+============+=======+==========================================+
| Field | Type | Contents |
+============+=======+==========================================+
| state | octet | 0x01 clear, 0x02 encrypted, 0x03 removed |
+------------+-------+------------------------------------------+
| descriptor | lv | signed part descriptor; identical across |
| | | redaction |
+------------+-------+------------------------------------------+
| part-hash | lv | part hash, 32 octets |
+------------+-------+------------------------------------------+
| salt | lv | present for clear and encrypted states |
+------------+-------+------------------------------------------+
| content | lv | cleartext or ciphertext; present for |
| | | clear and encrypted states |
+------------+-------+------------------------------------------+
Table 7
Descriptor (inside the descriptor lv):
+=============+======+===============================+
| Field | Type | Contents |
+=============+======+===============================+
| part-index | u64 | numeric index; fixes ordering |
| | | in the name and ToBeSigned |
+-------------+------+-------------------------------+
| part-kind | lv | application field name |
+-------------+------+-------------------------------+
| access-rule | lv | the access-rule structure |
| | | below |
+-------------+------+-------------------------------+
Table 8
Access-rule (inside the access-rule lv):
Shearer Expires 24 January 2027 [Page 10]
Internet-Draft Lumion Encoding July 2026
+==============+=======+============================================+
| Field | Type | Contents |
+==============+=======+============================================+
| rule-type | octet | 0x00 open, 0x01 immutable, 0x03 writer-set |
+--------------+-------+--------------------------------------------+
| writer | u32 | number of permitted writer identifiers |
| count | | |
+--------------+-------+--------------------------------------------+
| writer | lv | one per writer, bytewise-ascending order; |
| | | repeated writer-count times |
+--------------+-------+--------------------------------------------+
Table 9
A parser MUST reject a Lumion whose header magic or version octet
does not match, whose part-slot states fall outside the defined set,
or in which any lv length runs past the end of its containing region.
9. Parts and Part Hashes
Each part of a Lumion has its own part hash, by which it can be
referred to and its presence proven even when removed ([LUMION],
"Redaction").
A part MAY span one or more fields. Fields in the same part are
redacted together and governed by one rule. The Generator chooses
the mapping from fields to parts.
That choice is the main determinant of a Lumion's size. Per-part
cost is paid for two things: the unpredictable data that makes a
removed part safe against a dictionary search, and any access rule
the part carries (Section 11). A field needs neither when it is
disclosed and written together with its neighbours. A Generator
SHOULD place fields that are shown, removed, and governed together in
one part. A field SHOULD have its own part only when separate
disclosure or removal requires it.
Grouping is visible in the encoding, and redacting any field in a
grouped part redacts all of them.
A Generator MAY group several small rows into one Lumion to share the
fixed cost of the name and signature. Grouping rows makes them one
unit for signing, versioning, and row-level redaction, so part
grouping within a row is usually the better first choice.
Shearer Expires 24 January 2027 [Page 11]
Internet-Draft Lumion Encoding July 2026
Each part has a part hash. The ordered list of part hashes is hashed
under the Lumion-v1:part-list label (Section 6); that single part-
list hash is included in ToBeSigned and in the input to the Lumion
name. The list order is the ascending numeric order of part-index
values. Present parts are included.
The part hash for a present part is the Lumion-v1:part-leaf hash,
computed over these inputs in this order, each framed as an lv per
Section 6.1:
H("Lumion-v1:part-leaf", part-index, part-kind,
access-rule-hash, part-salt, part-content-hash,
part-descriptor)
where access-rule-hash is the Lumion-v1:access-rule hash of the
part's access rule and part-content-hash is its Lumion-v1:part-
content hash (Section 6).
A part starts with a one-octet state tag:
* 0x01: present cleartext part;
* 0x02: present encrypted part;
* 0x03: removed part.
A present part carries all data needed to recompute its part hash. A
removed part carries only its part hash and the signed part
descriptor. The state tag is carried outside the signed descriptor,
so changing present to removed does not change the signed body. A
reader therefore knows whether bytes are disclosed content or a
stand-in part hash before attempting to interpret the part.
A Generator MUST add a fresh salt to every removable part. The salt
MUST contain at least 128 bits from a cryptographically secure random
source. A Generator SHOULD use 256-bit salts for long-lived or high-
value data. A salt MUST NOT be reused within one Lumion. A salt is
carried only with a present part; when a part is removed, the salt is
removed with the content. This prevents dictionary tests against
guessable removed content.
10. Confidentiality
A part MAY be encrypted to a fixed set of readers ([LUMION],
"Confidentiality").
Shearer Expires 24 January 2027 [Page 12]
Internet-Draft Lumion Encoding July 2026
An encrypted part contains ChaCha20-Poly1305 [RFC8439] ciphertext.
ChaCha20-Poly1305 is the required AEAD algorithm. Associated data is
authenticated but not encrypted; it MUST include the encoding
version, part-index, part-kind, and access-rule hash. The nonce MUST
be unique for the content encryption key. The authority layer
handles content-key wrapping and key distribution.
For encrypted parts, the part hash is computed over the ciphertext
and encryption metadata, not over plaintext. This lets any Verifier
check the Lumion name, signature, and redaction state without holding
a read key. A Reader that holds the content encryption key decrypts
the ciphertext and checks AEAD authentication.
11. Access Rules
A part MAY carry, within the signed body, a fixed set of writer keys,
or a mark that it may not change ([LUMION], "Access Control").
An access rule is encoded in the signed part descriptor. The
permitted writers are a sorted list of writer key identifiers or
writer public-key commitments. A public-key commitment is a hash or
other fixed reference to a public key. The sorted order is bytewise
ascending order of the encoded identifiers. The access-rule hash in
a part hash binds the permitted writers to that part.
The access rule for a part is fixed across versions. A Verifier
checking an update MUST reject the current Lumion if the access rule
for any corresponding part differs from the prior version, even when
the part content was changed by a permitted writer.
A Verifier that holds a prior version checks access rules by
comparing the prior and current Lumions part by part. If a part's
content hash changed, the current Lumion signature MUST verify under
a key in that part's prior permitted writers. If the part had no
permitted writers, any content change is invalid.
An unchangeable part is encoded with access-rule type immutable. A
Verifier MUST reject a current Lumion if the hash for an immutable
part differs from the corresponding hash in the prior version.
12. Links and Version
A Lumion MAY reference its prior version by name and MAY carry a
version count ([LUMION], "Structural Linkage", "Versioning").
The version count is a 64-bit unsigned integer. Versioning starts at
zero. A Lumion that claims to be an update of a prior Lumion MUST
increment the prior version by exactly one and MUST carry a prior
Shearer Expires 24 January 2027 [Page 13]
Internet-Draft Lumion Encoding July 2026
link to the previous Lumion name. A Verifier that is checking an
update against a supplied prior Lumion MUST reject the update if
either the version increment or the prior link is wrong. The version
count and prior link are inside ToBeSigned.
Future revisions may introduce other link directions, such as next,
parent, and child.
13. Mapping to the Abstract Lumion
This section maps each property named in [LUMION] to a field or
region of this encoding. An implementation is a correct Lumion
encoder when each abstract property maps to its field here and every
property of [LUMION] holds.
+=====================+=============================================+
| Abstract Lumion | Encoding realisation |
| property | |
+=====================+=============================================+
| Lumion self- | Fixed Lumion header containing |
| identification | Lumion, encoding version, and |
| | carried name |
+---------------------+---------------------------------------------+
| Name | Lumion-v1:name SHA-256 hash over |
| | signed public metadata and the |
| | Lumion-v1:part-list hash of the |
| | ordered part hashes (Section 6) |
+---------------------+---------------------------------------------+
| Signed body | Deterministic ToBeSigned byte |
| | string |
+---------------------+---------------------------------------------+
| Signature | Exactly one body signature over |
| | ToBeSigned; Ed25519 is mandatory |
| | to implement |
+---------------------+---------------------------------------------+
| Signer identity | Ed25519 verification key in |
| | signed-body metadata |
+---------------------+---------------------------------------------+
| Part | Part entry in the parts region, |
| | identified by numeric part-index |
+---------------------+---------------------------------------------+
| Part hash | Part-hash field in each part |
| | entry |
+---------------------+---------------------------------------------+
| Redaction | Part state removed, carrying |
| | only the part hash and signed |
| | slot descriptor |
+---------------------+---------------------------------------------+
Shearer Expires 24 January 2027 [Page 14]
Internet-Draft Lumion Encoding July 2026
| Guessable-content | Fresh per-part salt carried only |
| protection | while the part is present |
+---------------------+---------------------------------------------+
| Confidentiality | Encrypted part state and |
| | ChaCha20-Poly1305 ciphertext |
+---------------------+---------------------------------------------+
| Permitted writers | Sorted writer key identifiers or |
| | public-key commitments in the |
| | signed access rule |
+---------------------+---------------------------------------------+
| Unchangeable field | Access-rule type immutable |
+---------------------+---------------------------------------------+
| Links | Optional signed prior link |
+---------------------+---------------------------------------------+
| Version | 64-bit unsigned integer inside |
| | ToBeSigned |
+---------------------+---------------------------------------------+
Table 10
14. Security Considerations
The encoding MUST be deterministic, since a non-deterministic
encoding breaks the binding between content and name.
The security of a Lumion encoded by this document depends on the
collision resistance of SHA-256, meaning it is infeasible to find two
inputs with the same digest, the unforgeability of Ed25519, meaning
it is infeasible to create a valid signature without the signing key,
the AEAD security of encrypted parts, and the unpredictability of
per-part salts.
All hash invocations in this encoding use a different fixed label for
each hash use, enumerated normatively in Section 6. Implementations
MUST NOT reuse a digest computed with one label as though it were
computed with another, and MUST use the exact label byte strings and
input framing of Section 6; any deviation changes the Lumion name and
breaks interoperability.
A removed part whose salt is disclosed can be vulnerable to
dictionary search if its content is guessable. A holder that redacts
a part MUST redact the salt with the content. A Generator MUST use
fresh salts as specified in Section 9.
AEAD nonce reuse under the same content encryption key breaks
confidentiality and may break integrity. A Generator MUST use a
nonce-generation method that prevents reuse for each encrypted part.
Shearer Expires 24 January 2027 [Page 15]
Internet-Draft Lumion Encoding July 2026
Access rules are enforced by a Verifier that holds the prior version
being updated from. Authority-layer guarantees are described in
[LUMION-AUTHORITY].
15. IANA Considerations
A later revision will register a media type and any code points for
the Lumion encoding.
16. References
16.1. Normative References
[LUMION] Shearer, D., "The Lumion: Self-Contained Data Object
Carrying Its Own Access Control", Work in Progress,
Internet-Draft, draft-shearer-lumion, n.d.,
<https://datatracker.ietf.org/doc/html/draft-shearer-
lumion>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/rfc/rfc4648>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/rfc/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
<https://www.rfc-editor.org/rfc/rfc8439>.
16.2. Informative References
Shearer Expires 24 January 2027 [Page 16]
Internet-Draft Lumion Encoding July 2026
[LUMION-AUTHORITY]
Shearer, D., "The Lumion Authority Layer (work in
progress)", Work in Progress, Internet-Draft, draft-
shearer-lumion-authority, n.d.,
<https://datatracker.ietf.org/doc/html/draft-shearer-
lumion-authority>.
[LUMOSQL] The LumoSQL Project, "LumoSQL", n.d.,
<https://lumosql.org/>.
Acknowledgments
The structure here modernises the byte-layout sketch in the original
Lumions draft, co-authored with Ruben De Smet and Claudio Calvelli,
and builds on the LumoSQL project [LUMOSQL].
Author's Address
Dan Shearer
LumoSQL
Email: dan@shearer.org
URI: https://shearer.org
Shearer Expires 24 January 2027 [Page 17]