feat: ML-DSA-65, did:key, named hash algorithm, model provenance, log tiles and witnesses
- hashing.algorithm names the hash function in every document; a consumer refuses one it does not implement (doc.hash.algorithm) - ML-DSA-65 (FIPS 204) is an implemented signature scheme: pure-Python reference in tools/oracle/mldsa.py checked against NIST ACVP vectors, a receipt signed by the new roster key dana, and signature vectors for key generation and a deterministic signature - roster keys may carry a did:key, which the validator checks against the public key (doc.roster.did), and a witness purpose for parties that cosign log checkpoints - model provenance: a correction's author and an annotation's generator name the model with provider, version and the hashes of its weights, prompt and parameters, and where it ran - the transparency log gains the tlog-tiles static layout (fixtures/records/log/), a project settings.log with origin, witnesses and threshold, and an acceptance rule; the fixture checkpoint is cosigned by a witness - store.sql: roster_keys accepts cose and ml-dsa-65 and gains a did column - spec chapters 01, 08, 11, 18, 20 and 23, the rationale, glossary, fixture, vector and tool guides updated; stress harness covers ML-DSA Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
127 files changed
+996
-141
No files matched your search
+14
-3
@@ -38,8 +38,9 @@ The key hash is the first four bytes of SHA-256 of the signer's name, a newline,
|
||||
A note parsed into JSON has `format`, `origin`, `size`, `root` as hex, `signatures` as `{name, key_hash, value}` and the `note` text itself; the schema is `checkpoint.schema.json`.
|
||||
`checkpoint.jsonl` gives a checkpoint over the example paper's receipts and its verification.
|
||||
|
||||
A checkpoint may carry further signature lines from witnesses, independent parties that cosign only a checkpoint consistent with every earlier one they saw.
|
||||
A checkpoint may carry further signature lines from witnesses: roster keys with the `witness` purpose, held by independent parties, that cosign only a checkpoint consistent with every earlier one they saw.
|
||||
A verifier that holds two checkpoints of one log checks a consistency proof between them ([11.5](11-corrections.md#115-the-history-root)); a log that cannot produce one has rewritten its past.
|
||||
A project accepts a checkpoint when its origin is the project's log, a key with the role `owner` and the `sign` purpose signed it, and at least the project's `threshold` of its listed witnesses cosigned it ([20](20-projects.md)); `fixtures/records/log/checkpoint` is signed by the team and one witness.
|
||||
|
||||
## 23.3 What a log settles
|
||||
|
||||
@@ -53,5 +54,15 @@ Without a log the rules of [8.6](08-fidelity.md#86-receipt-status) stand, and th
|
||||
|
||||
## 23.4 Serving a log
|
||||
|
||||
A log is served as tiles, the layout transparency logs share, so that clients fetch only the subtrees they need and a static file server can host a log.
|
||||
The tile layout and the exact URL scheme are left to the first deployment; this chapter fixes only the entries, the tree and the checkpoint, which any layout must preserve.
|
||||
A log is served as static files in the tile layout transparency logs share, so that a client fetches only the subtrees it needs and any file server can host a log.
|
||||
|
||||
| Path | Holds |
|
||||
| --- | --- |
|
||||
| `checkpoint` | The latest checkpoint note ([23.2](#232-checkpoints)). |
|
||||
| `tile/<L>/<N>` | Hash tile N of level L: the 32-byte hashes of the 256 complete subtrees of 256^L entries each that the tile covers, in order. Level 0 holds the leaf hashes. |
|
||||
| `tile/<L>/<N>.p/<W>` | The rightmost, partial tile of level L, holding W hashes. |
|
||||
| `tile/entries/<N>` and `tile/entries/<N>.p/<W>` | The entries themselves, 256 to a tile, as canonical JSON Lines. |
|
||||
|
||||
N is written as 3-digit groups, every group but the last prefixed `x`: tile 1234067 is `tile/0/x001/x234/067`.
|
||||
A tile at level L holds only the hashes of complete subtrees, so the hashes a partial tree still needs are computed from lower levels, as RFC 9162 computes a root from its subtrees.
|
||||
`fixtures/records/log/` is the example paper's log in this layout, and `checkpoint.jsonl` lists its tile paths.
|
||||
Reference in new issue
Block a user