@ -13,10 +13,12 @@ Estado al parar la sesión del 26 por el límite semanal de uso. Se actualizó e
- el plan de la firma, pasos 3 y 4 (`c3175a1`), 5 (`d1441de`) y 6 (`b88c459`): el escritor firma con `alg` 1, el lector da F2 a F4, la CLI tiene `author keygen|public`, `-sign`, `-expect-author`, y el fixture `format3_signed`;
- `alg` 2 (CMS) y sello `seal_type` 2 (RFC 3161): `55a261c` y `6cac49b`;
- la nota pública: `2142fcb`; la extensión `datekeys.capsule` (paquete `locator`) y la documentación: `1df818d`;
- los arreglos de la revisión adversarial: `90e15eb` y `b0bda15`.
- los arreglos de la revisión adversarial: `90e15eb` y `b0bda15`;
- los datos de prueba de `alg` 2, el sello y el localizador: `78f56a2`;
- la aprobación del spec, `SpecVersion` 0.11 y su SHA-256: `ae33434`, con el tag `spec-v0.11` (local).
- `main` de `datekeys-go` sigue en `13910b3`. `docs` no tiene remoto.
**El spec v0.11** es un borrador, sin aprobación escrita del autor: `datekeys-go/spec/DateKeys_Protocol_Specification_v0.11.md`. Su §76 lista los cambios. Lo que el autor decidió el 01-10:
**El spec v0.11** está aprobado por el autor (1-10-2026) y lleva el tag `spec-v0.11` en `datekeys-go`, sobre `ae33434`, con el SHA-256 `25cf1039d16666199c662e88e838a1d2ef0507be68e17fecd9aeee5d85a5bb6e`: `datekeys-go/spec/DateKeys_Protocol_Specification_v0.11.md`. El tag es local, sin subir. `SpecVersion` es 0.11. Su §76 lista los cambios; el punto 8 recoge las aclaraciones de la revisión. Lo que el autor decidió el 01-10:
- **Área fija de 32 KiB,** firme o no, y de 64 KiB solo con ampliación expresa. Los 32 KiB están por confirmar con firmas reales de varios países.
- **`AUTHOR_MESSAGE` en texto,** 99 bytes con el resumen en hexadecimal y un código de 8 caracteres. No cubre L, así que el área puede ampliarse después de firmar.
- **Firmas:**`alg` 1 es Ed25519 estricto; `alg` 2 es CMS con uno o varios firmantes, la lista de firmantes exigidos en la clave 1 y un CAdES-T por firmante.
@ -32,20 +34,21 @@ Estado al parar la sesión del 26 por el límite semanal de uso. Se actualizó e
- `EncryptOptions.CMSSigner` recibe `AUTHOR_MESSAGE` y devuelve la firma CMS hecha fuera; `Sealer` pide el sello. El escritor no escribe nada salvo F4, F6 y S4 o S5;
- `internal/cms` solo usa la biblioteca estándar: DER comprobado a mano, tabla cerrada de algoritmos, certificados leídos con `encoding/asn1` para que una curva que Go no tiene sea «no verificable» y no «mal formada».
**Decisiones que la revisión dejó al autor (anotadas, sin cambiar el spec):**
1. `ESSCertIDv2` con `hashAlgorithm` SHA-256 escrito de forma explícita: el código lo acepta (DER lo prohíbe, pero algunas aplicaciones lo escriben). Un `hashAlgorithm` SHA-1 se rechaza. Decidir y decirlo en §29.10.
2. El relleno del localizador (§44.1) a múltiplos de 4096 tiene huecos en los límites de la longitud CBOR; el código pasa al siguiente múltiplo. Añadir una frase o un vector para que TypeScript haga lo mismo.
3. `isCIDv1` solo acepta base32 (`b…`). El spec dice «un CID v1»: ampliar a base36 o dejarlo así.
4. Un `signing-certificate` junto al `signing-certificate-v2` en una firma no decide nada (decidido en el código, conforme al texto del spec).
5. SignerInfo con `version` 1 exige `issuerAndSerialNumber`, y 3 exige `subjectKeyIdentifier` (RFC 5652): el spec no lo dice.
6. §29.7: una mtime posterior a t con sello válido SHOULD mostrarse como incoherencia. No está hecho.
**Decisiones de la revisión, aprobadas por el autor el 01-10 y ya en el texto del spec:**
1. `ESSCertIDv2` con SHA-256 escrito de forma explícita: se acepta; SHA-1 es F1 (§29.10).
2. El relleno del localizador pasa al múltiplo de 4096 siguiente cuando ninguna longitud encaja (§44.1; `locator.json` da los casos).
3. Los CID de `ipfs` son v1 en base32.
4. Un `signing-certificate` junto al v2 no decide nada, y la `version` de un `SignerInfo` va según su `sid`.
5. Una mtime posterior a un sello válido se muestra como incoherencia: hecho en `decrypt`.
6. Los 32 KiB del área se mantienen; el autor puede aportar firmas reales de varios países para medirlos, sin que bloquee nada.
**Siguiente, en orden:**
1. **Datos de prueba para TypeScript:** fixtures de `alg` 2 (con certificados de prueba), de sello y de localizador, y sus vectores. Los certificados se generan con `internal/cms/cmstest`.
2. **Después, la página** (`datekeys-ts`), con su propio plan: la firma en el navegador (`alg` 1 y la ida y vuelta de `alg` 2 con AutoFirma), la nota y el localizador.
3. **Pendiente del autor:** aprobar el texto del spec v0.11 (con las decisiones de arriba), autorizar la subida, y conseguir firmas de prueba de varios países para medir el área de 32 KiB.
1. **Sincronizar `datekeys-ts`** con `datekeys-go` en `spec-v0.11`: copiar `testdata` (fixtures `format3_signed`, `format3_signed_cms` y `format3_sealed`, y los vectores `ed25519_strict.json`, `security_cms.json` y `locator.json`) y subir `SPEC_VERSION` a 0.11.
2. **La página** (`datekeys-ts`), con su propio plan: la firma `alg` 1 en el navegador, la ida y vuelta de `alg` 2 con una aplicación de firma como AutoFirma, el sello, la nota y el localizador. Para verificar CMS y RFC 3161 en TypeScript habrá que escribir el lector (DER, CMS, tabla de algoritmos) sin dependencias, o decidir qué dependencia se admite: preguntar antes al autor, por la regla de dependencias.
3. **Pendiente del autor:** autorizar la subida de `datekeys-go` (rama `v0.11` y el tag `spec-v0.11`), y llevar `main` a `ae33434` por fast-forward cuando se suba.
4. **Gate:** en esta máquina Windows bloqueó una vez `testdata/vectors/mutations.json` (algún proceso lo tenía mapeado); se resolvió reescribiéndolo vía fichero temporal y renombrado. Si vuelve a pasar, no es del código.
**Para trabajar:** en esta máquina los heredocs de Bash rompen las barras invertidas y los apóstrofos, así que los cambios con ellas se escriben como scripts con la herramienta Write. La vista previa hay que reiniciarla tras cada build. Los secretos de prueba no se muestran en el chat.
