Initial implementation of the DateKeys Protocol v0.8.1
Reference implementation in Go, built from the implementation plan
(milestones M0 to M5): datekey, profile, provider, codec, agewrap,
extension, capsule, accesskey, the datekeys CLI, official vectors and
fixtures, the mutation corpus, fuzz targets, interop and live tests,
CI workflows, traceability and policy documents.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2 weeks ago
# Specification
- `DateKeys_Protocol_Specification_v0.8.2.md` : frozen copy of the normative
Implement capsule format 2 of spec v0.9
The reference moves to the DateKeys Protocol Specification v0.9, approved
by its author on 29 September 2026. Encrypt writes capsule format 2 only;
Open and Inspect read formats 1 and 2, and a format 1 capsule keeps the
verdict v0.8.2 gave it.
Format 2 (spec §22, §29.1, §31, §39):
- VERSION in the PRELUDE is the capsule format, capsule.Format; any other
value is ERR_UNSUPPORTED_VERSION at step 2.
- CONTROL_CBOR has the schema version of its format. Version 2 adds key 6,
payload_length (8 bytes, big-endian, at most L_MAX = 2^53 - 2^46), and
key 7, padding (1 bloque256, 2 reforzado); it is 103 bytes without
extensions, whatever L.
- The payload is the content padded with zeros to P = rule(L). Step 17
checks the length and the zeros, and Open writes only the first L bytes.
- INNER_ACCESS_AGE holds exactly 16 X25519 stanzas: 1 to 16 credentials,
and a dummy in each slot left, in a uniformly random order.
Writer rules (spec §62.1): EncryptOptions.Length is required and the
source must deliver exactly that many bytes; recipients that are not
canonical or of low order are rejected (agewrap.CheckX25519Recipient);
self-checks of the header, the control, INNER_ACCESS_AGE and PAYLOAD_AGE.
The CLI measures its input, takes -padding and reports the format.
Test data: seven format 2 fixtures, padding vectors checked against
math/big, format 2 CBOR vectors, and the mutation corpus in both formats
with the 22 cases of the third list of spec §64, built without randomness
by sealing the fixtures again with their known keys and nonces. The
format 1 fixtures are kept byte for byte and never regenerated; the
differential corpus keeps its 1825 cases and adds a block per format 2
fixture. The spec copy loses its "to be implemented" markers, and the
READMEs, CHANGELOG, traceability and testdata/README.md follow v0.9.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1 week ago
draft v0.8.2 (28 September 2026), tagged `spec-v0.8.2` . SHA-256:
Spec v0.8.2: second-round corrections from the formal review
The second round of the formal review confirmed the nine corrections of
c57ed48 and asked for these, recorded in §76 as corrections 4 to 6 and
an editorial note:
- §72: an encoder MUST NOT write a registered extension in an object or
array it is not registered for; §54: a reader MUST NOT interpret the
data of a noncritical one it ignores for that reason. capsule.Encrypt
and accesskey.Encode take no Registry, so the application applies the
rule; their documentation and extension.Placement say so.
- §17 and §51 give the step-10 codes only for a directly supplied
release, as step 10 does; a network source discards a failing one at
step 9.
- Step 9 reports ERR_RELEASE_UNAVAILABLE and no other code, whatever the
failure of the source. provider/drand.Client keeps each relay's failure
as text only (errors.Join made a relay's ERR_ROUND_MISMATCH match with
errors.Is), and capsule.Open keeps only the text of a source error that
carries another code (a caller's source failing with
ERR_RELEASE_INVALID gave that code at step 9). A context that ended
stays detectable: Fetch now has a single failure path, so the canceled
and deadline cases are deterministic.
- TestExtensionPlacement covers the noncritical array of a .dkk: with
the object-blind extension.CheckNoncritical at step 9.a it fails.
- Editorial: §28.1 "analizan solo la cabecera age", one arrow at step 9,
two §76 introductions; §73 lines for release sources and placement.
- testdata/README.md says the corpus registers its extensions in both
arrays of every object; traceability, CHANGELOG and both READMEs
(integrity holds against whoever lacks the file keys, §27, §55.1)
follow. Spec dated 28 September 2026; new SHA-256 in spec/README.md.
No fixture or vector changes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1 week ago
`5cfa32034ea2ba02e77676e015cad7bba09796383afdda6634aaa017a5a23351` .
v0.8.2 replaces v0.8.1 with a normative change to extensions, refined
Spec v0.8.2 refinements: error precedence, trust model, strict order
Approved refinements, each recorded with its reproducible case in the
§76 v0.8.2 subsection:
- §69.1: layered error model with normative precedence (frame, type tag
and version, CBOR profile and CDDL, then fields with their own code in
ascending key order; across steps the §63 order decides), with a scope
paragraph for the optional steps 5, 6 and 8.
- §55.1: normative trust table per section (who can write it, from which
step it is bound, what it never proves); §72: security-relevant claims
go in CONTROL_CBOR or under a signature, .dkk data is advisory.
- §31/§54: extension arrays in strictly ascending unsigned byte order of
extension_id (one rule for order and uniqueness).
- Gaps a second implementation needed: §28.1 malformed age headers,
§15/§19 latest unlock time and dk1_ reading rules, §22/§23/§57 length
lower bounds, §63 step 8 tlock argument comparison and step 9 order,
§12.1 profile validation with the drand chain-hash formula, §74 table
of implementation limits.
Reference alignment: .dkk errors only at step 9.a (new
OpenOptions.AccessKeyFile, used by the CLI), CR/LF in dk1_ is
ERR_DATEKEY_INVALID, BODY_LEN 0 is ERR_INTEGRITY, nil identities are not
credentials, and AccessIdentity tries every identity on every stanza so
its verdict does not depend on their order. dk1.json gains three
vectors; every other testdata file is byte-identical.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2 weeks ago
before release (error precedence, trust model, extension order, and rules
Spec v0.8.2: corrections from the formal review
A formal review of the whole v0.8.2 text found it approvable after
these corrections, recorded in §76 ("Correcciones de la revisión
formal"):
- §27 no longer calls header_binding the authenticity of PUBLIC_HEADER:
it binds the header to the opened control, never authorship or date
(§55.1); the age MAC only protects against whoever lacks the file key.
- §63 steps 9 and 10: a network source (relay, Release API, cache) MUST
verify every response and gives ERR_RELEASE_UNAVAILABLE at step 9 when
none verifies; the step-10 codes are for a directly supplied release.
The reference already behaved so; TestReleaseFromANetworkSource pins
both paths.
- §54 and §72: registrations declare the objects and arrays where an
extension may appear, and a known extension out of place counts as
unknown there. The reference gains the optional extension.Placement
interface, used at steps 4, 9.a and 14.
- §63 step 11 fixes the GT serialization hashed by H2 (kilic/kyber order)
with the frozen vector H2(e(G1, G2))[:16] = cb87319f..., shared as
testdata/vectors/tlock_ibe.json; H2-H4 are cited to drand/kyber.
- Step 5 makes the SEALED_CONTROL read mandatory, step 15 names
ERR_HEADER_BINDING, §21 makes capsule_id 16 CSPRNG bytes a MUST, §76
is made accurate (four dk1.json vectors, the §36 time_only rule, two
cases rewritten against the texts that really existed), and editorial
fixes in §5, §36, §55.1, §69.1 and §77. §73 lists the three new
decisions.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2 weeks ago
the reference had applied without normative text), amended (the canonical
Spec v0.8.2: second-round corrections from the formal review
The second round of the formal review confirmed the nine corrections of
c57ed48 and asked for these, recorded in §76 as corrections 4 to 6 and
an editorial note:
- §72: an encoder MUST NOT write a registered extension in an object or
array it is not registered for; §54: a reader MUST NOT interpret the
data of a noncritical one it ignores for that reason. capsule.Encrypt
and accesskey.Encode take no Registry, so the application applies the
rule; their documentation and extension.Placement say so.
- §17 and §51 give the step-10 codes only for a directly supplied
release, as step 10 does; a network source discards a failing one at
step 9.
- Step 9 reports ERR_RELEASE_UNAVAILABLE and no other code, whatever the
failure of the source. provider/drand.Client keeps each relay's failure
as text only (errors.Join made a relay's ERR_ROUND_MISMATCH match with
errors.Is), and capsule.Open keeps only the text of a source error that
carries another code (a caller's source failing with
ERR_RELEASE_INVALID gave that code at step 9). A context that ended
stays detectable: Fetch now has a single failure path, so the canceled
and deadline cases are deterministic.
- TestExtensionPlacement covers the noncritical array of a .dkk: with
the object-blind extension.CheckNoncritical at step 9.a it fails.
- Editorial: §28.1 "analizan solo la cabecera age", one arrow at step 9,
two §76 introductions; §73 lines for release sources and placement.
- testdata/README.md says the corpus registers its extensions in both
arrays of every object; traceability, CHANGELOG and both READMEs
(integrity holds against whoever lacks the file keys, §27, §55.1)
follow. Spec dated 28 September 2026; new SHA-256 in spec/README.md.
No fixture or vector changes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1 week ago
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
Format 3, step 8: fuzzing of format 3 and the SHA-256 of spec v0.10
- Three fuzz targets, in scripts/fuzz.sh too: FuzzDecodeHead (a head
that is accepted re-encodes to its input, and a rejection carries one
normative code), FuzzEvaluateSecurity (verdicts of this version, X for
both or for neither) and FuzzCheckPath (the rules of one entry and the
decoder of the head agree on every path). About a million runs each,
clean; scripts/check.sh 60s is clean.
- Spec v0.10, section 67: the fixtures of format 3 exist, so "Serán ...
(por implementar)" reads "Son ...", as for those of format 2. No rule
changes.
- spec/README.md: v0.10 approved by its author on 30 September 2026 and
implemented on this branch, with the SHA-256 of its text; the tag
spec-v0.10 waits for the author.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1 week ago
tagged `spec-v0.9` . SHA-256:
`36189e1e62f0f835b7665219aa63df7200cd89ac4e4e924f2705f970fa7c40a9` .
It adds capsule format 2, which hides until the unlock date the exact
Implement capsule format 2 of spec v0.9
The reference moves to the DateKeys Protocol Specification v0.9, approved
by its author on 29 September 2026. Encrypt writes capsule format 2 only;
Open and Inspect read formats 1 and 2, and a format 1 capsule keeps the
verdict v0.8.2 gave it.
Format 2 (spec §22, §29.1, §31, §39):
- VERSION in the PRELUDE is the capsule format, capsule.Format; any other
value is ERR_UNSUPPORTED_VERSION at step 2.
- CONTROL_CBOR has the schema version of its format. Version 2 adds key 6,
payload_length (8 bytes, big-endian, at most L_MAX = 2^53 - 2^46), and
key 7, padding (1 bloque256, 2 reforzado); it is 103 bytes without
extensions, whatever L.
- The payload is the content padded with zeros to P = rule(L). Step 17
checks the length and the zeros, and Open writes only the first L bytes.
- INNER_ACCESS_AGE holds exactly 16 X25519 stanzas: 1 to 16 credentials,
and a dummy in each slot left, in a uniformly random order.
Writer rules (spec §62.1): EncryptOptions.Length is required and the
source must deliver exactly that many bytes; recipients that are not
canonical or of low order are rejected (agewrap.CheckX25519Recipient);
self-checks of the header, the control, INNER_ACCESS_AGE and PAYLOAD_AGE.
The CLI measures its input, takes -padding and reports the format.
Test data: seven format 2 fixtures, padding vectors checked against
math/big, format 2 CBOR vectors, and the mutation corpus in both formats
with the 22 cases of the third list of spec §64, built without randomness
by sealing the fixtures again with their known keys and nonces. The
format 1 fixtures are kept byte for byte and never regenerated; the
differential corpus keeps its 1825 cases and adds a block per format 2
fixture. The spec copy loses its "to be implemented" markers, and the
READMEs, CHANGELOG, traceability and testdata/README.md follow v0.9.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1 week ago
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
Spec v0.11 approved: the text of the review, SpecVersion 0.11 and its SHA-256
The author approved the text and the six open decisions on 1 October 2026.
The spec says now what the review left open: the form of the CMS signature
and of the TSTInfo field by field, the ESSCertIDv2 with SHA-256 written, the
padding of the locator at its boundaries, base32 CIDs, the addresses read
without decoding, the issuer shown by the rules of the holder, and the area
decided after the signatures. SpecVersion is 0.11, the records of fixtures
and vectors say so, and decrypt shows an mtime later than a valid seal as an
inconsistency, which 29.7 asks as a SHOULD.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
6 days ago
tagged `spec-v0.10` . SHA-256:
Format 3, step 8: fuzzing of format 3 and the SHA-256 of spec v0.10
- Three fuzz targets, in scripts/fuzz.sh too: FuzzDecodeHead (a head
that is accepted re-encodes to its input, and a rejection carries one
normative code), FuzzEvaluateSecurity (verdicts of this version, X for
both or for neither) and FuzzCheckPath (the rules of one entry and the
decoder of the head agree on every path). About a million runs each,
clean; scripts/check.sh 60s is clean.
- Spec v0.10, section 67: the fixtures of format 3 exist, so "Serán ...
(por implementar)" reads "Son ...", as for those of format 2. No rule
changes.
- spec/README.md: v0.10 approved by its author on 30 September 2026 and
implemented on this branch, with the SHA-256 of its text; the tag
spec-v0.10 waits for the author.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1 week ago
`7f26419a444aa3e89a3aa8afbbba9d952af69e048aee1e93cd70732c2d1d99d1` .
It adds capsule format 3, which stores several files with their paths, sizes,
Spec v0.10 draft, work in progress (not approved)
Delivery 1 of capsule format 3, as the author decided on 30-09-2026:
several files with their paths, sizes, SHA-256 and dates, encrypted in
the plaintext of PAYLOAD_AGE, and a security area that later versions
will fill with an author signature and a timestamp seal without
changing the format.
- VERSION 3 and CONTROL_CBOR schema 3; writers write only format 3,
readers open the three formats.
- BODY with a 12-byte frame (AREA_LEN, SECURITY_LEN, HEAD_LEN), the
security area fixed by spec version (512 bytes here), the head and
the files (new sections 29.2 to 29.7).
- The head is always version 1 in format 3; path rules R1 to R10 on
pinned Unicode 17.0.0 and WindowsBestFit tables; text rules; the
verdicts X, F0, F1, S0, S1 and S2 and their presentation.
- Step 17 split into 17.1 to 17.8 with its precedence, and the new
code ERR_HEAD_INVALID.
- Atomic delivery of several files (56), limits (57), writer rules 13
to 18, mutation tests, fixtures and the change log in 76.
- The CDDL gains control-v3, security, author-signature, seal, head and
file.
The reference implementation still implements v0.9. The design, its
reviews and the author's decisions are in the private docs repository,
spec_v0.10/formato3_diseno.md.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1 week ago
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.
Spec v0.11 approved: the text of the review, SpecVersion 0.11 and its SHA-256
The author approved the text and the six open decisions on 1 October 2026.
The spec says now what the review left open: the form of the CMS signature
and of the TSTInfo field by field, the ESSCertIDv2 with SHA-256 written, the
padding of the locator at its boundaries, base32 CIDs, the addresses read
without decoding, the issuer shown by the rules of the holder, and the area
decided after the signatures. SpecVersion is 0.11, the records of fixtures
and vectors say so, and decrypt shows an mtime later than a valid seal as an
inconsistency, which 29.7 asks as a SHOULD.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
6 days ago
- `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:
Spec v0.11 approved: the text of the review, SpecVersion 0.11 and its SHA-256
The author approved the text and the six open decisions on 1 October 2026.
The spec says now what the review left open: the form of the CMS signature
and of the TSTInfo field by field, the ESSCertIDv2 with SHA-256 written, the
padding of the locator at its boundaries, base32 CIDs, the addresses read
without decoding, the issuer shown by the rules of the holder, and the area
decided after the signatures. SpecVersion is 0.11, the records of fixtures
and vectors say so, and decrypt shows an mtime later than a valid seal as an
inconsistency, which 29.7 asks as a SHOULD.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
6 days ago
`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
Spec v0.12 draft and the verdicts of a certificate (not approved)
The draft v0.12 fixes what the review of the implementation of v0.11
found, without changing any format: the names of certificates in the
verdicts, the seal of each signer in the lines of F6 with the warning that
nobody checks who issued it, the holder by givenName and surname before
the commonName that carries the NIF, a profile of the certificate field by
field, identifiers by their bytes, repeated elements of a SET OF, the
edge cases of the token, the addresses and the padding of the locator, and
the errata of 44.1, 55.2, 64, 67 and 76. Section 76 lists each change with
its case. The CDDL fixes the sizes of the locator.
The reader shows the names of certificates between quotes, refuses one of
more than 64 code points or with two spaces in a row, names the authority
of each seal of F6 and adds the warning when a line says before the date,
and writes the result of a foreign signer in Spanish. The records of
format3_signed_cms and format3_sealed follow.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
6 days ago
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` . 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_Protocol_Specification_v0.14.md` : frozen copy of the normative
draft v0.14 (6 October 2026), approved by its author on that date and
tagged `spec-v0.14` . SHA-256:
`390922135931dd61a263ed90259c7a978b5d92944405e641e94cc194f84fb459` .
It changes no format and no verdict of a Quicknet capsule, and admits only
the scheme of Quicknet in a Provider Profile: it writes down what the completeness review of
Spec v0.14 draft: what is not guaranteed, the provider, the root of trust
The draft writes down what the completeness review of 6 October 2026 found
missing, and changes no format and no verdict: what the protocol does not
guarantee, the provider and the states of a profile, signatures and seals
against a quantum adversary, the web client, the entropy of a key of words,
and errata of section 76. Steps 10 and 11 of section 63 now give the root
of trust byte for byte, as the three implementations apply it: the message
a Quicknet round signs, its hash to G1 with its DST, and H2, H3 and H4 of
the tlock IBE. testdata/vectors/tlock_steps.json gives every intermediate
value for four published rounds, checked against drand, kyber and tlock.
SpecVersion stays 0.13 until the author approves the draft.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1 day ago
6 October 2026 found missing (what the protocol does not guarantee, the
provider, quantum risk to signatures, the web client, the entropy of a key
of words, the states of a profile) and the root of trust byte for byte:
the message a Quicknet round signs, its hash to G1, and H2, H3 and H4 of
the tlock IBE. Its §76 records each change with its case.
- `DateKeys_Protocol_Specification_v0.15.md` : frozen copy of the normative
draft v0.15 (7 October 2026), approved by its author on that date and
tagged `spec-v0.15` . SHA-256:
`45105e693be4187af4dd30f4d254402612587b6427c746f5d29f07a541c1e3f3` .
It covers the
Spec v0.15 draft: remove the .dkr file
The author's decision of 7 October 2026. A release saved next to a capsule
cannot exist when the capsule is made, and once the date comes the capsule
can be opened: such a file only opens it again and does not cover the real
case, someone opening it decades later when drand is gone and nobody saved
anything. Long-term recovery rests instead on archives and cache services
that keep the releases of all rounds; a reader asks for its round and
verifies the signature against the pinned key.
Spec: the .dkr extension (section 20, back to v0.14), sections 1, 4, 8, 45,
47.1, 49, 50 (rewritten), 53, 62.1 (rule 28 removed, rule 26 reworded),
63, 70, 73, 74 (the datekeys.release .dkk extension dropped too), 76
(the v0.15 block, with the discarded design) and the annex 79. The
release object, the chain hash at step 10, step 9.c option B and the
archive format stay.
Code: decrypt -save-release and the command datekeys release are gone,
with writeRelease and their tests; decrypt -release FILE stays. The
release objects of testdata/releases are now <round>.cbor, and
TestVectorFilesAreCurrent fails on a file the generator no longer writes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
21 hours ago
long-term recovery of capsules: the release object, the release of a
round as data, the answer of the Release API and an entry of a cache
(§47.1), with its chain hash checked at step 10; step 9.c only before a
network request, so that a release in hand is not compared with the clock;
long-term recovery resting on archives and cache services that keep the
releases of all rounds, with the release archive as an informative format
(§50); what the SDK warns about and keeps (§62.1); and an informative annex (§79) to open a capsule without DateKeys
Spec v0.15 draft: the release object, step 9.c and the recovery annex
The draft writes down the long-term recovery of capsules with the eight
decisions the author took on 6 October 2026. Section 47.1, new, defines
the release object, the content of a .dkr file: deterministic CBOR
without a frame, the chain identified by its chain_hash, from 1 to 1024
bytes, with drand's JSON still accepted as input. Step 10 checks its
layers and its chain hash before the round and the signature, with no new
code. Step 9.c applies only before a network request: a release in hand,
from a .dkr, drand's JSON or a local archive, is not compared with the
clock. Section 45 keeps the Release API with the object as its answer and
its HTTP form informative; section 50 makes the .dkr next to the .dkc the
main path and describes the release archive as an informative format;
sections 53 and 62.1 say what the writer and the SDK keep; section 79, an
informative annex, opens a capsule without DateKeys software. Section 74
drops the two items now covered, and section 76 records six changes with
their cases. datekeys.cddl adds the rule release. SpecVersion stays 0.14.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
22 hours ago
software. It changes no format of `.dkc` or `.dkk` , and one verdict: a
valid release in hand opens a capsule with a clock behind its round time.
Its §76 records each change with its case.
- `DateKeys_Protocol_Specification_v0.16.md` : frozen copy of the normative
draft v0.16 (7 October 2026), approved by its author on that date and
tagged `spec-v0.16` ; this module implements it. SHA-256:
`807d4fe85ac09ad6f97abc75ab3e2156bb2f3fb0dc589777f4420627fad545e1` . It fixes what Astra's
Spec v0.16 draft: Astra's review of v0.15
A valid seal without accuracy no longer proves that it came before the
unlock date: S5, with its reason, and a reason of its own for a token of
the ETSI BTSP policy (29.7, 29.11). The recovery annex derives a key of
words without DateKeys software (79.7, new): a recipe without tables for
the letters of the DateKeys lists, and UnicodeData.txt of Unicode 18.0.0,
named by its SHA-256, for any other text, with two vectors. The last chunk
of an age file may be full (79.5). A signature with certificates keeps the
chains without their roots and the OCSP responses that fit, and the writer
says what it leaves out (29.10, rules 21 and 22). drand's JSON is read
strictly: no repeated names, exact names after their escapes, an integer
round from 1 to 2^53 - 1 (47.1). Errata in 1, 74, 77 and 79.
No format changes. SpecVersion stays 0.15 until the author approves.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
5 hours ago
review of v0.15 found: a valid seal without `accuracy` no longer proves
that it came before the unlock date (S5, with its reason); the recovery
annex derives a key of words without DateKeys software, with a recipe
without tables for the letters of the DateKeys lists and `UnicodeData.txt`
of Unicode 18.0.0, named by its SHA-256, for any other text; the last
chunk of an `age` file may be full; a signature with certificates keeps
the chains without their roots and the OCSP responses that fit, and the
writer says what it leaves out; and drand's JSON is read strictly, with no
repeated names, exact names and an integer round. It changes no format.
Its §76 records each change with its case.
- `datekeys.cddl` : the CBOR schemas of v0.16, the same as those of v0.15: those of v0.12, v0.13 and v0.14 with the rule `release` added, the three control
Spec v0.10 draft, work in progress (not approved)
Delivery 1 of capsule format 3, as the author decided on 30-09-2026:
several files with their paths, sizes, SHA-256 and dates, encrypted in
the plaintext of PAYLOAD_AGE, and a security area that later versions
will fill with an author signature and a timestamp seal without
changing the format.
- VERSION 3 and CONTROL_CBOR schema 3; writers write only format 3,
readers open the three formats.
- BODY with a 12-byte frame (AREA_LEN, SECURITY_LEN, HEAD_LEN), the
security area fixed by spec version (512 bytes here), the head and
the files (new sections 29.2 to 29.7).
- The head is always version 1 in format 3; path rules R1 to R10 on
pinned Unicode 17.0.0 and WindowsBestFit tables; text rules; the
verdicts X, F0, F1, S0, S1 and S2 and their presentation.
- Step 17 split into 17.1 to 17.8 with its precedence, and the new
code ERR_HEAD_INVALID.
- Atomic delivery of several files (56), limits (57), writer rules 13
to 18, mutation tests, fixtures and the change log in 76.
- The CDDL gains control-v3, security, author-signature, seal, head and
file.
The reference implementation still implements v0.9. The design, its
reviews and the author's decisions are in the private docs repository,
spec_v0.10/formato3_diseno.md.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1 week ago
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` .
Initial implementation of the DateKeys Protocol v0.8.1
Reference implementation in Go, built from the implementation plan
(milestones M0 to M5): datekey, profile, provider, codec, agewrap,
extension, capsule, accesskey, the datekeys CLI, official vectors and
fixtures, the mutation corpus, fuzz targets, interop and live tests,
CI workflows, traceability and policy documents.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2 weeks ago
The specification is licensed under the Creative Commons
Attribution-NoDerivatives 4.0 International License (CC-BY-ND-4.0):
< https: / / creativecommons . org / licenses / by-nd / 4 . 0 / > . It may be copied and shared
unchanged, with credit; a modified version or a translation needs the written
permission of its author. The recovery annex, `annex/recovery.md` , is §79 under
a title and carries the same license. The code of this repository is licensed
separately under Apache-2.0, and the word lists of `wordkey/lists` keep their
own licenses (`wordkey/lists/README.md`).
Initial implementation of the DateKeys Protocol v0.8.1
Reference implementation in Go, built from the implementation plan
(milestones M0 to M5): datekey, profile, provider, codec, agewrap,
extension, capsule, accesskey, the datekeys CLI, official vectors and
fixtures, the mutation corpus, fuzz targets, interop and live tests,
CI workflows, traceability and policy documents.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2 weeks ago
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.
