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>
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>
Delivery 2 of capsule format 3, with the decisions the author took on
1 October 2026 after the review of Fable and Astra:
- A fixed area of 32 KiB for every capsule of a v0.11 writer, signed or
not, and 64 KiB only when the person enlarges it expressly (29.2).
- What is signed (29.8): AUTHOR_MESSAGE of 66 bytes over control_commit
of CONTROL_SIG, without I_PAYLOAD and with payload_length at zero,
head_digest and signers_digest. The size of the area never changes
what is signed, so the area can grow after signing.
- alg 1, strict Ed25519 with dkauthor1 keys (29.9, 29.12), and alg 2, a
detached CMS signature with one or more X.509 signers, the list of
required signers in key 1 and a CAdES-T timestamp per signer (29.10).
- seal_type 2, an RFC 3161 seal over SEAL_SUBJECT for capsules without a
certificate signature (29.11), and the verdicts F2 to F6 and S3 to S5.
- The key of words (38.1), the public note datekeys.note (24.1) and the
capsule extension datekeys.capsule of the .dkk, with the note, the date
and a locator encrypted for the date (44.1).
- Writer rules 19 to 24, privacy, threat model 7.9, mutation tests,
compatibility with v0.10 readers, the extension registry, provisional
items (the 32 KiB to be measured) and the change log in 76.
The CDDL adds the schemas of alg 1, alg 2, seal_type 2 and the two
extensions. The reference still implements v0.10.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The author authorized the tag on 30 September 2026. spec/README.md, the
two READMEs and the comment of SpecVersion name spec-v0.10 as a tag,
no longer as one to come. The text of the specification and its
SHA-256 do not change.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- 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>
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>
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>
The final review of the draft found 22 problems, and none had been applied
yet. All of them are applied now, together with four places that repeated
them (§62.1 rules 1 and 4, §76 changes 4 and 10).
- §29.1, §76 change 4: 32-bit arithmetic first gives a wrong P at
L = 2 113 929 217 with signed operators and at L = 4 227 858 433 with
>>> 0, not at 2^32 + 1. The vector table gains a row for each, checked
against a BigInt Padme. Above 2^32, Padme exceeds bloque256 except at
L_MAX. The Node log2 error changes E and lastBits, not P or S.
- §56, §76 change 4: a reader MUST NOT present the content as valid before
step 17 ends; a streaming reader MUST NOT write the padding and MUST
signal the step 17 error so that what it wrote is discarded. The author
chose this over the stricter rule, which forbade delivering any byte
before step 17 and so the streaming Open(dst) of the reference.
- §64: the 15 and 17 stanza mutations recalculate the PRELUDE and
header_binding; every time_and_key mutation offers the identity, because
any change breaks the capsule_digest of a .dkk; the duplicate recipient
mutation names its identity. Three new mutations cover the shape of
payload_length (7 or 9 bytes, a CBOR integer); the format 2 cbor.json
vectors of §76 list them too.
- §39, §62.1 rule 4: the official test vectors may show which slots are
dummies. §70, §62.1 rule 1: the format 2 rule binds implementations that
write capsules, and a test vector generator MAY write format 1.
- §62 step 8 gets the 64 MiB limit of §61 step 6.
- Accuracy: §22 (an older reader detects a new padding code only after the
network request; the .dkk schema is §41), §37 and §76 change 10 (the §63
rules do not detect those recipients), §55.2 (the writer knows the number
of parties; relays are §48), §76 changes 1 and 8.
- Wording: §62.1 rules 7 and 11, §63 step 4, §76 change 11, the field names
in the CDDL comments, and a v0.9 entry in spec/README.md.
go test ./... passes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
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>
Amendment of the unreleased v0.8.2, recorded in §76 with its case: the
second implementation's phase-2 research found that tlock-js over
@noble/curves 1.9.7 accepts U re-encoded as c0 + p and a signature
x + p and returns the same file key, while the reference rejects both
(noble 1.9.7 differed from kilic on 5,615 of 41,686 encodings), and the
spec did not say which encodings are valid.
- §12.2 defines the canonical encoding of a BLS12-381 point (drand's
compressed ZCash form) and requires decoders to reject every other
byte string; §12.1 applies it to public_key.
- §63 step 10 applies it to the release signature (ERR_RELEASE_INVALID)
and step 11 defines the tlock stanza body U || V || W (96 + 16 + 16
bytes for Quicknet) with a canonical, non-infinity U (ERR_INTEGRITY).
- §64 gains ten mutations, exported to mutations.json (65 cases). The
signature x + p case uses published Quicknet round 1004, the first
after 1000 whose x allows x + p < 2^381. The reference already gave
every stated code and step.
Errors no longer copy text from tlock, kyber, age, drand or
kyber-bls12381. kyber's IBE error carried the candidate plaintext and r,
and with one bit of W flipped the message disclosed the real tlock file
key with that bit flipped. Every such place now uses a fixed reason with
its normative sentinel; TestTlockFailureDiagnosticsCarryNoSecrets fails
with the old wrapping.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
Extension data becomes a non-empty opaque bstr bounded by the frame of its
container; the base protocol never decodes or validates it. Arrays hold at
most 64 extensions, extension_version is bounded to 2^32-1 and the profile's
period and genesis_time to 2^53-1. The multiplicity exception is removed,
ERR_EXTENSION_DATA_INVALID is added, the §57 limits become MUST with an
explicit error mapping, §58 names the protocol's CBOR profile and §72 sets
the registration rules. §76 records the six reproducible cases behind the
change. The implementation follows in the next commit.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
dev