The author approved the draft v0.16 on 7 October 2026 with the
recommendation of each of its decisions: the review of v0.15 by Astra, a
seal without accuracy, the key of words in the recovery annex, a full last
chunk of age, the evidence of a signature with certificates and drand's
JSON read strictly. Only the date of the header changes in the text;
spec/README.md records its SHA-256, and annex/recovery.md is written again
with it. The READMEs, SECURITY.md, the traceability, the CDDL header, the
README of testdata and the CHANGELOG name v0.16 and its tag.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The editor had written the escapes of the sources as their characters:
the cases "round escaped as round" and "round twice, once escaped as
round" of release.json had a plain round, and the surrogate pair of
"a surrogate pair in a value" a plain emoji, so the shared vectors tested
no escaped name. TestStrictJSON had lost its escaped é, its pair and the
escape after a lone high surrogate. They are escapes again, and the texts
of words_test.go too, so that no mark or invisible character hides in the
source. release.json gained 26 cases of drand's JSON, not 25 as b570338
says; the draft and the CHANGELOG now say 26.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
SpecVersion is 0.16, and so is the spec field of every file of testdata,
the frozen security_cms.json and locator.json included. annex/recovery.md
is §79 of the draft v0.16, with the key of words in 79.7. The draft lists
the two new fixtures in 67, says in 79 what recovery_check.sh opens, and
names in 76 the tests that now exist. The CHANGELOG has its section.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
scripts/recovery opens a time_and_key capsule with the words of a key of
words (-words FILE), as the annex says in 79.7: the normalization without
tables for the text of the DateKeys lists (printable ASCII, the ASCII
spaces, á é í ó ú ü ñ and their capitals, and the marks U+0300 to U+036F),
and for any other text the full one, NFD, without the marks, simple lower
case and the spaces of 38.1, from UnicodeData.txt of Unicode 18.0.0
(-unicodedata FILE), checked by its SHA-256; then PBKDF2-HMAC-SHA256 of the
standard library. Its tests check both normalizations against every case
of wordkey.json and the two vectors of the annex.
Two fixtures of v0.16: format3_time_and_key_words, opened with the text of
the second vector of the annex, recorded in words_text with the identity it
gives; and format3_full_chunk, whose BODY and P are 65536 bytes, so that
PAYLOAD_AGE ends in a full STREAM chunk (79.5). recovery_check.sh opens
both. wordkey.json gains the text of the annex, also with its marks apart.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
JSON of RFC 8259 in UTF-8 whose value is an object; no object repeats a
name, and names are compared exactly once their escapes are decoded, so
"round" is round and ROUND another name; an escape of a lone surrogate
is malformed; round is a number without sign, fraction or exponent from 1
to 2^53 - 1; signature and randomness are strings (spec v0.16, 47.1). Go's
encoding/json kept the last of two repeated names and matched ROUND to
round. ParseDrandJSON, exported, is the one reader of drand's JSON:
provider/drand reads the answers of the relays with it too. The error
texts do not change.
release.json gains 25 cases of drand's JSON for v0.16.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A valid seal is S4 only when its token carries accuracy and t plus the
accuracy is before round_time; otherwise S5, whose text gives the reason,
the first that holds: sealed after or too close, no accuracy under the BTSP
policy of ETSI EN 319 421 (0.4.0.2023.1.1), or no accuracy (spec v0.16,
29.7, 29.11). The line of a signer of F6 whose seal does not prove it says
so with the same reason. cms.Token gains HasAccuracy, Policy and BTSP;
Verdicts gain SealReason and SignerLine.Reason; EncryptFiles returns the
verdicts of the area it wrote in Result.Security, so that a writer warns of
a seal without accuracy (rule 19).
security_cms.json is made again: 143 cases, the seals about something else
with an accuracy of a second, and the new cases of 64 with seal_reason.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The author chose CC-BY-ND-4.0 over CC-BY-4.0: the specification may be
copied and shared unchanged, with credit; a modified version or a
translation needs the written permission of its author. The recovery
annex, which travels alone next to every capsule, says so in its title.
The code stays Apache-2.0 and the word lists keep their own licenses.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
Spec §38.1: the official SDK SHOULD warn not to reuse a password, since
once the date has come the capsule lets whoever holds it test guesses.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The SHOULDs of the official SDK that the CLI did not follow yet. encrypt
writes next to the .dkc the recovery annex, FILE.dkc.recuperacion.txt
(spec §62.1, rule 27): datekeys.RecoveryAnnex, annex/recovery.md, which is
§79 of the specification under a title with its version and SHA-256, the
same for every capsule; TestRecoveryAnnex checks it against the text of
SpecVersion. -no-recovery leaves it out. encrypt also says what opening the
capsule years later will take (rule 26): the .dkc, a credential of a
time_and_key capsule, and the release of its round, which an archive of
releases or a cache service must keep if drand no longer serves it; and
beyond one year it recommends time_and_key to a time_only capsule (§7.6).
profile.Status and StatusOf give the state of a pinned profile in the
registry of §71, which DateKeys does not publish yet: Quicknet is active.
encrypt writes no capsule with a profile that is not active, and decrypt
and inspect warn when the profile of a capsule is compromised.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
For whoever does not trust the random numbers of a computer, as the author
decided: five dice for each word, read in a fixed order, give a number
from 11111 to 66666, the position of the word in a list of 7776 words, the
first die the most significant. wordkey.DiceNumber and DiceWord number the
words and give the word of a number; DiceWords takes several numbers, at
least 6 and never the same word twice, which is rolled again; DiceList is
the list numbered for dice, a line for each word with its dice and a tab,
as the EFF publishes its own: for en it is the file of the EFF, byte for
byte.
encrypt -dice TEXT and -dice-file FILE take the words from the dice of the
list -dic and show them: the words open the capsule, the numbers give them
only with that list. datekeys wordlist [-dic LIST] writes the numbered
list, to print it, and its SHA-256, which wordkey/lists/README.md records.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
wordkey/lists/en.txt is the large wordlist for passphrases of the EFF,
7776 words, CC BY 4.0 under its copyright policy, without the dice number
of each line and in its order, so that the position of a word still gives
its dice, 11111 for the first. encrypt -new-words takes it by default, as
the author decided; -dic es takes the Spanish one. The alphabet of en is a
to z and the ASCII hyphen of its four compound words, such as t-shirt,
kept so that no word loses its dice. lists/README.md records its source,
the SHA-256 of the download, the change and the license.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The seed of TestGenerate, bytes.Repeat([]byte{7, 1, 200, 33}, 64), only
ever gives indices 1793 and 2081: both calls of Generate ended in EOF, the
test ignored the errors and compared two empty results. It now draws from
a SHA-256 counter stream and checks the errors and the count, draws an
index twice to see that it is drawn again, and keeps the old seed as the
case of a source that runs out. Found by the review of the Dart port.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
wordkey.CheckList takes the language of the list and refuses a word with a
character that is not a letter of its alphabet, which only the code gives:
for es, a to z, the five vowels with an acute accent, u with diaeresis and
n with tilde, in lower case and NFC. A Cyrillic letter that looks like a
Latin one, a capital, a digit or the carriage return of a file with CRLF
lines would be written down and typed again with another character, and
the capsule would not open. The Spanish list passes as it is; its SHA-256
does not change.
wordkey.Bits is the strength of the words that Generate draws, log2 of the
number of draws in order, and encrypt -new-words prints it: 90 bits for 7
words of 7776.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
wordkey.Generate draws words uniformly with crypto/rand from a built-in
list, and encrypt -new-words FILE writes them to a new file (-dic, default
es; -word-count, default 7). wordkey.List and CheckList refuse a list of
fewer than 2048 words or with two words that are one once normalized
(spec 38.1). The Spanish list, 7776 words, is a draft not yet reviewed,
licensed CC BY-SA 4.0 as an adaptation of FrequencyWords; its source,
method and SHA-256 are in wordkey/lists/README.md.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The author approved the draft v0.15 on 7 October 2026, after removing the
.dkr file from it: the long-term recovery of capsules rests on the release
object, archives and cache services of all rounds, a release in hand that
the clock does not stop, and the recovery annex. Only the date of the
header changes here. SpecVersion is 0.15, the records of the fixtures and
the vectors say so, and the frozen security_cms.json and locator.json
change only their spec field. spec/README.md records the SHA-256.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
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>
scripts/recovery is a program that opens a capsule with only the Go
standard library, golang.org/x/crypto, filippo.io/age and the BLS12-381
library of drand/kyber-bls12381, as the informative annex of the draft
v0.15 describes it: the pinned Quicknet parameters, the release object,
the frame, the BLS verification of the release, the tlock stanza with H2,
H3 and H4, the age file of SEALED_CONTROL opened with its file key (HKDF,
header MAC and STREAM written out), the X25519 layers with age, and the
content of formats 1, 2 and 3. A test forbids importing this module, tlock
and drand. scripts/recovery_check.sh opens a time_only and a time_and_key
fixture of format 3 with it and compares what it recovers; scripts/check.sh
runs it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The release of a round becomes a file, .dkr: a release object in
deterministic CBOR, {0: "datekeys-release", 1: 1, 2: chain_hash, 3: round,
4: signature}, which provider.EncodeRelease writes and DecodeRelease reads
with its layers (size, type and version, schema). provider.ParseRelease
also reads drand's JSON as the input of the caller. Verify checks the chain
hash a release names before its round and its signature, with
ERR_PROFILE_MISMATCH. provider.Archive reads a local release archive, the
informative format of the draft.
capsule.OpenOptions.Release takes a release in hand, a provider.Supplier,
exclusive with Source: Open does not compare it with the clock (step 9.c,
option B) and reports a clock behind it in Opened.ClockBehind; a network
source is still never asked before the round time. The CLI gains
decrypt -release FILE (.dkr, drand's JSON or a local archive),
decrypt -save-release FILE.dkr and the command release, which fetches,
verifies and saves the .dkr without opening the capsule.
Test data: vectors/release.json, releases/<round>.dkr for rounds 1000,
1001, 1004 and 2000, and a local archive of rounds 1000 to 1004. In
mutations.json every case says its source, "supplied" or "network"; the
case "round not reached yet", a release in hand, now opens, and four cases
are added: the same with a network source, a release of another round from
a network source, and two release objects of another chain. SpecVersion
stays 0.14 until the author approves the draft.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The traceability table, the READMEs, SECURITY.md and the header comment
of datekeys.cddl still described earlier versions: three drand schemes,
18 normative errors, a CDDL of v0.11 and signed releases that do not exist
yet. No normative text and no schema changes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The author approved the draft v0.14 on 6 October 2026 with the
recommendation of each of its ten decisions; decision 8, one scheme of
drand, is the previous commit. Only the date of the header changes here.
SpecVersion is 0.14, the records of the fixtures and the vectors say so,
and the frozen security_cms.json and locator.json change only their spec
field. spec/README.md records the SHA-256 of the text.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The author approved the draft with its recommendations, decision 8 among
them: section 12.1 admits only the scheme whose verification and tlock
decryption the text now writes byte for byte. profile.Validate refuses the
other two unchained schemes of drand with ERR_UNKNOWN_PROFILE. No pinned
profile and no vector changes; section 76 records it as change 7.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
Spec section 44.1 makes unusable a locator whose round or chain is not that
of its DateKey, and its plaintext is 4096 bytes or a multiple. ParseInfo
checked only the round: it now checks that the chain hash is lower-case
hexadecimal and, for a profile this module pins, the chain of the DateKey;
and that the body after the age header holds a plaintext of 4096 bytes or a
multiple, so that a header without a body is refused. Info.Extension, which
reads what it writes, refuses a DateKey of a profile that is not pinned.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The author approved the draft v0.13 on 6 October 2026, as it stood: only
the date of its header changes. SpecVersion is 0.13, the records of the
fixtures and the vectors say so, and the frozen security_cms.json and
locator.json change only their spec field. spec/README.md records the
SHA-256 of the text, and the READMEs, SECURITY.md, the traceability table,
testdata/README.md and the changelog name v0.13.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Spec v0.12, section 44.1, already asked for the CID in its canonical form
and an IPv6 literal: a CID with a character more, of zero bits, decoded to
the same bytes and passed, and https://[[2000::]/ passed because checkHost
trimmed every bracket. isCIDv1 refuses 5 or more bits left over, and
checkHost takes one pair of brackets.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
On an IPv6-only network with DNS64, a name that has only IPv4 addresses
resolves to an address of NAT64, which spec v0.12, section 44.1, always
rejected: a reader on such a network, as many mobile ones, could not
download the rest of an envelope. The draft v0.13 counts an address of
64:ff9b::/96, or of the NAT64 prefix of the network, by the IPv4 address it
holds (RFC 6052). An address of NAT64 written in a locator is still
rejected. Section 76 records the change with its case.
locator.CheckResolvedIP implements it for the readers that download, and
testdata/vectors/resolved_ip.json gives 42 cases. SpecVersion stays 0.12
until the author approves the draft.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The author approved the draft v0.12 on 6 October 2026, as it stood: only
the date of its header changes, and no normative text is added. SpecVersion
is 0.12, the records of the fixtures and the vectors say so, and the frozen
security_cms.json and locator.json change only their spec field.
spec/README.md records the SHA-256 of the text, and the READMEs, SECURITY.md,
the traceability table, testdata/README.md and the changelog name v0.12.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Spec section 64 of v0.11 asks for the vectors of the key of words, which
were only in the tests of package wordkey. The file has the words of 45
texts, among them each space of section 38.1 and three that are not; what a
writer does with 20 texts, with the text of the error of wordkey.Check; and
6 identities with their recipients, the vector of section 38.1 first. It is
regenerated by genfixtures and checked by TestVectorFilesAreCurrent.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
internal/pathrule/gen -dart renders the Unicode and best-fit tables as
const lists of a Dart library, as -ts does for datekeys-ts: the same data
and the same TablesDigest, with the formatter turned off for the file.
tables.go and the TypeScript module come out unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Section 29.7 said givenName and surname "si tiene uno de cada", and the
organizationName of the issuer "si no tiene" commonName, and left open an
attribute without text. The reference treats it as absent: the holder is
givenName and surname only when both have text that is not empty, and the
issuer falls back to its organizationName when its commonName is absent,
repeated or not text (internal/cms, cert_test.go). The datekeys-ts port
follows it, and the text now says so: "con texto" in 29.7 and in change 3
of section 76. The author decided it on 5 October; no code changes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The text of 44.1 now says what the reference already refused and a
second implementation that followed the text would have accepted:
segments of 1 to 63 characters that neither start nor end with a hyphen,
the scheme in lower case, 0x and the local names in either case, an IPv4
without leading zeros, and a CID of at most 128 characters in canonical
base32, with minimal varints and a digest of at least one byte. A port is
written without leading zeros: the reference accepted 0443 and 00443 and
refused 000443, the same number, and now refuses the three. Change 6 of
section 76 records it, and section 64 lists the cases.
locator.json is made again with 30 more addresses, 247 in all, and
TestAddresses checks the same rules.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- testdata/README.md: the files of v0.11 and of the draft, the spec
label 0.11 until the approval, 26 fixtures with format3_unsigned and
format3_note, security.json in its context with lines, security_cms.json
without the cases of no context, note.json, the new parts of
locator.json, and the corpus of 218 cases, 178 of the spec, with the
eight of the list of v0.11. The release of round 1000 is in the records
and in mutations.json, not in quicknet_rounds.json.
- docs/traceability.md: the cases of section 64 that security_cms.json
and locator.json now hold are no longer pending.
- CHANGELOG: security_cms.json and locator.json under the test data of
the draft, instead of pending.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- uri_cases: the first and the last address of each IPv4 block of 44.1,
with the public addresses next to them; the IPv6 blocks and the
addresses that hold an IPv4 one; the local names; characters outside
RFC 3986 and broken percent signs; "." and ".." segments; base32 that
is not a CID v1.
- mixed: a locator whose http and NAT64 addresses a reader rejects, and
whose third address it uses to find the rest.
- rest_cases: the rest alone, a host with bytes after the rest, a rest
with a byte changed, an offset that is not its own, a rest cut short.
- extension_cases: a locator sealed for round 1001 with a DateKey of
round 1000, and the other data that a reader cannot use.
- plaintext_cases: change 7, the bases 4094, 4070 and 3837 completed to
4096 with an empty key 6 or a length not in its shortest form, and a
defect in each field of the map.
- padding_cases: the bases 3837, 4070, 4094 and 4095 and those of the
next multiple, checked against the rule of 44.1.
The generator checks every case against this module and moves to its
own file. The vector is frozen: delete it to make it again.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A paragraph followed directly by "---" is a setext heading in Markdown,
so the closing paragraphs of sections 70 and 72 rendered as titles. The
other three rules follow list items and rendered right; they get the
blank line too, for one style. Editorial: no text changes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
security_cms.json says 0.11, as every file of testdata, until SpecVersion
moves with the approval of the draft v0.12 whose verdicts it gives; its test
checks SpecVersion. scripts/fuzz.sh runs FuzzDERCheck, FuzzParseSignature,
FuzzParseToken and FuzzParseCert.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The check of a minimal INTEGER in the millis of an accuracy was tested only
with 128 and 999, whose low byte has its high bit set: a check that took
every two-byte value under 0x8000 for one that is not minimal left them
all passing. 300, 01 2c, is minimal and must read.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The frozen vector of alg 2 and seal_type 2, made again with the profile of
v0.12:
- each case carries the lines of Verdicts.Lines, so that a second
implementation compares the texts byte for byte, and its times keep the
fraction of the token;
- the two cases without a context, which gave the verdicts of a reader of
v0.10, are gone, and the case named a seal from before the certificate
was valid, which gave an invalid seal, is named so;
- new cases for each row of §29.7 and each item of the lists of §64 for
v0.11 and v0.12: out of validity with a valid authority, SIGNERS that
break its rule beside a valid CMS (out of order, empty, 17 entries, 31
bytes, a hash twice) and 16 signers, the version against the sid, two
content-type attributes, the ESSCertIDv2, PSS with and without
trailerField, an arc of 2^31, a certificate twice or of version 1, keys
outside the table, every hash and curve of the table, BER, two
SignerInfo of one certificate, two time-stamps, the names of the holder
and of the issuer in each string type and against each rule, and the
edges of the token: accuracy, genTime, ordering, fields after the last,
the imprint, crls and the authority.
The generator checks each case against what the spec gives, written apart
from the code: the verdicts, the result of each signer and the lines,
built from the texts of §29.7. It fails when the reader gives anything
else. capsule reads every field of the file, the lines included.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The builder of the tests, cmstest:
- NewCert writes a certificate from the DER of its tbsCertificate, field by
field: names of any string type with any bytes (UTF8String,
PrintableString with an underscore or an at sign, IA5String,
TeletexString, BMPString of odd length or with a surrogate,
VisibleString, NumericString), an attribute twice or none, no version,
times with a fraction, an extension twice, a compressed EC key, an even
modulus, and any signature. A Signer made so serves Signature and Token.
- Options for the version of a SignerInfo, the hashAlgorithm and the
certHash of an ESSCertIDv2, a signatureAlgorithm other than the one of
the key, a certificate twice, two content-type attributes, an attribute
with an arc of 2^31, a SignerInfo twice, BER, signerInfos out of order,
two signature-time-stamp attributes, and edits of the SignedData and of
each SignerInfo.
- Token options for any accuracy, a genTime of free text, ordering FALSE,
a field after the last, an imprint of any length, no message-digest, a
CRL in crls and the certificate of the authority twice.
- Edits of the DER after signing: Edit, Retag, Withdraw (a SignerInfo
removed), WithoutTimeStamp (a CAdES-T removed), Merge (a co-signature)
and Indefinite.
The tests of internal/cms and internal/der fail for each check of cms.go,
cert.go, verify.go and der.go. A mutation run, which replaces each leaf of
each condition by false and by true, one at a time, kills every mutant
that is not equivalent to the code it mutates.
FuzzParseSignature, FuzzParseToken, FuzzParseCert and FuzzDERCheck, seeded
with security_cms.json and with what cmstest builds: no panic, what Check
accepts Split reads, and the parsers fail only with ErrForm or
ErrAlgorithm.
capsule: the case of a seal outside the validity of the certificate gave
an invalid seal; it now tests a certificate that expired before a valid
seal (out of validity) apart from an authority that was not valid at its
time (invalid seal). SIGNERS out of order, empty, too long, with 31 bytes
or with a hash twice are F1 beside a CMS signature that is valid for the
AUTHOR_MESSAGE of those SIGNERS, and the names of certificates show as
spec v0.12 §29.7 says.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
der.Check refused the universal types 7, 18, 21, 25 and 27
(ObjectDescriptor, NumericString, VideotexString, GraphicString and
GeneralString), which DER writes primitive with their content as it is
(X.690 10.2). A certificate whose name holds one of them, as the INN of a
Russian certificate or the countryCode3n of X.520, made the whole CMS
signature F1, and a token S2, while spec v0.12 §29.10 asks for DER and reads
the name with its profile: any value, which is no text when it is not of
the five string types. Such a certificate now meets the profile; its value
shows as no text.
REAL, RELATIVE-OID, TIME and the reserved tags stay refused: their DER has
rules of its own, and no certificate, signature or token uses them.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
What the update of the documentation found without a test: Header.UnusableNote
and the notice of decrypt, the helper that keeps a panic of a parser of
security in its own part, and that EncryptFiles writes nothing of the
capsule while it waits for a signature (spec 62.1 rules 19 and 25). The
usage text of decrypt -expect-author says that it writes no file.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The session that closed v0.11 left the documentation at v0.10 (review of
2 October, G14).
- README.md and README.es.md say the same again: the reference implements
v0.11, tagged, and the branch v0.12 the draft; SpecVersion 0.11; the area
of 32 KiB in the picture of BODY; the table of modules with authorkey,
internal/cms, internal/der, locator, wordkey and the public note; and what
the CLI does now: encrypt -sign shows the key and the code of
AUTHOR_MESSAGE before it signs, decrypt -expect-author writes nothing
unless the key of an F4 matches, the lines of the verdicts break behind a
mark, and decrypt and inspect say when a public note is not shown. The
security properties no longer say that no signature is checked.
- SECURITY.md: the scope is v0.11 and the draft v0.12; the limits of a
signature, a seal and a key of words; the standard library among the
cryptographic dependencies.
- docs/traceability.md at the draft v0.12: rows for 24.1, 29.8 to 29.12,
38.1 and 44.1, and rows 29.2, 29.3, 29.7, 62.1, 64, 67, 70, 72 and 76 up
to date, with the code and the tests of each. The cases of spec 64 that
security_cms.json and locator.json still lack are marked pending.
- CHANGELOG.md: an entry for the draft v0.12: the review and its fixes, the
draft, the CMS reader with its own profile, the addresses of the locator,
the CLI, the new test data, and what is pending.
- capsule/format3.go: the comments of EncodeSecurityWith,
EncodeAuthorSignature and EncodeSeal no longer say that this version
defines no alg and no seal_type.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
FuzzUnmarshal, FuzzParseInfo and FuzzCheckURI, in scripts/fuzz.sh: no
panic, no usable address that the rules refuse, ERR_EXTENSION_DATA_INVALID
as the only code of the data of datekeys.capsule, and a host shown that is
in the address as written. 40 s each with -parallel 4, clean.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
dev