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>
**Fecha:** 1 octubre 2026 (borrador en curso, sin aprobar)
**Fecha:** 1 octubre 2026, aprobado por su autor ese día
**Proyecto:** DateKeys
**Implementación de referencia prevista:** Go
**Proveedor temporal V1:** drand Quicknet
@ -1327,7 +1327,7 @@ X es una sola línea, en lugar de la de la firma y la del sello. Un lector de la
El SDK oficial MUST usar los textos de esta tabla. Otra implementación MUST usar esos textos o una traducción que no afirme más que ellos.
En los textos, ‹etiqueta› es la que la persona dio a una clave guardada (§29.12); ‹titulares›, el nombre del titular de cada certificado de los firmantes exigidos, tomado de su `subject` (`commonName`, o `givenName` y `surname`) sin su `serialNumber`, si cumple las reglas del autor declarado de §29.6, y si no, el SHA-256 del certificado en hexadecimal; ‹TSA›, el del titular del certificado de la autoridad de sellado, con las mismas reglas; y ‹t›, el instante del sello en UTC. Con F6, el lector MUST mostrar además una línea por firmante, con su titular, el emisor que dice su certificado y el instante de su sello, y decir si ese instante, más su precisión, es anterior a la fecha de apertura. Un `SignerInfo` cuyo certificado no está entre los exigidos se muestra aparte, con su resultado, y no cuenta (§29.10).
En los textos, ‹etiqueta› es la que la persona dio a una clave guardada (§29.12); ‹titulares›, el nombre del titular de cada certificado de los firmantes exigidos, tomado de su `subject` (`commonName`, o `givenName` y `surname`) sin su `serialNumber`, si cumple las reglas del autor declarado de §29.6, y si no, el SHA-256 del certificado en hexadecimal; ‹TSA›, el del titular del certificado de la autoridad de sellado, con las mismas reglas; y ‹t›, el instante del sello en UTC. Con F6, el lector MUST mostrar además una línea por firmante, con su titular, el emisor que dice su certificado y el instante de su sello, y decir si ese instante, más su precisión, es anterior a la fecha de apertura. Un `SignerInfo` cuyo certificado no está entre los exigidos se muestra aparte, con su resultado, y no cuenta (§29.10). El emisor que dice el certificado, en la línea de cada firmante, sigue las mismas reglas que el titular: si incumple las del autor declarado, se muestra el SHA-256 de su nombre en hexadecimal.
Un lector MUST NOT decir que una cápsula se firmó antes de la fecha salvo por un sello válido con t + precisión <round_time,yentoncesMUSTdecirquenocompruebaquiénemitióelsello:quienpuedeabrirlapuederehacerelárea(§7.9).Conunselloválido,unamtimeposterioratSHOULDmostrarsecomoincoherencia.
@ -1427,6 +1427,14 @@ author-signature:
3. Cada `SignerInfo` identifica con su `sid`, por `issuerAndSerialNumber` o por `subjectKeyIdentifier`, exactamente un certificado de `certificates`, y ningún certificado tiene dos `SignerInfo`. Los certificados que ningún `SignerInfo` identifica no deciden nada: un validador externo puede usarlos como intermedios. En `crls` solo van respuestas OCSP (`OtherRevocationInfoFormat` con id-ri-ocsp-response, RFC 5940).
4. Cada `SignerInfo` lleva `signedAttrs` con exactamente un `content-type` (id-data), un `message-digest` y un `signing-certificate-v2` (RFC 5035) cuyo primer `ESSCertIDv2` da el hash de su certificado; y como mucho un atributo no firmado `signature-time-stamp` (id-aa-signatureTimeStampToken, 1.2.840.113549.1.9.16.2.14), con un solo valor. Los demás atributos, firmados o no, no deciden nada.
Sobre esa forma, un lector MUST aplicar además:
- el `ContentInfo` y cada `SignerInfo` son SEQUENCE; la `version` de un `SignerInfo` es 1 con `issuerAndSerialNumber` y 3 con `subjectKeyIdentifier` (RFC 5652, §5.3);
- un atributo tiene al menos un valor, y un atributo de un tipo que esta sección pide una sola vez se cuenta por atributo y no por valor: dos atributos `content-type`, uno de ellos con un conjunto de valores vacío, incumplen la forma;
- un `signing-certificate` (RFC 2634) junto al `signing-certificate-v2` no decide nada: cuenta el v2;
- un `ESSCertIDv2` con el `hashAlgorithm` SHA-256 escrito de forma explícita se acepta, aunque sea su valor por defecto y DER no lo escriba, porque algunas aplicaciones de firma lo escriben; su hash MUST ser uno de la tabla de abajo, y SHA-1 incumple la forma;
- los parámetros de RSASSA-PSS van en el orden de sus etiquetas, sin repetir ninguno y sin escribir el `trailerField` que vale 1 por defecto: de otro modo, la firma no es verificable.
**Algoritmos.** Una tabla cerrada; el hash de la firma es el de `digestAlgorithm`:
| Algoritmo | OID |
@ -1481,7 +1489,7 @@ seal:
**Perfil del token**, en los dos sitios. Un lector comprueba, en este orden, y el resultado es el del primer fallo:
1. **Forma (S2):** DER de X.690; un `SignedData` con `eContentType` id-ct-TSTInfo (1.2.840.113549.1.9.16.1.4), su `eContent` y un solo `SignerInfo`; en él, `signedAttrs` con `content-type` id-ct-TSTInfo, `message-digest` y un `signing-certificate` (ESSCertID, cuyo SHA-1 solo identifica) o `signing-certificate-v2` que identifica el certificado de la TSA en `certificates`; y un `TSTInfo` de versión 1.
1. **Forma (S2):** DER de X.690; un `SignedData` con `eContentType` id-ct-TSTInfo (1.2.840.113549.1.9.16.1.4), su `eContent` y un solo `SignerInfo`; en él, `signedAttrs` con `content-type` id-ct-TSTInfo, `message-digest` y un `signing-certificate` (ESSCertID, cuyo SHA-1 solo identifica) o `signing-certificate-v2` que identifica el certificado de la TSA en `certificates`; y un `TSTInfo` de versión 1, en DER aunque vaya dentro de una cadena de bytes: `genTime` en UTC con la letra Z y una fracción sin cero final, `accuracy` con segundos de 0 en adelante y milisegundos y microsegundos de 1 a 999, `ordering` solo si es TRUE, los campos en su orden y ninguno después del último.
2. **Algoritmos (S1):** los de la tabla de §29.10, incluido el de `messageImprint`, que con `seal_type` 2 es SHA-256.
3. **Verificación (S3):** el `message-digest` es el hash del `eContent`, la firma de la TSA verifica, `messageImprint` es el hash de lo sellado, y el certificado de la TSA es válido en `genTime`.
@ -2050,7 +2058,7 @@ La extensión `datekeys.capsule`, versión 1, registrada para el array no críti
1 → desplazamiento (entero, opcional: 0 si falta)
```
El plaintext mide exactamente 4096 bytes, o el menor múltiplo de 4096 en el que quepa: la clave 6 completa lo que falte, así que su longitud no delata cuántas direcciones hay ni de qué tipo.
El plaintext mide exactamente 4096 bytes, o el menor múltiplo de 4096 en el que quepa: la clave 6 completa lo que falte, así que su longitud no delata cuántas direcciones hay ni de qué tipo. Si ninguna longitud de la clave 6 completa un múltiplo exactamente, porque la longitud CBOR de su cadena de bytes cambia de tamaño en ese punto, se usa el múltiplo siguiente: una base de 4070 bytes sin la clave 6 da 8192. `locator.json` da los casos en torno a esos límites.
**El sobre.** Quien crea la cápsula cifra el `.dkc` con `age` para la pública de `I_SOBRE`, una identity nueva de un CSPRNG, y parte ese fichero `age` en dos: la cabecera, hasta el salto de línea de su MAC incluido, que va en el localizador; y el resto, el nonce y los chunks de STREAM, que es lo único que se guarda fuera. El resto no lleva ninguna marca: sus bytes no se distinguen del azar, así que quien lo encuentra no sabe que es un fichero `age` ni una cápsula. Nadie, tampoco quien tiene la llave, lee el localizador antes de la fecha. En la fecha, el mismo release que abre la cápsula lo descifra, y el lector une la cabecera y el resto y descifra el `.dkc` con `I_SOBRE`.
@ -2059,7 +2067,7 @@ La extensión `datekeys.capsule`, versión 1, registrada para el array no críti
- Es ocultación, no esteganografía: quien analice el huésped puede ver que lleva bytes de más, pero no qué son ni de qué cápsula.
- Solo sirve un almacenamiento que conserva el fichero byte a byte, como un disco en la nube, IPFS o un servidor propio. Una red social o una aplicación de mensajería recomprimen las imágenes y los vídeos, o quitan lo que sobra, y el resto se pierde.
**Direcciones.** Cada URI es ASCII, de RFC 3986, con el esquema `https` o `ipfs` (un CID v1), sin userinfo. Un lector:
**Direcciones.** Cada URI es ASCII, de RFC 3986, con el esquema `https` o `ipfs` (un CID v1 en base32, que empieza por «b»), sin userinfo. Un lector lee la autoridad tal como está escrita, sin decodificar nada, y MUST rechazar la dirección si la autoridad lleva `%`, `@` o una barra invertida, si el puerto no es un número de 1 a 65535, si el host de un `https` no son letras, dígitos y guiones separados por puntos, o una dirección IP, que no sea de loopback, privada ni de enlace local, y si un nombre cuyo último segmento es numérico o empieza por `0x` no es una dirección IPv4 en notación decimal con puntos. Un nombre con letras que no son ASCII se escribe en su forma punycode. El host que muestra a la persona es ese texto, no el que daría una decodificación. Un lector:
- MUST NOT descargar sin que la persona lo pida, y MUST mostrar antes el host o el CID: la descarga revela a quien controla la dirección cuándo y desde dónde se usa la llave, y en IPFS la ven la pasarela y los pares;
- MUST pedir solo los bytes del resto, con un rango de HTTP si el servidor lo admite; si no, MUST dejar de leer al llegar al desplazamiento más `resto_size`;
@ -2736,7 +2744,7 @@ SHOULD:
En formato 3, además, MUST:
13. **Área.** Escribir `AREA_LEN` = 32768 y `SECURITY_CBOR` en todas las cápsulas, lleve o no firma o sello, sin que dependa de lo que el escritor sepa hacer (§29.2). La única excepción es la ampliación expresa: si las firmas y sus evidencias no caben y quien crea la cápsula elige ampliar, `AREA_LEN` = 65536. MUST NOT ampliar por su cuenta ni descartar nada en silencio, y si no cabe en 65536, MUST rechazar la cápsula. Sin firma ni sello, `SECURITY_CBOR` va vacío: `{0: "datekeys-security", 1: 1}` (§29.3). Solo un generador de vectores de prueba MAY escribir otra área u otro `SECURITY_CBOR`, como los de `format3_area_1024`, `format3_security_v2`, `format3_signature_unsupported` y `format3_seal_unsupported` (§67).
13. **Área.** Escribir `AREA_LEN` = 32768 y `SECURITY_CBOR` en todas las cápsulas, lleve o no firma o sello, sin que dependa de lo que el escritor sepa hacer (§29.2). La única excepción es la ampliación expresa: si las firmas y sus evidencias no caben y quien crea la cápsula elige ampliar, `AREA_LEN` = 65536. MUST NOT ampliar por su cuenta ni descartar nada en silencio, y si no cabe en 65536, MUST rechazar la cápsula. El escritor decide el área después de hacer las firmas y los sellos, con lo que ocupan, y quien firmó no firma de nuevo por eso. Sin firma ni sello, `SECURITY_CBOR` va vacío: `{0: "datekeys-security", 1: 1}` (§29.3). Solo un generador de vectores de prueba MAY escribir otra área u otro `SECURITY_CBOR`, como los de `format3_area_1024`, `format3_security_v2`, `format3_signature_unsupported` y `format3_seal_unsupported` (§67).
14. **Head.** Escribir el head de versión 1 (§29.4): con una sal de un CSPRNG, nueva para cada cápsula; con al menos un fichero o un comentario; con las entradas en el orden de R8, con sus tamaños, su maquetación y el SHA-256 de los bytes que escribe; y de como mucho 16 MiB.
15. **Rutas y texto.** Rechazar una ruta o un texto que incumpla §29.5 o §29.6, con un mensaje que nombre la regla y el carácter, en lugar de corregirlo sin avisar. Guardar las rutas tal como llegan, rechazar un UTF-16 mal formado y no conservar carpetas vacías. El SDK oficial SHOULD excluir por defecto `.DS_Store`, `Thumbs.db`, `desktop.ini`, `._*` y `__MACOSX/`, y dejar ver y editar la lista antes de cifrar.
16. **mtime.** Si incluye la mtime de un fichero, tomarla de su fuente, al cargarlo: ⌊lastModified / 1000⌋ en un navegador, o `ModTime().Unix()` en Go; y omitirla si no la conoce o si cae fuera de 0 a 253402300799, sin recortarla. El SDK oficial SHOULD incluirla por defecto, con una opción para quitarla.
@ -4030,6 +4038,11 @@ La v0.11 define la firma de autor y el sello de tiempo del área `security`, que
- Motivo: una aplicación que lista cápsulas y llaves solo puede distinguirlas hoy por `capsule_id`, y una llave suelta no dice de qué cápsula es ni dónde está.
- Caso: una `.dkk` de la v0.10 lleva `capsule_id` y `capsule_digest`, nada legible para una persona. Y en IPFS un `.dkc` es público: un rastreador indexaría `capsule_id`, la nota y la fecha, y quien tiene la `.dkk` encontraría la cápsula antes de la fecha; por eso se guarda un sobre.
- Pruebas previstas: la nota cambiada y la nota inválida, y los casos de `datekeys.capsule` (§64).
8. **Aclaraciones de la revisión adversarial** (§29.7, §29.10, §29.11, §44.1, §62.1 regla 13).
- Cambio: la forma de la firma CMS y del `TSTInfo` queda fijada campo a campo (versión del `SignerInfo` según su `sid`, atributos contados por atributo, `signing-certificate` junto al v2, `ESSCertIDv2` con SHA-256 explícito, parámetros de PSS, `accuracy` sin negativos, `genTime` en UTC con Z); el emisor de un certificado se muestra con las reglas del titular; las direcciones del localizador se leen sin decodificar y se rechazan los hosts que no son letras, dígitos y guiones y las IP que no son públicas; el relleno del localizador pasa al múltiplo siguiente cuando ninguna longitud encaja; y el área se decide después de firmar.
- Motivo: tres revisiones independientes, del lector CMS, de la lógica de firma y del escritor y del localizador, encontraron estas ambigüedades y fallos, todos con un caso que los reproduce.
- Caso: un sello con una `accuracy` negativa daba S4 a una cápsula sellada después de la fecha; un certificado con un nombre de emisor que lleva ESC y U+202E ponía líneas falsas en los veredictos; `https://%D0%B0pple.com/` se mostraba como un host con una «а» cirílica.
- Pruebas previstas: `security_cms.json` y `locator.json`, y los fixtures `format3_signed_cms` y `format3_sealed` (§64, §67).
Con un lector de la v0.11 cambian de veredicto cinco vectores de la v0.10 que usaban `alg` 1 y `seal_type` 2 como no soportados: en `security.json`, «a signature of alg 1» y «a signature and a seal» pasan de F1 a F2, y «a seal of seal_type 2», de S1 a S2; y los fixtures `format3_signature_unsupported` y `format3_seal_unsupported`, de F1 a F2. Los casos no soportados se rehacen con `alg` y `seal_type` 4294967295 (§29.3), y los actuales quedan como casos de F2 y S2. Ningún otro objeto cambia de veredicto ni de código. Los vectores de la firma, del sello, de la nota y de la extensión de cápsula, y los de `control_commit`, `signers_digest`, `AUTHOR_MESSAGE` y `SEAL_SUBJECT` sobre `format3_single`, se añadirán a `testdata` con el paso 6 del plan de la firma.
"description":"format 3 time_only capsule with an author-signature of alg 4294967295, as in format3_signature_unsupported, and a seal of seal_type 1 with a random token of 32 bytes: verdicts F1 and S1",
"description":"format 3 time_only capsule with a single file, nota.txt, signed with alg 1 by the test key of format3_signed and sealed with seal_type 2 by a test time-stamping authority before the round time: verdicts F4 and S4, with SEAL_SUBJECT and the token in the record",
"description":"format 3 time_only capsule with an author-signature of alg 4294967295, a random key of 32 bytes and a random signature of 64: verdicts F1 and S0",
"description":"format 3 time_only capsule with a single file, nota.txt, signed with alg 1 by a test key whose seed the record gives: verdict F4, and the commitments and the message of the signature",
"description":"format 3 time_only capsule with a single file, nota.txt, signed with alg 2 by two test certificates, an ECDSA P-256 one and an RSA 2048 one, each sealed by a test time-stamping authority before the round time: verdict F6, with the certificates, the commitments, SIGNERS and the result of each signer in the record",
"description":"format 3 time_only capsule with five files in three folders, one of them over two STREAM chunks and one without mtime, a comment of two lines and a declared author",
"description":"portable X25519 .dkk of time_and_key_portable.dkc with a noncritical extension: the credential of time_and_key_portable.dkk re-issued with org.example.delivery",
"description":"CBOR profile of spec §58 and the schemas of spec/datekeys.cddl, generated by the reference implementation. accept and reject are walked as one data item of the profile with the limits of walk; schemas are decoded with the decoder of their schema. See testdata/README.md.",
"description":"Ed25519 signatures and the result of the strict profile of the author signature (spec v0.11, §29.9), after the cases of «Taming the many EdDSAs»; stdlib is the result of crypto/ed25519 of Go, for the record. Generated by the reference implementation. See testdata/README.md.",
"description":"HEAD_CBOR of format 3 (spec §29.4 to §29.6) and the result of decoding it with no extension known, generated by the reference implementation: layer 2 (type tag and version), layer 3 (the CDDL with R1 and R8), then layer 4 in key order (spec §69.1). See testdata/README.md.",
"description":"Differential corpus of the pre-unlock checks (spec §63 steps 1 to 8): deterministic mutations of the official .dkc fixtures with the verdict of the reference implementation. See testdata/README.md.",
"format":"Each mutation is bases[base].file (in testdata/fixtures) with its edits applied. An edit is [at, delete, insert]: the delete bytes at offset at of the base are replaced by the bytes of the hex string insert. The edits of one mutation refer to offsets of the unmodified base, are sorted by offset and do not overlap. result is the verdict of steps 1 to 8 of spec §63 (capsule.Inspect, the Quicknet profile pinned, no extension known, no network, no secret): ok, or the normative error code, with step the step that failed. kind names the generator of the mutation and is informative.",
"description":"The extension datekeys.capsule of a .dkk and what it points to (spec v0.11, 44.1): an envelope of age with its header apart from its rest, the rest hidden in a host file, the locator sealed with tlock for round 1000, and the data of the extension. Frozen. See testdata/README.md.",
"description":"Mutation corpus of spec §64 and further cases of capsule.TestMutationCorpus, generated by the reference implementation: each case is a .dkc and what the reader is given, with the normative error and the step of spec §63 at which capsule.Open fails. See testdata/README.md.",
"description":"Padding rules of the payload of a format 2 capsule (spec §29.1): for each content length L, P with code 1 (bloque256) and code 2 (reforzado), and the length of PAYLOAD_AGE for each. e, s and last_bits are informative. Generated by the reference implementation. See testdata/README.md.",
"description":"The key of R7 (spec §29.5) of segments, with the Unicode 18.0.0 tables of §29.5.1, generated by the reference implementation: nfd is NFD(segment) and key is NFD(fold(NFD(s'))), s' the segment without ZWNJ, ZWJ, VS15 and VS16. See testdata/README.md.",
"description":"Paths of a format 3 head (spec §29.5) with the Unicode 18.0.0 and best-fit tables of §29.5.1, generated by the reference implementation. paths: one path and the rules of one entry, R2 to R6c and R10; trees: the paths of a head, of 0 bytes each, and the result of decoding it. See testdata/README.md.",
"description":"SECURITY_CBOR of format 3, exactly its SECURITY_LEN bytes, and the verdicts of the signature and of the seal (spec §29.3, §29.7), generated by the reference implementation, which implements no alg and no seal_type. See testdata/README.md.",
"description":"SECURITY_CBOR with an author signature of alg 2 or a time seal of seal_type 2, its context and the verdicts of spec v0.11 29.7, 29.10 and 29.11. Certificates and tokens are made once with test keys and the file is frozen. See testdata/README.md.",
"spec":"0.10",
"spec":"0.11",
"cases":[
{
"name":"alg 2: two signers, each sealed before the round time",
"description":"H2 of the IBE-CCA of tlock (spec §63 step 11): SHA-256 of \"IBE-H2\" and the 576 bytes of an element of GT, c1 before c0 at every level of the tower and each coordinate of Fp in 48 bytes big-endian (the order of kilic/bls12-381), truncated to 16 bytes. Generated by the reference implementation with drand/kyber-bls12381, the pairing of tlock.",
