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>
As the author asks: the rest of the envelope can be stored inside a host
file, an image, a video or any file, and each address of the locator says
at which byte it starts (44.1).
- The envelope is split: its age header, up to the MAC, goes in the
time-locked locator, and only the rest, nonce and STREAM, is stored
outside. Those bytes carry no mark: nobody can tell they are an age
file, let alone a capsule. The reader joins both and decrypts with
I_SOBRE.
- An address is a map with the URI and an optional offset; the reader
asks only for those bytes, with an HTTP range when it can, and checks
their SHA-256.
- Concealment, not steganography: an analysis of the host can see extra
bytes, not what they are. Only storage that keeps the file byte for
byte works; social networks and messaging applications spoil a host.
- The CDDL of the locator follows.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The author drops the list of recognized authorities: a signature is
checked only when the capsule opens, maybe decades later, and a court
or a notary will use the official validator of their country, with the
trust lists of that moment. What matters is that the capsule keeps the
evidence of the moment of signing (signature, certificate, CAdES-T and
OCSP), which it does; a list would never cover every country and adds
no legal value.
- 29.13 and the verdicts F7 and S6 go away. F6 and S4 say that DateKeys
does not check who issued the certificate or the seal, and point to an
official validator; the names come from the certificates.
- A reader may keep an author key received by another channel, but never
offers to keep one from a capsule.
- The text is no longer Spanish only: any country, any signing
application; P-521 joins the table, and brainpool, GOST and SM2 are
named as not supported, as future work.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
As the spec v0.11 draft decides after the review (38.1):
- the salt is "DateKeys llave de palabras v2|chain|round|capsule_id", so
the same words give another key in each capsule and a dictionary
cannot attack together the many capsules of a popular round;
- the words are lowered with the table of Unicode 18.0.0 of pathrule;
- wordkey.Check refuses controls, Default_Ignorable code points and
unassigned ones, and counts toward the six words only the different
ones of three letters or more.
EncryptOptions.Words takes the words: the writer derives their identity
once it has drawn capsule_id, and adds its recipient to the credentials.
The CLI passes them to the writer, and decrypt salts them with the
capsule_id of the capsule. New vector of 38.1.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The author's decisions after the review of 1 October 2026:
- Recognized authorities (29.13): a list pinned in the SDK for the
certificates of signers and for timestamp authorities, checked at the
time of the seal, without revocation. Without it a certificate or a
seal was checked with what it brings itself. New verdicts F7 and S6.
- The key of words is salted with capsule_id too (salt v2), so that the
capsules of a popular round cannot be attacked together; the writer
rejects controls and ignorable code points and should reject short or
repeated words. New vector.
- What is stored outside is an opaque envelope: the .dkc encrypted for a
random identity whose key goes in the time-locked locator, padded to
4096 bytes, with https and ipfs addresses only.
- AUTHOR_MESSAGE is ASCII text of 99 bytes with the digest in hex and an
8-character code to compare before signing.
Fixes from the three reports: SIG_PART over the exact content of key 2
for any alg; one procedure per signer in 29.10, with F1 only for the
shape of what is present; a closed table of OIDs and DER with sorted SET
OF; the token checks its content-type and message-digest; S4 needs
genTime + accuracy before the round; F1 or F2 in 29.9 and the noble text;
alg and seal_type 4294967295 reserved for tests, and the five v0.10
vectors that change verdict listed in 76; the leftovers of v0.10 in
55.1, 27, 63, 72 and 73; the note as one line of the declared author
rules; extension data never gives ERR_NON_CANONICAL_CBOR; what a
certificate signature reveals; blind signing in 7.9; no secrets at rest
while waiting for a signature; the figures of 76.
Co-Authored-By: Claude Opus 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>
dev