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>
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 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 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>
Fixtures format3_signed_cms (alg 2, two certificates, each sealed, F6) and
format3_sealed (alg 1 and a seal of seal_type 2, F4 and S4), with the
certificates, SIGNERS, the commitments, SEAL_SUBJECT, the token and the
result of each signer in their records. vectors/security_cms.json has 22
frozen areas with their context and verdicts (F1, F2, F5, F6, S1 to S5), and
vectors/locator.json the extension datekeys.capsule with its envelope hidden
in a host, its locator sealed with tlock, the padding at the boundaries and
the rules of the addresses. The README of testdata describes all of it.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
dev