diff --git a/CHANGELOG.md b/CHANGELOG.md index 87f9523..3ce8739 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -6,9 +6,9 @@ Cambios notables de la librería TypeScript y de la página. El proyecto usa ver ### El borrador de la especificación 0.16 (07-10-2026) -El borrador v0.16 de la rama `v0.16` de `datekeys-go`, en `3fd0e93`, aún sin aprobar: lo que encontró la revisión de Astra de la v0.15. No cambia ningún formato; cambian el veredicto de un sello sin `accuracy` y la lectura del JSON de drand (§76, «Cambios normativos de la v0.16»). +La v0.16 de `datekeys-go`, aprobada el 7 de octubre de 2026 con el tag `spec-v0.16` (`b6ff17a`): lo que encontró la revisión de Astra de la v0.15. No cambia ningún formato; cambian el veredicto de un sello sin `accuracy` y la lectura del JSON de drand (§76, «Cambios normativos de la v0.16»). -- `SPEC_VERSION` pasa a `0.16`. `testdata`, `wordlists` y `annex` se sincronizan con `3fd0e93` (`node scripts/sync-testdata.mjs sync --commit 3fd0e93`), que devuelve a `release.json` los escapes de sus casos `\u0072ound` y del par de sustitutos, que `4f78854` había perdido: el campo `spec` de cada fichero dice `0.16`; `vectors/security_cms.json` se hizo de nuevo, con 143 casos y `seal_reason`; `vectors/release.json` gana 26 casos del JSON de drand; `vectors/wordkey.json`, el texto del vector del anexo, también con sus marcas sueltas, y su llave; y llegan dos fixtures, `format3_time_and_key_words` y `format3_full_chunk`. El anexo de recuperación es el §79 del borrador v0.16, con la licencia de la especificación, CC BY-ND 4.0, en su título (`70d907b`) y la llave de palabras en 79.7. +- `SPEC_VERSION` pasa a `0.16`. `testdata`, `wordlists` y `annex` se sincronizan con `b6ff17a`, el commit del tag (`node scripts/sync-testdata.mjs sync --commit b6ff17a`), cuyo anexo lleva el SHA-256 de la versión aprobada; antes, `3fd0e93` devolvió a `release.json` los escapes de sus casos `\u0072ound` y del par de sustitutos, que `4f78854` había perdido: el campo `spec` de cada fichero dice `0.16`; `vectors/security_cms.json` se hizo de nuevo, con 143 casos y `seal_reason`; `vectors/release.json` gana 26 casos del JSON de drand; `vectors/wordkey.json`, el texto del vector del anexo, también con sus marcas sueltas, y su llave; y llegan dos fixtures, `format3_time_and_key_words` y `format3_full_chunk`. El anexo de recuperación es el §79 del borrador v0.16, con la licencia de la especificación, CC BY-ND 4.0, en su título (`70d907b`) y la llave de palabras en 79.7. - **El sello sin `accuracy`** (§29.7, §29.11, como `7e3b810` de Go). Un sello válido es S4 solo si el token lleva `accuracy` y t más la precisión es anterior a `round_time`; si no, S5, con el primer motivo que se cumple: `late`, sellado después o demasiado cerca; `no accuracy, BTSP`, sin `accuracy` en un token de la política BTSP de ETSI EN 319 421 (0.4.0.2023.1.1), que la exige; o `no accuracy`. Una `accuracy` de 0 segundos, o vacía, es una precisión de 0 y vale. `cms.ts`: el token gana `hasAccuracy` y `policy`, y `tokenIsBTSP`. `securitycms.ts`: `SealReason`, `Detail.sealReason` y `SignerLine.reason`. `security.ts`: S5 ya no tiene texto fijo; `verdictLines` escribe «No acredita que se sellara antes de la fecha de apertura: ‹motivo›.», y la línea de un firmante de F6 cuyo sello no lo acredita, «sin acreditar que fuera antes de la fecha de apertura: ‹motivo›», con los textos de `sealReasonText`, los de Go byte a byte. - **El escritor avisa** (§62.1, regla 19). `encryptFiles` devuelve en `Encrypted.security` los veredictos del área que escribió, como `Result.Security` de Go: un sello sin `accuracy` se escribe, y quien escribe ve su S5, o la línea de su firmante, con el motivo. `/create` no sella, así que no cambia. - **El JSON de drand, estricto** (§47.1, como `b570338` de Go). `releaseobject.ts` cambia el lector que imitaba `encoding/json` por `parseDrandJSON`, como `ParseDrandJSON` de Go: JSON de RFC 8259 en UTF-8 válido cuyo valor es un objeto, ningún nombre repetido en ningún objeto, nombres comparados exactos tras decodificar sus escapes (`"round"` es `round`, y `ROUND` otro nombre), un sustituto escapado sin su pareja es JSON mal formado, `round` es un número sin signo, fracción ni exponente de 1 a 2⁵³ − 1, `signature` y `randomness` son cadenas, y `randomness`, si viene, aunque sea vacía, es el SHA-256 de la firma. Los textos de error no cambian. Como la ronda ya no pasa de 2⁵³ − 1, `ParsedRelease` es un `Release`, sin `bigint`. `drand.ts` lee las respuestas de los relays con `parseDrandJSON`, como el cliente de Go, y `release-input.ts`, lo pegado, con `strictJSON` y `jsonRound`, para que la página no lea otra ronda que el paso 10. diff --git a/README.md b/README.md index c5f3ff6..a7a815d 100644 --- a/README.md +++ b/README.md @@ -21,12 +21,12 @@ Hay tres números de versión, cada uno con su significado, como en la referenci | Versión | Dónde | Cambia cuando | |---|---|---| | Formato | Dentro de los objetos: el formato de la cápsula, el `VERSION` del prelude de DKC1, 1, 2 o 3 al leer, que fija también la versión de schema de CONTROL_CBOR; y 1 en la trama DKK1 y en el schema de los demás objetos | Cambia el formato. Un lector rechaza una versión que no conoce (§22, §70) | -| Especificación | `SPEC_VERSION` de `src/lib/dkc/version.ts`, hoy `0.16`: el borrador v0.16 de la rama `v0.16` de `datekeys-go`, aún sin aprobar, en `3fd0e93`. `testdata` está en ese commit, y todos sus ficheros dicen `0.16` | Cambia el texto normativo | +| Especificación | `SPEC_VERSION` de `src/lib/dkc/version.ts`, hoy `0.16`: la v0.16 de `datekeys-go`, aprobada el 7 de octubre de 2026 con el tag `spec-v0.16`, en `b6ff17a`. `testdata` está en ese commit, y todos sus ficheros dicen `0.16` | Cambia el texto normativo | | Librería | `VERSION` de `src/lib/dkc/version.ts`, igual al campo `version` de `package.json` | Cambia la API o el comportamiento. Versionado semántico, sin promesa de estabilidad antes de 1.0.0 | `version.test.ts` comprueba que `VERSION` coincide con `package.json` y con su lockfile, y que `SPEC_VERSION` es la versión que nombran los vectores y fixtures compartidos; `vectors.test.ts` exige esa versión a cada fichero. El pie de la página muestra las dos. -La versión en desarrollo es `0.5.0-dev`, que sigue el borrador v0.16: el sello sin `accuracy` no prueba nada antes de la fecha de apertura, y el JSON de drand se lee estricto. La última publicada es la `0.4.0`, del 7 de octubre de 2026, con el tag `v0.4.0`, que cubre: +La versión en desarrollo es `0.5.0-dev`, que sigue la v0.16: el sello sin `accuracy` no prueba nada antes de la fecha de apertura, y el JSON de drand se lee estricto. La última publicada es la `0.4.0`, del 7 de octubre de 2026, con el tag `v0.4.0`, que cubre: - la especificación 0.15 (el tag `spec-v0.15` de `datekeys-go`): lee los formatos de cápsula 1 a 3 y escribe el 3, y el 2 solo como generador de vectores (§62.1, regla 1); - el objeto release y el release en la mano (§47.1, §49, §50, §63 pasos 9.c y 10): lee el objeto release y el JSON de drand con los textos de Go, busca la ronda en un archivo de releases local y abre con un release en la mano aunque el reloj vaya atrasado; `/inspect` acepta el release pegado o en un fichero; - la firma de autor de `alg` 1, con las claves `dkauthor1…`, y la de `alg` 2 con certificados, y el sello RFC 3161: las evalúa al abrir con los veredictos de Go y las escribe con los enganches del escritor; @@ -475,7 +475,7 @@ Comprueba que los ficheros coinciden con `SOURCE.json`, sin faltantes ni sobrant `.gitattributes` marca `testdata/**` y `wordlists/**` como binarios para que git no altere ningún byte. -Copia actual: la de `testdata/SOURCE.json`, `datekeys-go` en `3fd0e93`, el borrador v0.16 de la rama `v0.16`, que se sincroniza con `node scripts/sync-testdata.mjs sync --commit 3fd0e93`. Del mismo commit vienen `wordlists/` y `annex/`, el anexo de recuperación, que es ya el §79 del borrador v0.16, con la licencia CC BY-ND 4.0 de la especificación en su título y la llave de palabras en 79.7. Sobre el `testdata` de `spec-v0.15` (`fe50885`), el de la v0.16 cambia el campo `spec` de cada fichero a `0.16`, hace de nuevo `vectors/security_cms.json`, con 143 casos y `seal_reason`, añade a `vectors/release.json` los 26 casos de la lectura estricta del JSON de drand y a `vectors/wordkey.json` el vector del anexo, y trae dos fixtures, `format3_time_and_key_words` y `format3_full_chunk`. `wordkey/lists` trae la lista inglesa de la EFF y la española; la página solo publica la española. +Copia actual: la de `testdata/SOURCE.json`, `datekeys-go` en `b6ff17a`, el commit del tag `spec-v0.16`, que se sincroniza con `node scripts/sync-testdata.mjs sync --commit b6ff17a`. Del mismo commit vienen `wordlists/` y `annex/`, el anexo de recuperación, que es ya el §79 de la v0.16, con la licencia CC BY-ND 4.0 de la especificación en su título y la llave de palabras en 79.7. Sobre el `testdata` de `spec-v0.15` (`fe50885`), el de la v0.16 cambia el campo `spec` de cada fichero a `0.16`, hace de nuevo `vectors/security_cms.json`, con 143 casos y `seal_reason`, añade a `vectors/release.json` los 26 casos de la lectura estricta del JSON de drand y a `vectors/wordkey.json` el vector del anexo, y trae dos fixtures, `format3_time_and_key_words` y `format3_full_chunk`. `wordkey/lists` trae la lista inglesa de la EFF y la española; la página solo publica la española. ## Licencia diff --git a/annex/SOURCE.json b/annex/SOURCE.json index ac74bcd..8759fe2 100644 --- a/annex/SOURCE.json +++ b/annex/SOURCE.json @@ -1,7 +1,7 @@ { "module": "g.activething.com/go/DateKeys", - "commit": "3fd0e9372b4e759d6b65e37802322b6e01643da4", + "commit": "b6ff17a5fa5f119aa8125356437a09c657b15d0b", "files": { - "recovery.md": "dfb823cc2e8638e890cc690eea1d82bbcc661a50157be1ab4e8aaa5a4f80a6cb" + "recovery.md": "856f37efbc74a86af0db996e7c7678a8b506f839f0a8074389c0dbabc5dafa81" } } diff --git a/annex/recovery.md b/annex/recovery.md index 664c38d..ea5e4a7 100644 --- a/annex/recovery.md +++ b/annex/recovery.md @@ -1,6 +1,6 @@ # Cómo abrir una cápsula DateKeys sin software de DateKeys -Este texto acompaña a una cápsula del tiempo de DateKeys, un fichero `.dkc`: dice cómo abrirla, llegada su fecha, sin ningún software de DateKeys, por si ya no existe. Es el anexo informativo §79 de la especificación del protocolo DateKeys v0.16, cuyo texto tiene el SHA-256 a3cbdc6ef99aeb3ec77e40c4ce838f6f5b8950af6191383e4033761d2ca1df80. Es el mismo para toda cápsula: no lleva ningún dato de esta. Su licencia es CC BY-ND 4.0, Atribución-SinDerivadas 4.0 Internacional (https://creativecommons.org/licenses/by-nd/4.0/deed.es): se puede copiar y compartir sin cambios, citando su origen. +Este texto acompaña a una cápsula del tiempo de DateKeys, un fichero `.dkc`: dice cómo abrirla, llegada su fecha, sin ningún software de DateKeys, por si ya no existe. Es el anexo informativo §79 de la especificación del protocolo DateKeys v0.16, cuyo texto tiene el SHA-256 807d4fe85ac09ad6f97abc75ab3e2156bb2f3fb0dc589777f4420627fad545e1. Es el mismo para toda cápsula: no lleva ningún dato de esta. Su licencia es CC BY-ND 4.0, Atribución-SinDerivadas 4.0 Internacional (https://creativecommons.org/licenses/by-nd/4.0/deed.es): se puede copiar y compartir sin cambios, citando su origen. ## 79. Anexo informativo: recuperación sin software DateKeys diff --git a/testdata/README.md b/testdata/README.md index d469c74..530a1ed 100644 --- a/testdata/README.md +++ b/testdata/README.md @@ -1,7 +1,7 @@ # DateKeys test data Official vectors, fixtures and corpora of the DateKeys Protocol Specification -v0.15, generated by the reference implementation. +v0.16, generated by the reference implementation. Another implementation consumes them as they are: this file documents every format, so that no Go code has to be read. The rules that decide each verdict are in the specification; this file points to them, and states only what @@ -21,10 +21,14 @@ added since. The local gate (`scripts/check.sh`) and CI run it and fail if any committed file changes: every file below is exactly what the implementation computes today. -The `spec` field of every file is `"0.15"`, the version this module declares. +The `spec` field of every file is `"0.16"`, the version this module declares. v0.15 adds the release object and a release in the caller's hand (§47.1, §63 step 9.c): `vectors/release.json`, the files of `releases/`, and the -field `source` of `mutations.json`. +field `source` of `mutations.json`. v0.16 adds the reason of a seal that +proves nothing before the opening date, `seal_reason`, to +`security_cms.json`, made again; the strict reading of drand's JSON to +`release.json`; and the fixtures `format3_time_and_key_words`, with +`words_text`, and `format3_full_chunk`. What v0.12 changes from v0.11, the texts of the verdicts of a certificate and of a seal, the profile of a certificate and the rules of the addresses and of the padding of a locator, is in the files: the verdicts and the lines of @@ -402,7 +406,7 @@ flow). ```json { - "spec": "0.15", + "spec": "0.16", "description": "…", "profile": "datekeys:quicknet:v1", "scheme": "bls-unchained-g1-rfc9380", diff --git a/testdata/SOURCE.json b/testdata/SOURCE.json index 1b6a036..5f92478 100644 --- a/testdata/SOURCE.json +++ b/testdata/SOURCE.json @@ -1,8 +1,8 @@ { "module": "g.activething.com/go/DateKeys", - "commit": "3fd0e9372b4e759d6b65e37802322b6e01643da4", + "commit": "b6ff17a5fa5f119aa8125356437a09c657b15d0b", "files": { - "README.md": "acd08972fca2ec6d84f203f7dea95c13ce290736200795025dbd525794e33f21", + "README.md": "a7b2d6810928ccb8be33e39ede053a2cada38cd74b2888dc8655f3d5c0bb8375", "fixtures/empty_payload.dkc": "871e9bf05b52bbae17f3adfbbf97b46e7f0e53aa8f57bcaa506e43f36f53a9d4", "fixtures/empty_payload.inspect.json": "373e5d012b023ad58bbb54cbdffe0bed9e50c637438a4083ddb74d5414c59f59", "fixtures/empty_payload.json": "4ef16c75b3a7fe543ab37ff2c08e9e5061dc2d22f4b2724fe572c658af41c72a", diff --git a/wordlists/SOURCE.json b/wordlists/SOURCE.json index 435960f..597632a 100644 --- a/wordlists/SOURCE.json +++ b/wordlists/SOURCE.json @@ -1,6 +1,6 @@ { "module": "g.activething.com/go/DateKeys", - "commit": "3fd0e9372b4e759d6b65e37802322b6e01643da4", + "commit": "b6ff17a5fa5f119aa8125356437a09c657b15d0b", "files": { "README.md": "a29122e04cd8dac3e44d6f271da2ca99ac98e28b27e88c16b58162fe3eebedad", "en.txt": "6d557f0693958fb5e650b68b5bee585eb82cf4da32965505c789e924743bc522",