DateKeys/spec

Specification

• DateKeys_Protocol_Specification_v0.8.2.md: frozen copy of the normative draft v0.8.2 (28 September 2026), tagged spec-v0.8.2. SHA-256: 5cfa32034ea2ba02e77676e015cad7bba09796383afdda6634aaa017a5a23351. v0.8.2 replaces v0.8.1 with a normative change to extensions, refined before release (error precedence, trust model, extension order, and rules the reference had applied without normative text), amended (the canonical encoding of BLS12-381 points and the tlock stanza body) and corrected in two rounds of a formal review (an invalid release from a network source, the objects and arrays where each extension may appear, which an encoder must respect, the serialization of GT in the tlock H2, and a single code for any failure of a release source), all recorded with their reproducible cases in the specification's §76.
• DateKeys_Protocol_Specification_v0.9.md: frozen copy of the normative draft v0.9 (29 September 2026), approved by its author on that date and tagged spec-v0.9. SHA-256: 36189e1e62f0f835b7665219aa63df7200cd89ac4e4e924f2705f970fa7c40a9. It adds capsule format 2, which hides until the unlock date the exact length of the content (the payload is padded) and the number of credentials (always 16 X25519 stanzas), and it makes the writer rules normative. A v0.9 reader still opens format 1, the format of v0.8.2. Its §76 records each change with its reproducible case.
• DateKeys_Protocol_Specification_v0.10.md: frozen copy of the normative draft v0.10 (30 September 2026), approved by its author on that date and tagged spec-v0.10. SHA-256: 7f26419a444aa3e89a3aa8afbbba9d952af69e048aee1e93cd70732c2d1d99d1. It adds capsule format 3, which stores several files with their paths, sizes, hashes and dates, encrypted, and reserves the security area for an author signature and a timestamp seal that later versions will define without changing the format. Its §76 records each change with its reproducible case.
• DateKeys_Protocol_Specification_v0.11.md: frozen copy of the normative draft v0.11 (1 October 2026), approved by its author on that date and tagged spec-v0.11. SHA-256: 25cf1039d16666199c662e88e838a1d2ef0507be68e17fecd9aeee5d85a5bb6e. It defines the author signature of format 3, with an Ed25519 key of one's own or with X.509 certificates (CMS, one or several signers, a CAdES-T timestamp each), the RFC 3161 seal, a fixed area of 32 KiB, the key of words, the public note and the capsule extension of the .dkk. Its §76 records each change with its reproducible case.
• DateKeys_Protocol_Specification_v0.12.md: frozen copy of the normative draft v0.12 (6 October 2026), approved by its author on that date and tagged spec-v0.12. SHA-256: afc31fd8105d650773d093ac01bd2f5e0b56af04726f4e75c652e2cf9308ac3f. It changes no format: it fixes what the review of the implementation of v0.11 found, the names of certificates and the warning of the seal in the verdicts, a profile of the certificate field by field, the addresses and the padding of the locator, and errata. Its §76 records each change with its case.
• DateKeys_Protocol_Specification_v0.13.md: frozen copy of the normative draft v0.13 (6 October 2026), approved by its author on that date and tagged spec-v0.13; this module implements it. SHA-256: 796f176f51119e287211428496b0d30fd8f941617780c5a5d2954243431fdaaf. It changes no format and no verdict: the IP address that the name of a locator resolves to may be an address of NAT64 whose IPv4 address inside is public, so that a reader on an IPv6-only network downloads the rest of an envelope. Its §76 records the change with its case.
• datekeys.cddl: the CBOR schemas of v0.13, the same as those of v0.12, the three control versions and the security and head objects of format 3 included, with the encoding rules CDDL cannot express. Those of v0.9 and v0.8.2 are at the tags spec-v0.9 and spec-v0.8.2.

The specification is licensed under the Creative Commons Attribution 4.0 International License (CC-BY-4.0): https://creativecommons.org/licenses/by/4.0/. The code of this repository is licensed separately under Apache-2.0.

Changes to the specification follow its §76: a normative change should answer a reproducible case found through the reference implementation, the CDDL, a fixture, a mutation test, an interoperability test, fuzzing, a second implementation or an external review.