228 KiB

Raw Blame History Unescape Escape

DateKeys Protocol Specification

DateKey, DateKeyCap (`.dkc`) y DateKeys Access Key (`.dkk`)

Borrador normativo v0.10

Estado: Draft / pre-estándar
Fecha: 30 septiembre 2026
Proyecto: DateKeys
Implementación de referencia prevista: Go
Proveedor temporal V1: drand Quicknet

1. Alcance

Este documento define exclusivamente el protocolo base DateKeys.

Define:

DateKey: descriptor público de una condición temporal criptográfica.
DateKeyCap (.dkc): contenedor cifrado asociado a una DateKey y a una política de acceso.
DateKeys Access Key (.dkk): credencial portable de acceso.
perfiles de proveedor;
Quicknet como proveedor temporal V1;
resolución fecha → ronda;
framing de .dkc y .dkk;
cifrado y bindings;
políticas time_only y time_and_key;
recipient X25519 V1;
formatos 1, 2 y 3 de .dkc y su compatibilidad;
huecos fijos de INNER_ACCESS_AGE y relleno del payload;
contenido del formato 3: varios ficheros con sus rutas y metadatos, y el área security;
verificación;
reglas del escritor;
Release API;
Release Cache;
recuperación directa contra el proveedor;
extensiones genéricas;
consideraciones de privacidad.

Este documento no define almacenamiento, descubrimiento, distribución ni aplicaciones construidas sobre DateKeys.

Una aplicación que necesite información de transporte, descubrimiento o integración DEBE expresarla mediante extensiones no críticas, sin modificar el núcleo del protocolo.

2. Terminología normativa

Las palabras MUST, MUST NOT, SHOULD, SHOULD NOT, MAY y OPTIONAL se interpretan conforme a RFC 2119 / RFC 8174.

MUST / DEBE: requisito obligatorio.
MUST NOT / NO DEBE: prohibición obligatoria.
SHOULD / DEBERÍA: recomendación fuerte.
MAY / PUEDE: opcional.

3. Principio rector

Nunca confiar en el servidor cuando la misma propiedad puede verificarse criptográficamente en el cliente.

Consecuencias:

fecha → condición se calcula localmente;
Provider Profiles se pinnean localmente;
releases se verifican localmente;
.dkc, .dkk, APIs y relays se consideran entradas no confiables;
DateKeys no debe necesitar plaintext ni secretos finales de acceso.

4. Objetivos de seguridad

DateKeys persigue:

Confidencialidad temporal
Bajo los supuestos del proveedor, una condición temporal no debe poder satisfacerse antes del momento elegido.
Confidencialidad frente al operador
DateKeys no debe necesitar conocer el plaintext ni la credencial final de acceso.
Verificabilidad local
El SDK debe detectar condiciones, perfiles y releases manipulados.
Integridad
Alteraciones del framing, cabecera, control o payload deben provocar fallo.
Interoperabilidad
Implementaciones independientes deben producir y consumir objetos compatibles.
Recuperación independiente
Siempre que el proveedor conserve o pueda servir el release necesario, el ciphertext siga disponible y las credenciales correspondientes existan, un objeto maduro debería poder abrirse sin pasar por la API DateKeys.
Extensibilidad
Nuevos proveedores y extensiones no deben redefinir objetos antiguos.
Privacidad de metadatos
Antes de la fecha, una cápsula de formato 2 o 3 no debe revelar la longitud exacta de su contenido ni el número de credenciales que la abren. Una de formato 3 tampoco debe revelar las rutas, los tamaños, los hashes ni las fechas de sus ficheros, su comentario ni su autor declarado, ni su número más allá de la cota que da el relleno (§55.2).

5. No objetivos

El protocolo base no garantiza:

existencia perpetua de Quicknet;
conservación perpetua del histórico de releases;
resistencia post-cuántica del timelock V1;
revocación de una copia ya distribuida;
anonimato absoluto;
ocultar la fecha de apertura, la política de acceso, capsule_id o el tamaño rellenado del contenido (§55.2);
autoría legal por metadatos;
fecha probatoria de creación;
protección frente a un dispositivo ya comprometido;
control del plaintext después de un descifrado legítimo.

6. Fuera de alcance

El protocolo base NO define:

dónde se almacena un .dkc;
cómo se descubre un .dkc;
cómo se distribuye un .dkc;
políticas de disponibilidad del fichero;
mecanismos de naming externos;
mecanismos de entrega de una .dkk.

Estas cuestiones pertenecen a capas superiores.

El nombre del fichero .dkc y sus fechas en el sistema de ficheros tampoco pertenecen al protocolo. Los nombres, los tamaños y las fechas de los ficheros que guarda una cápsula de formato 3 sí: van cifrados en su head (§29.4).

7. Modelo de amenazas

El protocolo asume potencialmente maliciosos:

7.1 Servidor DateKeys

Puede intentar:

devolver una ronda pasada;
devolver un perfil falso;
devolver releases inválidos;
correlacionar consultas;
servir datos obsoletos;
guardar copias del ciphertext.

7.2 Relay / MITM / DNS

Puede:

suplantar endpoints;
modificar respuestas;
retrasarlas;
denegar servicio.

7.3 Poseedor de `.dkc`

Puede:

modificar bytes;
truncar;
reordenar;
intercambiar cabeceras;
intercambiar controles;
intercambiar payloads;
cambiar una política declarada;
intentar downgrade;
fabricar una cápsula de formato 3 con rutas que escapen de la carpeta del lector o que colisionen al extraerlas, nombres que se confundan, un head que agote su memoria o un comentario que imite un veredicto (§29.4 a §29.7).

7.4 Poseedor de `.dkk`

Debe tratarse como poseedor de una capacidad sensible.

7.5 Cadena de suministro

Un SDK o dependencia comprometidos pueden:

sustituir la raíz de confianza;
aceptar condiciones falsas;
exfiltrar secretos;
debilitar criptografía.

7.6 Provider comprometido

Si deja de cumplirse el supuesto de seguridad del provider, puede fallar la confidencialidad temporal.

7.7 Adversario cuántico futuro

El timelock Quicknet V1 no se considera post-cuántico.

Existe riesgo harvest now, decrypt later para ciphertexts de larga duración.

7.8 Dispositivo del creador

Si está comprometido antes o durante el cifrado, el protocolo no puede impedir la copia del plaintext o de secretos.

8. Objetos del protocolo

DateKey
    ↓
condición temporal pública

DateKeyCap (.dkc)
    ↓
objeto protegido

DateKeys Access Key (.dkk)
    ↓
capacidad adicional de acceso

9. Provider abstraction

Toda condición temporal se expresa como:

provider
profile
condition

Ejemplo Quicknet:

{
  "provider": "drand",
  "profile": "datekeys:quicknet:v1",
  "condition": {
    "round": 66884212
  }
}

El protocolo no presupone que todos los providers utilicen rondas.

10. Provider Profile

Un Provider Profile es inmutable.

Debe definir:

profile_id;
provider;
identificador de red;
parámetros criptográficos;
parámetros de tiempo;
reglas de validación;
profile_hash.

Cualquier cambio criptográficamente relevante exige otro perfil.

11. Codificación canónica del Provider Profile

V1 usa Deterministic CBOR conforme a RFC 8949, con el perfil CBOR del protocolo (§58).

Quicknet se serializa como mapa CBOR con claves enteras:

0  → "datekeys-provider-profile"
1  → 1
2  → "datekeys:quicknet:v1"
3  → "drand"
4  → "quicknet"
5  → <32-byte chain hash>
6  → <public key bytes>
7  → 3
8  → 1692803367
9  → "bls-unchained-g1-rfc9380"
10 → <genesis seed bytes>

Rangos de los enteros del perfil:

period (clave 7) MUST estar entre 1 y 2⁵³ − 1 (9007199254740991);
genesis_time (clave 8) MUST estar entre 0 y 2⁵³ − 1.

Estos son los rangos de la codificación. Las reglas que un perfil MUST cumplir para pinnearse, con su código de error, y la autocomprobación de chain_hash están en §12.1; el orden en que se aplican sigue §69.1.

El hash:

profile_hash =
SHA-256(exact_deterministic_cbor_bytes)

La seguridad NO procede de un profile_hash autodeclarado por una entrada remota.

La seguridad procede del perfil pinneado/confiado localmente.

12. Quicknet Provider Profile V1

profile_id:
datekeys:quicknet:v1

provider:
drand

network:
quicknet

chain_hash:
52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971

public_key:
83cf0f2896adee7eb8b5f01fcad3912212c437e0073e911fb90022d3e760183c8c4b450b6a0a6c3ac6a5776a2d1064510d1fec758c921cc22b0e17e63aaf4bcb5ed66304de9cf809bd274ca73bab4af5a6e9c76a4bc09e76eae8991ef5ece45a

period_seconds:
3

genesis_time:
1692803367

genesis_seed:
f477d5c89f21a17c863a7f937c6a6d15859414d2be09cd448d4279af331c5d3e

scheme:
bls-unchained-g1-rfc9380

El SDK oficial DEBE pinnear estos parámetros o una representación firmada equivalente.

12.1 Validación de un Provider Profile

Una implementación MUST aplicar estas reglas antes de pinnear un Provider Profile y a todo perfil que decodifique, en este orden; la primera que falla decide el código (§69.1):

Tipo, versión y schema. El type tag y la versión de schema (claves 0 y 1, §70) y el CDDL provider-profile de datekeys.cddl (§11): ERR_NON_CANONICAL_CBOR, o ERR_UNSUPPORTED_VERSION para una versión distinta de 1. Las reglas de nombre y de clave pública de ese CDDL tienen código propio (§57) y se comprueban en el punto 2. Una implementación que aplica el límite de implementación sobre period (§74) lo comprueba aquí, con ERR_NON_CANONICAL_CBOR.
Campos. Cada campo, ya con el tipo CBOR de su regla CDDL; cualquier fallo es ERR_UNKNOWN_PROFILE:
- profile_id (clave 2) está formado por caracteres de [a-z0-9:._-] y empieza por uno de [a-z0-9]; provider (3), network (4) y scheme (9), por caracteres de [a-z0-9._-], y empiezan por uno de [a-z0-9]. El profile_id aparece sin escapes en el JSON canónico de dk1_ (§18), que por eso no define ninguno;
- una implementación que aplica los límites de implementación de longitud de esos nombres y de public_key (§74) los comprueba aquí, con este mismo código;
- period (clave 7) es como mucho 2³² − 1 (4294967295) segundos, porque el hash del punto 3 lo codifica en 32 bits;
- genesis_time (clave 8) está entre 1 y 253402300798 (9999-12-31T23:59:58Z): posterior al instante 0 y anterior al último instante representable de §15;
- provider es drand, el único proveedor de V1;
- scheme es uno de los schemes drand sin encadenar que tlock admite: pedersen-bls-unchained, bls-unchained-on-g1 o bls-unchained-g1-rfc9380;
- public_key es la codificación canónica (§12.2) de un punto del grupo de claves del scheme —G1, 48 bytes, para pedersen-bls-unchained; G2, 96 bytes, para los otros dos— distinto del punto en el infinito.
Autocomprobación de chain_hash. Relaciona varias claves y por eso va después de todas las comprobaciones de campo. chain_hash (clave 5) MUST ser el hash de la información de cadena de drand (drand Protocol Specification, sección Root of trust, §77) de los demás parámetros:
```
chain_hash = SHA-256(
    uint32_be(period) ||
    int64_be(genesis_time) ||
    public_key ||
    genesis_seed ||
    network
)
```
con period en segundos, que el punto 2 acota a 32 bits; genesis_time, entero con signo de 64 bits; public_key y genesis_seed, los bytes exactos de las claves 6 y 10; y network, los bytes UTF-8 de la clave 4, que se omiten cuando network es default. profile_id, provider y scheme no entran en el hash. Una discrepancia es ERR_PROFILE_MISMATCH. Para Quicknet el resultado es su chain_hash de §12.
Pin. Al pinnearlo, su profile_hash (§11) MUST ser el que el cliente conoce previamente (§13): ERR_PROFILE_MISMATCH.

Los alfabetos de los nombres valen para todo perfil. Las demás reglas de los puntos 2 y 3 son las del proveedor drand en V1; un proveedor futuro definirá las suyas en su propio perfil (§10).

12.2 Codificación canónica de un punto

La clave pública del Provider Profile (§12.1), la firma de un release (§63, paso 10) y el punto U del stanza tlock (§63, paso 11) son puntos de BLS12-381. Cada punto tiene una única codificación válida, la canónica: la comprimida que produce drand, del formato de serialización de BLS12-381 de ZCash (§77), de 48 bytes para un punto de G1 y de 96 para uno de G2.

p  = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaaab
r  = 0x73eda753299d7d483339d80809a1d80553bda402fffe5bfeffffffff00000001

G1: y² = x³ + 4           sobre Fp
G2: y² = x³ + 4·(1 + u)   sobre Fp2 = Fp[u]/(u² + 1), con x = c0 + c1·u

Los tres bits más significativos del primer byte son flags, y el resto de la cadena es la coordenada x en big-endian:

bit 7 (0x80)  compresión   MUST valer 1
bit 6 (0x40)  infinito     1 solo en el punto en el infinito
bit 5 (0x20)  signo        elige y entre y y −y

En G1, x ocupa los 381 bits que siguen a los flags y MUST ser menor que p.
En G2, la cadena es c1 seguido de c0, 48 bytes cada uno, con los flags en el primer byte de c1; c1 y c0 MUST ser menores que p.
El bit de signo vale 1 si y solo si y es lexicográficamente mayor que −y: en G1, y > (p − 1)/2; en G2, con y = y0 + y1·u, y1 > (p − 1)/2, o y1 = 0 e y0 > (p − 1)/2.
El punto MUST estar en la curva y en el subgrupo de orden primo r.
El punto en el infinito se codifica con el primer byte 0xc0, compresión e infinito, y todos los demás bits a cero.

Un decodificador MUST rechazar cualquier otra cadena de bytes, aunque represente el mismo punto. En particular:

una longitud distinta de 48 en G1 o de 96 en G2, incluidas las formas sin comprimir, de 96 y 192 bytes;
el bit de compresión a 0;
una coordenada mayor o igual que p, como x + p en G1 o c0 + p y c1 + p en G2, que reducida módulo p daría un punto válido;
el bit de infinito con el de signo o con algún bit de la coordenada a 1: una identidad con signo o con carga;
una x que no es la de un punto de la curva, o un punto fuera del subgrupo de orden primo.

Es la regla del decodificador que usan drand y la implementación de referencia (kilic/bls12-381). Una librería que reduce las coordenadas módulo p o ignora la carga del infinito no la cumple por sí sola, y abriría cápsulas que la referencia rechaza (§76).

La clave pública, la firma y U MUST además ser distintos del punto en el infinito (§12.1, §63 pasos 10 y 11): su codificación canónica existe, pero ninguno de los tres usos la admite.

13. Root of trust

El cliente NO DEBE aceptar como raíz de confianza una clave pública o un perfil suministrados por el mismo endpoint que entrega el release.

Debe conocer previamente:

chain hash;
public key;
scheme;
genesis time;
genesis seed;
period;
profile hash.

14. DateKey

Una DateKey:

es pública;
no es una clave simétrica;
no es una private key;
no es una .dkk;
no es un secreto.

Representa una condición temporal verificable.

15. Resolución Quicknet fecha → ronda

Para Quicknet:

round_time(r) =
genesis_time + (r - 1) * period

El SDK MUST elegir la primera ronda cuyo:

round_time >= requested_unlock_at

Algoritmo:

candidate =
floor((timestamp - genesis_time) / period) + 1

if round_time(candidate) < requested_unlock_at:
    candidate++

requested_unlock_at MAY tener precisión inferior al segundo. La comparación round_time(candidate) < requested_unlock_at MUST realizarse a la precisión completa del instante solicitado; truncar o redondear el instante antes de comparar está prohibido.

Nunca se redondea hacia atrás.

Al escribir una cápsula, el instante pedido MUST ser posterior al instante actual del reloj del escritor (§62.1).

Cotas de la condición temporal:

El último instante representable es 9999-12-31T23:59:59Z (253402300799 en segundos Unix). La ronda de una DateKey MUST cumplir round_time(round) <= 253402300799; una ronda posterior es ERR_DATEKEY_INVALID. Para Quicknet la última ronda válida es 83903165811, con round_time 9999-12-31T23:59:57Z.
Al resolver una fecha, un requested_unlock_at anterior a genesis_time MUST rechazarse con ERR_DATEKEY_INVALID, en lugar de resolverse a la ronda 1, y también uno cuya primera ronda tenga un round_time posterior a 9999-12-31T23:59:59Z (para Quicknet, todo instante posterior a 9999-12-31T23:59:57Z).
Al leer una DateKey, la sintaxis dk1_ (§19) admite rondas de 1 a 2⁵³ − 1 sin consultar el perfil. La cota de round_time depende del perfil y se comprueba en el paso 7 de §63, antes de cualquier petición de red.

16. Vector normativo de ronda

Con:

genesis_time = 1692803367
period = 3
requested_unlock_at = 2030-01-01T00:00:00Z

resultado:

round = 66884212
round_time = 2030-01-01T00:00:00Z

La ronda:

66432123

corresponde a:

2029-12-16T07:15:33Z

Los vectores definitivos MUST generarse desde la implementación de referencia y congelarse antes de v1.0.

17. Ataque de ronda pasada

Verificar únicamente una firma BLS válida NO basta.

El SDK MUST exigir, cuando disponga de la fecha solicitada:

received_round == locally_resolved_round

round_time(received_round) >= requested_unlock_at

Al descifrar, el paso 10 de §63 compara la ronda del release con DateKey.round antes de verificar su firma: una ronda distinta es ERR_ROUND_MISMATCH, aunque su firma sea válida para esa otra ronda. Ese código es el de un release que el llamador suministra directamente: el que llega de una fuente de red con otra ronda lo descarta su fuente en el paso 9, y si ninguna fuente entrega un release válido el código es ERR_RELEASE_UNAVAILABLE.

18. Representación `dk1_`

Por compatibilidad con el prototipo V1 conserva:

dk1_

con JSON UTF-8.

Payload canónico:

{"version":1,"network":"datekeys:quicknet:v1","round":66884212}

network es el profile_id del perfil, cuyo alfabeto (§12.1) nunca necesita escapes JSON: el JSON canónico no escapa ningún carácter.

Representación:

dk1_<base64url(JSON_CANONICO)>

sin padding.

19. Canonicalidad `dk1_`

Existe una única cadena válida para una DateKey V1.

El parser MUST:

Base64URL-decodificar.
Parsear JSON.
Validar campos.
Reemitir el JSON canónico exactamente.
Recrear dk1_....
Comparar byte a byte con la entrada.

Si no coincide:

ERR_DATEKEY_NON_CANONICAL

Un fallo de los pasos 1 a 3 es ERR_DATEKEY_INVALID; una entrada que supera los pasos 1 a 3 y no coincide en el paso 6 es ERR_DATEKEY_NON_CANONICAL. Los pasos 1 a 3 aplican estas reglas:

el paso 1 exige el prefijo dk1_ y decodifica el resto con uno de los dos alfabetos, Base64URL o Base64 estándar, sin mezclarlos, sin padding o con el padding completo, y admite bits finales distintos de cero; el paso 6 rechaza después esas formas. Cualquier otro carácter, incluidos el espacio, CR (0x0D) y LF (0x0A), hace fallar el paso 1;
el paso 2 exige un único texto JSON de RFC 8259 cuyo valor es un objeto, con espacio en blanco JSON opcional antes y después y nada más, y sin marca de orden de bytes: un U+FEFF inicial, un segundo valor, UTF-8 inválido o cualquier otra cosa fuera de la gramática de RFC 8259 hace fallar el paso 2;
el paso 3 exige exactamente los campos version, network y round (un nombre repetido cuenta una vez, con su último valor); version igual a 1; network un profile_id válido: el alfabeto de §12.1 y, si la implementación lo aplica, el límite de longitud de §74; y round un entero entre 1 y 2⁵³ − 1;
los números JSON se leen por su valor decimal exacto, nunca por su aproximación a un double IEEE 754: otra grafía del mismo valor, como 1.0, 1e0 o 100e-2 para 1, supera el paso 3 y la rechaza el paso 6, pero 1.0000000000000001 no es 1 y falla el paso 3.

Esta validación no consulta el perfil: la cota de §15 se comprueba en el paso 7 de §63.

20. Extensiones de archivo

.dkc → DateKeyCap
.dkk → DateKeys Access Key

La extensión no sustituye los magic bytes.

21. `capsule_id`

Cada .dkc MUST contener un capsule_id.

Debe ser:

aleatorio;
opaco;
independiente de identidad, fecha o servicio;
de al menos 128 bits de entropía.

En V1, capsule_id MUST ser exactamente:

16 random bytes

generados por un CSPRNG. §24 y datekeys.cddl fijan esa longitud (§57).

22. Framing `.dkc` V1

V1 fija el siguiente prelude:

offset  size  field
0       4     MAGIC = "DKC1"
4       1     VERSION = 1, 2 o 3 (formato)
5       1     FLAGS = 0
6       2     RESERVED = 0
8       4     PUBLIC_HEADER_LEN (uint32 BE)
12      4     SEALED_CONTROL_LEN (uint32 BE)
16      ...   PUBLIC_HEADER
...     ...   SEALED_CONTROL
...     EOF   PAYLOAD_AGE

No existe PAYLOAD_LEN.

El payload es el resto del fichero hasta EOF.

VERSION es el formato de la cápsula. La trama es la misma en los tres formatos; cambian INNER_ACCESS_AGE, el plaintext de PAYLOAD_AGE y la versión de schema de CONTROL_CBOR:

Formato	`VERSION`	`INNER_ACCESS_AGE` (`time_and_key`)	Plaintext de `PAYLOAD_AGE`	Versión de schema de `CONTROL_CBOR`
1	1	uno o más stanzas	el contenido	1
2	2	exactamente 16 stanzas (§39)	el contenido con relleno (§29.1)	2 (§31)
3	3	exactamente 16 stanzas (§39)	`BODY`, con los ficheros y su head, con relleno (§29.2)	3 (§31)

El formato 1 es el de la v0.8.2; el 2, el de la v0.9; el 3, el de esta versión. PUBLIC_HEADER y la .dkk tienen la versión de schema 1 en los tres formatos (§24, §41).

Un escritor MUST escribir el formato 3 (§62.1). Un lector MUST aceptar los tres (§70).

Un cambio de la semántica de la cápsula que un lector anterior solo detectaría después de pedir el release, como un código de relleno nuevo (§29.1), una versión nueva del head o un límite mayor del formato 3 (§29.4), exige un formato nuevo, con su fila en esta tabla: así un lector que no lo conoce lo rechaza en el paso 2 de §63, sin red.

V1 MUST exigir:

1 <= VERSION <= 3
FLAGS == 0
RESERVED == 0
1 <= PUBLIC_HEADER_LEN <= 1048576      (1 MiB)
1 <= SEALED_CONTROL_LEN <= 67108864    (64 MiB)

Una longitud 0 queda fuera de rango: ninguna trama vacía contiene un objeto válido (§57). PAYLOAD_AGE no tiene campo de longitud: ocupa desde 16 + PUBLIC_HEADER_LEN + SEALED_CONTROL_LEN hasta EOF y MUST ser un fichero age completo (§28.1); un PAYLOAD_AGE vacío es un fichero age mal formado.

23. PRELUDE

PRELUDE son exactamente los primeros 16 bytes:

MAGIC
VERSION
FLAGS
RESERVED
PUBLIC_HEADER_LEN
SEALED_CONTROL_LEN

El binding criptográfico de la cabecera utiliza estos bytes exactos.

Los pasos 1 y 2 de §63 lo validan en este orden, y el primer fallo decide el código (§69.1):

menos de 4 bytes, o MAGIC distinto de DKC1 → ERR_INVALID_MAGIC (paso 1);
DKC1 seguido de menos de 12 bytes, un PRELUDE truncado → ERR_INTEGRITY (paso 1);
VERSION fuera de 1 a 3 → ERR_UNSUPPORTED_VERSION (paso 2);
FLAGS o RESERVED distintos de 0 → ERR_INVALID_FLAGS (paso 2);
PUBLIC_HEADER_LEN y después SEALED_CONTROL_LEN fuera de su rango (§22) → ERR_INTEGRITY (paso 2).

Que el fichero contenga los bytes que declara cada longitud se comprueba al leer cada sección: PUBLIC_HEADER en el paso 3 y SEALED_CONTROL en el paso 5, ambos con ERR_INTEGRITY.

Un lector que solo conoce el formato 1, como los de la v0.8.2, rechaza aquí una cápsula de formato 2, y uno de la v0.9, que conoce los formatos 1 y 2, una de formato 3, antes de cualquier petición de red (§70).

24. PUBLIC_HEADER

V1 almacena la cabecera directamente como Deterministic CBOR.

Schema:

0 → "datekeycap"
1 → 1
2 → capsule_id (16 bytes)
3 → compact_datekey (text, canonical dk1_)
4 → access_policy
5 → critical_extensions
6 → noncritical_extensions

Las claves 5 y 6 son opcionales y se omiten cuando no hay extensiones (§58.1). Cada una, cuando existe, contiene entre 1 y 64 extensiones (§54).

PUBLIC_HEADER es la misma en los tres formatos, con la versión de schema 1. No contiene nada del relleno, del número de credenciales ni del contenido del formato 3 (§55.2).

La data de las extensiones de PUBLIC_HEADER es pública y el protocolo base no la vincula al control hasta que se verifica header_binding (§63, paso 15). Esa verificación aporta coherencia interna, no autoría (§36.1, §55.1, §72).

No se almacena profile_id por separado.

El perfil se obtiene de la DateKey, evitando dos fuentes de verdad.

25. Política de acceso declarada

Valores V1:

0 → time_only
1 → time_and_key

El parser MUST comprobar que la estructura criptográfica real de SEALED_CONTROL coincide con la política declarada.

Una discrepancia:

ERR_POLICY_STRUCTURE_MISMATCH

26. Header binding

CONTROL_CBOR MUST contener:

header_binding =
SHA-256(
    PRELUDE ||
    PUBLIC_HEADER_BYTES
)

donde PUBLIC_HEADER_BYTES son exactamente los bytes CBOR almacenados.

La implementación NO DEBE reserializar la cabecera para calcular el binding.

El PRELUDE incluye VERSION: una cápsula a la que solo se cambia el formato falla, como tarde, en el paso 15. Antes falla en el paso 12 o en el 14 (§31, §39, §63), o en el 9.a, con ERR_ACCESS_INVALID, si se ofrece una .dkk con capsule_digest y la implementación lo comprueba (§43, §69.1). Quien puede sellar otro control sí puede cambiar el formato: es una reescritura (§55.1, §70).

27. Validación pre-unlock

Antes de abrir el control pueden verificarse:

magic;
versión, que es el formato (1, 2 o 3);
flags;
reserved;
longitudes;
CBOR canónico;
capsule_id;
DateKey canónica;
provider profile pinneado;
coherencia fecha/ronda cuando la fecha solicitada esté disponible;
extensions críticas conocidas.

La implementación SHOULD inspeccionar, antes de utilizar secretos o realizar una petición de red, la estructura visible de los ficheros age accesibles en ese momento:

OUTER_TIME_AGE: número y tipo de stanzas;
PAYLOAD_AGE: número y tipo de stanzas;
argumentos visibles del stanza tlock, cuando la implementación pueda inspeccionarlos de forma segura.

Esta inspección previa permite rechazar una cápsula mal formada antes de solicitar un release. Además de reducir trabajo innecesario, evita que una cápsula inválida genere una consulta observable en la Release API o en los relays.

Estas comprobaciones de stanzas previas al descifrado son estructurales. Su autenticidad frente a modificaciones de terceros queda confirmada únicamente cuando la cabecera age correspondiente supera la verificación del MAC durante la apertura, y solo frente a quien no conoce la file key (§55.1): una vez publicada la ronda, cualquiera puede calcular FK_TIME y recalcular el MAC de OUTER_TIME_AGE (§64). Frente a un creador que incluya vías alternativas de descifrado mediante stanzas adicionales, el MAC es válido por construcción y la comprobación estructural es la defensa del protocolo.

La inspección pre-unlock es una optimización de validación y privacidad y, por tanto, es un SHOULD. La aplicación de las reglas de cardinalidad de las secciones 29, 32, 33 y 39 es un MUST y DEBE realizarse, como mínimo, en el momento de abrir cada fichero age: la identity que desenvuelve la file key MUST rechazar el fichero si el conjunto completo de stanzas recibido viola la regla correspondiente.

header_binding vincula PUBLIC_HEADER al control abierto (§63, paso 15): aporta coherencia interna, no autoría ni fecha (§55.1). Solo una extensión de firma puede aportar autenticidad del creador (§36.1, §72).

28. Tres ficheros `age`

La construcción time_and_key V1 utiliza tres ficheros age estándar e independientes:

1. PAYLOAD_AGE
2. INNER_ACCESS_AGE
3. OUTER_TIME_AGE

Cada fichero age genera su propia file key aleatoria de 16 bytes.

Se nombran:

FK_PAYLOAD
FK_ACCESS
FK_TIME

No se reutiliza ninguna de ellas.

28.1 Formato de los ficheros `age`

Cada uno de los tres ficheros MUST ser un fichero age v1 completo conforme a la especificación age de C2SP (§77). Su cabecera sigue la gramática de esa especificación:

header     = v1-line 1*stanza end
v1-line    = %s"age-encryption.org/v1" LF
stanza     = arg-line *full-line final-line
arg-line   = "-> " argument *(SP argument) LF   ; el primer argumento es el tipo
argument   = 1*VCHAR                           ; bytes 0x21 a 0x7E
full-line  = 64base64char LF                   ; 48 bytes
final-line = *63base64char LF                  ; menos de 48 bytes, quizá ninguno
end        = "--- " 43base64char LF            ; MAC de 32 bytes
base64char = ALPHA / DIGIT / "+" / "/"

Base64 usa el alfabeto estándar sin padding y se decodifica de forma estricta: un =, una longitud que ninguna codificación sin padding produce o unos bits finales distintos de cero hacen mal formada la línea.
Las líneas terminan en LF: un CR forma parte de la línea y la hace mal formada.
Los argumentos se separan por exactamente un espacio.

Una cabecera que no sigue esta gramática hace mal formado el fichero. Eso incluye una cabecera sin stanzas, porque la gramática exige al menos uno (1*stanza), y una cabecera que supera los límites del parser de la implementación (§74).

Correspondencia de errores:

Fichero	Cabecera mal formada	Cabecera bien formada con un número o un tipo de stanzas que viola §29, §32, §33 o §39
`OUTER_TIME_AGE`	`ERR_INTEGRITY` en el paso 5, o en el 11 si no se hizo la inspección previa	`ERR_POLICY_STRUCTURE_MISMATCH` en el paso 5, y como MUST en el 11
`PAYLOAD_AGE`	`ERR_INTEGRITY` en el paso 6, o en el 17	`ERR_POLICY_STRUCTURE_MISMATCH` en el paso 6, y como MUST en el 17
`INNER_ACCESS_AGE`	`ERR_POLICY_STRUCTURE_MISMATCH` en el paso 12 (§36)	`ERR_POLICY_STRUCTURE_MISMATCH` en los pasos 12 y 13

INNER_ACCESS_AGE es el plaintext autenticado de OUTER_TIME_AGE: si no es un fichero age bien formado, lo que falla es la estructura que declara access_policy (§36), no la integridad de la cápsula.

La cabecera de OUTER_TIME_AGE se analiza dentro de los SEALED_CONTROL_LEN bytes de SEALED_CONTROL; la de PAYLOAD_AGE, desde su offset hasta EOF. Los pasos 5 y 6 analizan solo la cabecera age y no verifican su MAC (§27). Los demás fallos de un fichero age —MAC de la cabecera, argumentos o cuerpo de un stanza, STREAM, truncado, datos tras el final— aparecen al abrirlo, en los pasos 11, 13 y 17, y son ERR_INTEGRITY, salvo los códigos que esos pasos de §63 asignan a las reglas de stanzas y a las identities ofrecidas.

En los formatos 2 y 3 también es ERR_INTEGRITY, en el paso 17, un plaintext de PAYLOAD_AGE cuya longitud no es la P de su L o cuyo relleno no es nulo (§29.1), y en formato 3, además, una trama del contenido inválida, un último fichero que no termina en C o un fichero con otro SHA-256 (§29.2, §29.4).

29. PAYLOAD_AGE

El contenido del usuario se cifra como un fichero age v1 estándar completo.

Durante la creación se genera:

I_PAYLOAD = X25519 identity aleatoria de 32 bytes
R_PAYLOAD = X25519 public recipient correspondiente

I_PAYLOAD MUST salir de un CSPRNG, nueva para cada cápsula. MUST NOT reutilizarse en otra cápsula ni derivarse de otro valor, como el contenido, capsule_id, I_ACCESS o un secreto maestro. La razón es la confidencialidad: la cabecera de PAYLOAD_AGE es pública desde la creación, y I_PAYLOAD viaja en el control, que se abre en la fecha de su cápsula:

compartida con otra cápsula, abrir una de ellas, lo que en time_only puede hacer cualquiera en su fecha, abre el payload de la otra antes de la suya;
derivada del contenido, cualquiera puede comprobar un contenido que adivina, y descifrarlo, antes de la fecha;
derivada de un secreto maestro, ese secreto abre todos los payloads, sea cual sea su fecha.

Además, el binding de §30.1 solo separa dos cápsulas si sus I_PAYLOAD son distintas.

Entonces:

PAYLOAD_AGE =
age.Encrypt(
    recipient = R_PAYLOAD,
    plaintext = PAYLOAD_PLAINTEXT
)

donde L es la longitud del contenido en bytes, y en formato 3, la de BODY (§29.2):

formato 1:  PAYLOAD_PLAINTEXT = contenido
formato 2:  PAYLOAD_PLAINTEXT = contenido || 0x00^(P − L),  P = regla(L)  (§29.1)
formato 3:  PAYLOAD_PLAINTEXT = BODY || 0x00^(P − L),       P = regla(L)  (§29.2)

PAYLOAD_AGE MUST contener exactamente un stanza, de tipo X25519, para R_PAYLOAD.

age genera internamente:

FK_PAYLOAD = 16 random bytes

y la protege para R_PAYLOAD.

I_PAYLOAD se almacena dentro de CONTROL_CBOR; en los formatos 2 y 3, también L y el código de la regla de relleno (§31).

29.1 Relleno del payload

En los formatos 2 y 3 el plaintext de PAYLOAD_AGE es el contenido seguido de ceros. En formato 3, el contenido de esta sección es BODY (§29.2):

PAYLOAD_PLAINTEXT = contenido || 0x00^(P − L)
P = regla(L)

donde L es la longitud del contenido en bytes. La longitud de PAYLOAD_AGE, visible para cualquiera, revela P y no L (§55.2).

El escritor elige la regla. Su código viaja sellado en CONTROL_CBOR, junto a L (claves 6 y 7, §31); nada del relleno va en PUBLIC_HEADER.

Código	Nombre	P
1	`bloque256`	el menor múltiplo de 256 mayor o igual que L, y como mínimo 256
2	`reforzado`	el mayor de `bloque256(L)` y `Padme(L)`

No existe una regla sin relleno. Un lector MUST aceptar los dos códigos. El SDK oficial SHOULD usar el código 2 por defecto. Un código nuevo exige un formato nuevo (§22).

Definición exacta, para 0 ≤ L ≤ L_MAX:

L_MAX = 2^53 − 2^46 = 8936830510563328

si L <= 256:
    bloque256(L) = 256
    reforzado(L) = 256

si L > 256:
    bloque256(L) = 256 · ceil(L / 256)
    E            = bitlen(L) − 1        ; floor(log2 L), de 8 a 52
    S            = bitlen(E)            ; floor(log2 E) + 1, de 4 a 6
    lastBits     = E − S
    mask         = 2^lastBits − 1
    Padme(L)     = (L + mask) AND NOT mask
    reforzado(L) = max(bloque256(L), Padme(L))

bitlen(x) es el número de bits de x sin ceros a la izquierda: bitlen(1) = 1, bitlen(256) = 9. Padme es la función Padmé de Nikitin et al. (§77), con E = ⌊log2 L⌋, S = ⌊log2 E⌋ + 1 y lastBits = E − S: conserva los S + 1 bits más significativos de L y redondea hacia arriba los demás. (L + mask) AND NOT mask es igual a 2^lastBits · ceil(L / 2^lastBits). Tratar aparte L ≤ 256 evita el logaritmo de 0 y garantiza E ≥ 8 y S ≥ 4 donde se usa Padme.

Aritmética:

todos los valores son enteros exactos; para L ≤ L_MAX, ningún resultado intermedio supera 2⁵³ − 1;
E MUST calcularse con enteros, como bitlen(L) − 1, nunca con un logaritmo en coma flotante: en IEEE 754, Math.log2(2^49 − 1) da 49, y el resultado correcto es 48. Es el primer L del rango en que falla. Con el Math.log2 de Node, el error solo aparece justo por debajo de una potencia de dos y no cambia P ni S, pero sí E y lastBits, que fijan los vectores;
bitlen y Padme MUST NOT calcularse con operaciones de 32 bits, como los operadores de bits de JavaScript o Math.clz32: dan una P incorrecta por primera vez en L = 2 113 929 217 con los operadores con signo (2 113 929 472 en lugar de 2 147 483 648), y en L = 4 227 858 433 con >>> 0 (4 227 858 688 en lugar de 4 294 967 296). Es el riesgo real para P: con el código 2, un escritor así rellenaría como bloque256, y los lectores correctos rechazarían la cápsula en el paso 17, cuando ya no puede repararse. Una implementación en JavaScript usa BigInt o la forma con ceil, exacta en doubles porque divide y multiplica por potencias de dos.

L_MAX es el mayor L para el que las dos reglas dan una P de como mucho 2⁵³ − 1 (§58): reforzado(L_MAX + 1) = 2^53. Un escritor MUST NOT sellar un L mayor (§62.1), y un lector lo rechaza en CONTROL_CBOR (§31).

Propiedades, para todo L de 0 a L_MAX (informativo):

P es múltiplo de 256, P ≥ 256 y P ≥ L;
las dos reglas coinciden para L ≤ 8192; la primera diferencia está en L = 8193: 8448 con bloque256 y 8704 con reforzado;
bloque256 añade como mucho 256 bytes; por encima de L = 8192, reforzado añade menos de L / 2^S: menos del 6,25 %, del 3,125 % desde L = 65 536 y del 1,5625 % desde L = 2³²;
entre 2^E y 2^(E+1), reforzado admite como mucho 2^S valores de P (16, 32 o 64), y bloque256, 2^(E − 8).

Vectores (testdata/vectors/padding.json), con la longitud de PAYLOAD_AGE, 184 + P + 16·max(1, ⌈P / 65536⌉) (§62.1):

L	P, código 1	P, código 2	`PAYLOAD_AGE`, código 1 / 2
0, 1, 40, 255, 256	256	256	456 / 456
257	512	512	712 / 712
1000	1024	1024	1224 / 1224
8192	8192	8192	8392 / 8392
8193	8448	8704	8648 / 8904
65 537	65 792	67 584	66 008 / 67 800
78 000	78 080	79 872	78 296 / 80 088
3 000 000	3 000 064	3 014 656	3 000 984 / 3 015 576
600 000 000	600 000 000	603 979 776	600 146 680 / 604 127 416
2 113 929 217	2 113 929 472	2 147 483 648	2 114 445 768 / 2 148 008 120
4 227 858 433	4 227 858 688	4 294 967 296	4 228 891 080 / 4 296 016 056
2³² − 1	4 294 967 296	4 294 967 296	4 296 016 056 / 4 296 016 056
2³² + 1	4 294 967 552	4 362 076 160	4 296 016 328 / 4 363 141 304
5 000 000 000	5 000 000 000	5 033 164 800	5 001 220 888 / 5 034 393 784
10¹²	1 000 000 000 000	1 005 022 347 264	1 000 244 140 824 / 1 005 267 714 232
2⁵² + 1	4 503 599 627 370 752	4 573 968 371 548 160	4 504 699 138 998 728 / 4 575 085 063 045 304
L_MAX	L_MAX	L_MAX	8 939 012 353 949 880 / 8 939 012 353 949 880

Las filas 2 113 929 217 y 4 227 858 433 son los primeros L en que fallan las operaciones de 32 bits, con signo y con >>> 0; en la fila 2³² − 1 aciertan por coincidencia. Las filas por encima de 2³² fijan la aritmética de más de 32 bits: en ellas, salvo L_MAX, Padme supera a bloque256.

El código va sellado, pero P lo delata a veces (§55.2).

29.2 Contenido del formato 3

En formato 3 el contenido es BODY: una trama de 12 bytes, el área de security (§29.3), el head (§29.4) y los ficheros. L es la longitud de BODY, y el relleno de §29.1 se aplica a BODY:

PAYLOAD_PLAINTEXT = BODY || 0x00^(P − L),   L = |BODY|,   P = regla(L)

BODY = AREA_LEN      (uint32 BE)
    || SECURITY_LEN  (uint32 BE)
    || HEAD_LEN      (uint32 BE)
    || SECURITY_CBOR || 0x00^(AREA_LEN − SECURITY_LEN)
    || HEAD_CBOR
    || CONTENT

La trama MUST cumplir:

AREA_LEN = 512·k, con 1 <= k <= 128       (de 512 a 65536)
1 <= SECURITY_LEN <= AREA_LEN
1 <= HEAD_LEN <= 16777216                 (16 MiB)
12 + AREA_LEN + HEAD_LEN <= L

y los AREA_LEN − SECURITY_LEN bytes que siguen a SECURITY_CBOR MUST valer 0x00. Cualquier violación de la trama, incluido un L menor que 12, es ERR_INTEGRITY en el paso 17 (§63). SECURITY_CBOR y HEAD_CBOR ocupan exactamente SECURITY_LEN y HEAD_LEN bytes: un objeto CBOR que termina antes o que no cabe en ellos es inválido, con las consecuencias de su objeto (§29.3, §29.4).

CONTENT son los C = L − 12 − AREA_LEN − HEAD_LEN bytes restantes: los ficheros del head concatenados en su orden (§29.4). Sin ficheros, C MUST ser 0.

El área:

su tamaño lo fija la versión del spec con la que se escribe, no lo que contiene ni ninguna opción de cada cápsula: un escritor de esta versión MUST escribir AREA_LEN = 512, y MUST escribir SECURITY_CBOR siempre, aunque vaya vacío (§62.1, regla 13);
un lector MUST aceptar cualquier AREA_LEN que cumpla la trama, sin compararlo con la versión del spec: así lee el área, quizá mayor, de un escritor de una versión posterior (§70);
por eso P no depende de lo que lleve security (§55.2).

AREA_LEN, SECURITY_LEN y HEAD_LEN van dentro del plaintext de PAYLOAD_AGE: solo se conocen al descifrarlo y los autentica age. No son longitudes de trama del .dkc, y un lector MUST NOT reservar memoria según ellas antes de recibir los bytes que declaran (§57).

Ejemplos, con el área de 512 bytes y el código 2 (informativo):

Contenido	`HEAD_LEN`	L	P
sin ficheros ni comentario	53	577	768
un comentario de 1 byte	56	580	768
un fichero `nota.txt` de 1000 bytes, con mtime	117	1641	1792

SECURITY_CBOR vacío mide 22 bytes (§29.3), así que el área lleva 490 bytes a cero.

29.3 `security`

SECURITY_CBOR es un mapa CBOR con el perfil de §58:

0 → "datekeys-security"
1 → 1
2 → author_signature (cadena de bytes con el mapa author-signature, codificado aparte)
3 → seal (cadena de bytes con el mapa seal, codificado aparte)

Las claves 2 y 3 son opcionales (§58.1). Cada una es una cadena de bytes de 1 a 65 536 bytes cuyo contenido es otro objeto CBOR con el perfil de §58:

author-signature:
0 → alg (entero sin signo, de 1 a 2³² − 1)
1 → clave pública (cadena de bytes)
2 → firma (cadena de bytes)

seal:
0 → seal_type (entero sin signo, de 1 a 2³² − 1)
1 → token (cadena de bytes)

security nunca decide la apertura: ningún fallo suyo tiene código de error, detiene el paso 17 o cambia el código de otro fallo (§69.1). Su único resultado son los veredictos de §29.7. Es el objetivo 6 de §4: abrir una cápsula nunca depende de poder comprobar una firma o un sello.

Esta versión no define ningún alg ni ningún seal_type. La firma de autor y el sello de tiempo llegarán en versiones posteriores, que no cambiarán la trama, el head ni el mapa exterior de security (§70). Quedan reservados alg 1 (Ed25519) y seal_type 1 (servicio de sellado de DateKeys), 2 (RFC 3161) y 3 (OpenTimestamps). En esta versión:

un escritor MUST escribir security vacío, {0: "datekeys-security", 1: 1}, de 22 bytes (§62.1, regla 13);
un lector MUST aceptar las claves 2 y 3 y evaluarlas como dice §29.7, lo que con esta versión da siempre «no soportado» o «ilegible».

El contenido de las claves 2 y 3 se codifica aparte para que los lectores de todas las versiones validen igual el mapa exterior. Así, un author-signature o un seal mal formado solo cambia su propio veredicto, nunca el del otro, y un alg o un seal_type futuros pueden tener el tamaño que quepa en el área.

Validación, en el paso 17.3, con las capas de §69.1 y sin código:

Capa 2: el mapa exterior empieza por el type tag datekeys-security y la versión 1.
Capa 3: el perfil de §58, la igualdad con la recodificación, el schema de arriba y que SECURITY_CBOR ocupe exactamente SECURITY_LEN bytes.

Un fallo en cualquiera de las dos da el veredicto X (§29.7). El contenido de las claves 2 y 3 se valida después, al evaluar cada veredicto.

29.4 Head

HEAD_CBOR describe el contenido de una cápsula de formato 3. Es un mapa CBOR con el perfil de §58:

0 → "datekeys-head"
1 → 1
2 → salt (32 bytes)
3 → comment (texto)
4 → declared_author (texto)
5 → files (array de entradas)
6 → critical_extensions
7 → noncritical_extensions

Las claves 3 a 7 son opcionales (§58.1). Cada entrada de files es un mapa:

0 → path (texto: la ruta relativa del fichero, §29.5)
1 → size (entero sin signo)
2 → start (entero sin signo)
3 → end (entero sin signo, exclusivo)
4 → sha256 (32 bytes: el SHA-256 del fichero)
5 → mtime (entero sin signo: segundos UTC, informativa)

En una entrada, la clave 5 es opcional y las demás, obligatorias.

Reglas:

Versión. En formato 3 el head MUST tener la versión 1. Una versión nueva del head exige un formato nuevo (§22), que un lector anterior rechaza en el paso 2, sin red. La versión se sigue comprobando como defensa: otra es ERR_UNSUPPORTED_VERSION en el paso 17, capa 2, igual que la versión de CONTROL_CBOR en el paso 14.
Sal. salt son 32 bytes de un CSPRNG, nuevos en cada cápsula (§62.1, regla 14). Hacen de SHA-256(HEAD_CBOR) un compromiso que oculta: quien ve ese hash sin el head no puede confirmar una conjetura sobre nombres, tamaños o hashes previsibles. Los SHA-256 de cada fichero van sin sal: quien recibe el head puede compararlos con los de sus ficheros.
Comentario y autor declarado. comment mide de 1 a 16 384 bytes, y declared_author, de 1 a 256; sus caracteres siguen §29.6. El autor declarado es un texto del creador y no prueba nada (§36.1, §55.1).
Ficheros. files tiene de 1 a 65 535 entradas, en orden ascendente estricto de los bytes UTF-8 de path (§29.5, R8). Sin ficheros, la clave 5 se omite.
Maquetación. Con C la longitud de CONTENT (§29.2) y las entradas en su orden: start₀ = 0; startᵢ = endᵢ₋₁; y endᵢ − startᵢ = sizeᵢ. size, start y end son como mucho L_MAX. Un lector comprueba las igualdades restando, sin sumar valores que no ha comprobado. El fichero i son los bytes startᵢ a endᵢ − 1 de CONTENT, y su SHA-256 MUST ser su sha256. Que el end de la última entrada sea C, o que C sea 0 sin ficheros, se comprueba en el paso 17.5 (§63).
mtime. La fecha de modificación del fichero en su origen, en segundos UTC desde 1970-01-01, de 0 a 253402300799 (9999-12-31T23:59:59Z). Es informativa: no prueba nada, y ningún lector decide nada por ella (§55.1).
Extensiones. Las claves 6 y 7 siguen §54. Una extensión solo vale en el head si está registrada para él (§72).
Tamaño. HEAD_CBOR mide como mucho 16 MiB (§29.2).

El head no lleva tipo de contenido, hash global, permisos ni fecha de creación.

Los límites de esta sección y de §29.2, §29.5 y §29.6 quedan fijados con el formato 3: subirlos exige un formato nuevo (§22), porque un lector de esta versión rechazaría la cápsula después de pedir el release.

Validación, en el paso 17.4, con las capas de §69.1:

Capa 2: type tag y versión. Un type tag ajeno es ERR_NON_CANONICAL_CBOR; una versión distinta de 1, ERR_UNSUPPORTED_VERSION.
Capa 3: el perfil de §58, la igualdad con la recodificación, el schema de arriba con sus tamaños y rangos, que HEAD_CBOR ocupe exactamente HEAD_LEN bytes, R1 y R8 de §29.5 y las reglas de §54 para las extensiones → ERR_NON_CANONICAL_CBOR.
Capa 4, en orden de clave:
- claves 3 y 4: los caracteres de §29.6 → ERR_HEAD_INVALID;
- clave 5: las reglas de §29.5 y la maquetación, en el orden de §29.5 → ERR_HEAD_INVALID;
- clave 6: las extensiones críticas → ERR_EXTENSION_CRITICAL_UNKNOWN, y si todas son conocidas, ERR_EXTENSION_DATA_INVALID (§54).

ERR_HEAD_INVALID separa un head bien codificado cuyos campos incumplen sus reglas de un CBOR roto.

29.5 Rutas

path es la ruta relativa de un fichero dentro de la cápsula. Estas reglas hacen que ningún lector escriba fuera de su carpeta, y que dos entradas no puedan confundirse ni colisionar al extraerlas en Windows, macOS o Linux, ni al abrir el ZIP que las lleva (§56).

R1 y R8 son de la capa 3 y se comprueban sobre todo el array; las demás, de la capa 4. Así, ["b/..", "a"] es ERR_NON_CANONICAL_CBOR por R8, aunque «..» incumpla también R3.

R1. path mide de 1 a 1024 bytes UTF-8.
R2. Se divide en segmentos por '/' (U+002F): de 1 a 32 segmentos, ninguno vacío. No hay rutas absolutas ni '//'.
R3. Cada segmento mide de 1 a 255 bytes y no es «.» ni «..». Al quitarle los puntos de la lista blanca de R4, tampoco queda vacío, ni queda «.» ni «..»: HFS+ ignora ZWNJ y ZWJ al comparar nombres, así que allí un «.» seguido de ZWJ se vería y se compararía como «.». Además, el NFD del segmento (§29.5.1) mide como mucho 255 unidades UTF-16, el límite de HFS+: 127 veces «ΐ» (U+0390) son 254 bytes, pero 381 unidades tras NFD.
R4. Ningún punto de código de un segmento es:
- de C0 (U+0000 a U+001F) ni de U+007F a U+009F;
- ", *, :, <, >, ?, \ ni |;
- U+2028 ni U+2029;
- de la propiedad Default_Ignorable_Code_Point, salvo los de la lista blanca: U+200C (ZWNJ), U+200D (ZWJ), U+FE0E (VS15) y U+FE0F (VS16), que hacen falta en emoji y en varias escrituras. La propiedad incluye los controles bidi (U+061C, U+200E, U+200F, U+202A a U+202E y U+2066 a U+2069), U+00AD, U+034F, U+200B, U+2060 a U+206F, U+3164, U+FEFF, los demás selectores de variante y las etiquetas U+E0000 a U+E007F, que permiten nombres visualmente idénticos;
- de U+F000 a U+F0FF, del área de uso privado: Cygwin, WSL y el SMB de macOS representan con ellos los caracteres prohibidos en Windows, así que «informe», U+F03A y «anexo» se verían allí como «informe:anexo»;
- de la categoría general Cn, que incluye los no-caracteres y los puntos sin asignar: una versión futura de Unicode podría plegarlos o volverlos ignorables.
R4b. Los puntos de la lista blanca de R4 solo van donde su uso es conforme:
- VS15 y VS16, justo detrás de un carácter para el que emoji-variation-sequences.txt (§29.5.1) define la secuencia con ese selector;
- ZWJ y ZWNJ, nunca al principio ni al final del segmento, ni justo detrás de otro ZWJ o ZWNJ.
Así un segmento no puede llevar secuencias invisibles, que esconden datos: Unicode 18.0.0 advierte de que las secuencias de selectores de variante invisibles sirven para atacar aplicaciones de IA. Los emoji compuestos siguen valiendo, como la bandera arcoíris, U+1F3F3 U+FE0F U+200D U+1F308.
R5. Ningún segmento empieza por U+0020 ni termina en U+0020 o en '.'.
R6. La parte del segmento anterior a su primer '.', o todo el segmento si no lo tiene, sin los U+0020 finales y sin distinguir mayúsculas ASCII, no es CON, PRN, AUX, NUL, CONIN$, CONOUT$, de COM0 a COM9, de LPT0 a LPT9, COM¹, COM², COM³, LPT¹, LPT² ni LPT³.
R6b. Contando puntos de código, no se cumplen a la vez estas tres condiciones, que describen un alias 8.3 de NTFS:
- el segmento tiene como mucho un '.';
- la parte anterior al '.', o todo el segmento si no lo tiene, mide de 1 a 8 y cumple la expresión regular ^[^.]*~[0-9]{1,6}$;
- la parte posterior al '.' mide de 0 a 3.
En NTFS, «ABCDEF~1» puede resolver a «ABCDEFGHIJ», y extraer las dos fusionaría dos carpetas distintas. La expresión regular no usa búsquedas anticipadas, que el paquete regexp de Go no admite; en JavaScript lleva la bandera u.
R6c. Para cada tabla best-fit de §29.5.1, la proyección del segmento, que sustituye cada punto no ASCII que la tabla lleva a un byte ASCII por ese byte y deja los demás como están, no contiene '/', '', ':' ni U+0000, y cumple R3, R5, R6 y R6b. Cubre, entre otros, ∖, ∶, ¥ en cp932, ₩ en cp949, ´ en cp1253, las formas de ancho completo de '/', '', ':' y '.', «ＣＯＮ.txt», y U+3000 al principio o al final de un segmento, que bestfit1252 lleva a U+0020. Solo se proyecta lo que la tabla lleva a ASCII: el '?' que Windows pone por defecto a lo que no convierte no es sintaxis de ruta. Los demás caracteres de R4 que dé una proyección no se rechazan: con la API ANSI de Windows hacen fallar la creación del fichero, pero no cambian su destino. Así se aceptan «¿», que bestfit1250 lleva a '?', y «§», «♥» y las flechas, que bestfit874 lleva a controles C0.
R7. La clave de un segmento s es NFD(pliegue(NFD(s′))), con s′ el segmento sin los puntos de la lista blanca de R4 y el pliegue de las entradas C y F de CaseFolding más U+0131 → U+0069, como NTFS (§29.5.1). Los puntos de la lista blanca se quitan antes de normalizar porque tienen clase de combinación 0: entre dos marcas combinantes, cambiarían su orden canónico. Sobre el árbol cuyos nodos son las rutas y sus prefijos por segmentos:
- dos hermanos no tienen la misma clave. Colisionan, por ejemplo, «A.txt» y «a.txt», un nombre en NFC y en NFD, «Fotos/a» y «fotos/b», «Straße» y «STRASSE», «K» y el signo de Kelvin, y «ab» con y sin ZWNJ;
- ninguna ruta es a la vez un fichero y el prefijo de otra, comparando claves, como «A» y «a/b».
R8. Las rutas están en orden estrictamente ascendente de sus bytes UTF-8, comparados como en §54. Una implementación MUST NOT comparar unidades UTF-16 ni usar una colación: con el operador < de JavaScript, U+FF5E y U+1F600 quedan al revés que en UTF-8, y localeCompare ordena por colación.
R9. Hay como mucho 65 535 carpetas implícitas, es decir, prefijos propios distintos de las rutas.
R10. La clave de R7 del primer segmento no empieza por «.datekeys-». La implementación de referencia escribe el árbol en DIR/.datekeys-* antes de moverlo a su destino (§56), y una entrada con ese nombre chocaría con él.

Orden de las comprobaciones de la capa 4 en la clave 5: para cada entrada, en su orden, R2, R3, R4, R4b, R5, R6, R6b, R6c, R10 y la maquetación de §29.4; después de todas las entradas, R7 y R9. Todas dan ERR_HEAD_INVALID, y la primera que falla decide.

29.5.1 Tablas

R3, R4, R4b, R6c, R7 y la regla de invisibles de §29.6 usan datos fijos, no los de la plataforma:

Unicode 18.0.0: UnicodeData.txt, con la categoría general, la clase de combinación canónica y las descomposiciones canónicas; DerivedCoreProperties.txt, con Default_Ignorable_Code_Point; CaseFolding.txt, con sus entradas C y F; emoji/emoji-variation-sequences.txt, con los caracteres que admiten VS15 y VS16 (R4b); y NFD según UAX #15, con la descomposición algorítmica de Hangul.
WindowsBestFit, de unicode.org: los quince ficheros bestfit874.txt, bestfit932.txt, bestfit936.txt, bestfit949.txt, bestfit950.txt, de bestfit1250.txt a bestfit1258.txt y bestfit1361.txt, con la conversión de Unicode a su código de página de su sección WCTABLE.

Una implementación MUST aplicar las tablas generadas de esos ficheros, fijados por su SHA-256 (por fijar al implementar), y MUST NOT usar las funciones de Unicode de su plataforma para estas reglas: normalize, toLowerCase, las clases \p{…} de las expresiones regulares, el paquete unicode de Go o golang.org/x/text. Su versión de Unicode cambia con cada motor: Go 1.26.8 trae la 15.0.0, y Node 24.9, la 16.0. La implementación de referencia genera desde esos ficheros el código de las dos implementaciones, y sus pruebas comprueban los digests.

Un punto de código posterior a Unicode 18.0.0 es Cn para estas tablas: R4 lo rechaza, y el escritor lo dice con un mensaje que nombra el carácter (§62.1, regla 15).

La versión de Unicode queda fijada con el formato 3. Pasar a otra cambiaría qué rutas se aceptan, algo que un lector de esta versión solo notaría después de pedir el release, así que exige un formato nuevo (§22).

29.6 Texto

El comentario y el autor declarado del head (§29.4) son UTF-8 válido. «Espacio» es U+0020. Una implementación MUST NOT usar trim, \s, TrimSpace ni unicode.IsSpace para estas reglas.

Comentario. Ningún punto de código es de U+0000 a U+0008, de U+000B a U+001F, de U+007F a U+009F, de U+202A a U+202E, de U+2066 a U+2069, U+2028, U+2029, U+FEFF ni un no-carácter. Se admiten TAB y LF; el escritor convierte CR LF, y un CR suelto, en LF.
Autor declarado. Lo mismo que el comentario, y además ni TAB, ni LF, ni U+061C, U+200E ni U+200F. No empieza ni termina en U+0020.
Invisibles. Ni el comentario ni el autor declarado llevan puntos de la propiedad Default_Ignorable_Code_Point salvo los de la lista blanca de R4, y esos van solo donde R4b los admite, con cada línea en el papel del segmento. Quedan fuera las etiquetas U+E0000 a U+E007F y los selectores de variante fuera de una secuencia de emoji, con los que se esconde un texto que no se ve en pantalla pero que un modelo de IA sí lee. Por eso quedan fuera también las banderas de subdivisión, como la de Escocia, que usan etiquetas.

Así, ningún texto ni ruta puede llevar ESC ni un control C1 a un terminal, cambiar la dirección del texto que lo sigue ni esconder un texto invisible.

29.7 Veredictos y presentación

Un lector evalúa security en el paso 17.6 y presenta el resultado, tras el paso 18, como veredictos. Un veredicto nunca impide abrir la cápsula.

La firma y el sello se evalúan por separado:

Situación	Firma	Sello
El mapa exterior de `security` falla la capa 2 o la 3 (§29.3)	X	X
Sin clave 2	F0	no cambia
El contenido de la clave 2 no decodifica o incumple el schema de `author-signature`	F1	no cambia
`alg` que el lector no implementa	F1	no cambia
Sin clave 3	no cambia	S0
El contenido de la clave 3 no decodifica o incumple el schema de `seal`	no cambia	S2
`seal_type` que el lector no implementa	no cambia	S1

Para la firma y para el sello por separado, decide la primera fila de la tabla que se cumple, de arriba abajo: alg y seal_type solo se leen de un contenido que decodifica y cumple su schema. Así, un seal con una clave desconocida, o con seal_type 0, es S2 y no S1.

X es una sola línea, en lugar de la de la firma y la del sello. Esta versión no implementa ningún alg ni ningún seal_type (§29.3), así que un lector solo llega a X, F0, F1, S0, S1 y S2. Las versiones que definan la firma y el sello añadirán sus propios veredictos sin cambiar los de esta tabla.

Veredicto	Significado	Texto
X	`security` ilegible	«No se han podido comprobar la firma ni el sello: trátala como no firmada y sin fecha probada.»
F0	sin firma	«Sin firma de autor.»
F1	firma ilegible o no soportada	«No se ha comprobado ninguna firma: trátala como no firmada.»
S0	sin sello	ninguno
S1	sello no soportado	«Lleva un sello de tiempo que esta versión no sabe comprobar: aquí no prueba nada.»
S2	sello ilegible	«El sello de tiempo es ilegible: no prueba nada.»

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.

Un lector que muestra el contenido de una cápsula de formato 3:

MUST mostrar primero los veredictos, y después el autor declarado y el comentario, marcados como texto del creador que nadie ha comprobado. El SDK oficial MUST usar «autor declarado (texto del creador, sin comprobar)» y un recuadro titulado «Comentario del creador (sin comprobar)»;
MUST mostrar las rutas solo como texto, aisladas de la dirección del texto que las rodea;
en una salida de texto, como la de una CLI, sea o no un terminal, MUST:
- expandir cada TAB del comentario a espacios, hasta la siguiente columna múltiplo de 8;
- partir cada línea del autor, del comentario y de cada ruta que muestre en trozos de ancho visual como mucho W − 3, con W el ancho del terminal, u 80 si la salida no es un terminal, y nunca menos de 20; cada trozo lleva al menos un punto de código;
- contar el ancho por lo alto: 1 por carácter ASCII imprimible y 2 por cualquier otro punto de código;
- poner delante de cada trozo │ (U+2502 y U+0020), que cuenta 3 columnas porque U+2502 tiene anchura ambigua y ocupa 2 en un terminal CJK;
- repetir los veredictos al final, después del comentario y de las rutas que muestre.
Así el terminal nunca parte una línea por su cuenta, y ninguna línea del creador aparece sin prefijo ni puede imitar un veredicto;
SHOULD avisar de los ficheros .lnk, .url, .library-ms, .searchConnector-ms y desktop.ini, de una carpeta .git, de los ejecutables y de un '-' inicial, comparando la clave de R7 del segmento y de su extensión, así que «.GIT» o «Informe.LNK» también avisan.

30. Por qué PAYLOAD_AGE es un fichero age completo

V1 NO expone ni reimplementa STREAM como un subformato DateKeys.

El STREAM de ChaCha20-Poly1305, chunks de 64 KiB, nonce y final-chunk marker forman parte interna del formato age.

DateKeys trata PAYLOAD_AGE como bytes de un fichero age estándar.

Esto permite reutilizar:

header MAC;
recipient stanza;
file key de 16 bytes;
STREAM;
detección de truncado;
vectores y librerías existentes.

El relleno de §29.1 forma parte del plaintext de age: no existe un subformato DateKeys para él.

30.1 Binding `CONTROL_CBOR` ↔ `PAYLOAD_AGE`

El binding entre control y payload se obtiene mediante I_PAYLOAD.

CONTROL_CBOR contiene exactamente la identity privada I_PAYLOAD generada para esa cápsula. Esa identity solo abre el PAYLOAD_AGE cifrado para su recipient correspondiente.

Por tanto:

CONTROL_A + PAYLOAD_AGE_B

MUST fallar porque I_PAYLOAD_A no puede desenvolver la file key de PAYLOAD_AGE_B.

Este binding criptográfico es independiente de cualquier digest auxiliar del fichero.

El binding solo separa dos cápsulas si sus I_PAYLOAD son distintas: I_PAYLOAD MUST ser nueva para cada cápsula (§29).

En los formatos 2 y 3 el control fija, además, la longitud y el relleno del plaintext de PAYLOAD_AGE: su L y su código dan P (§29.1), y el paso 17 rechaza un plaintext de otra longitud o con un byte de relleno distinto de 0x00 (ERR_INTEGRITY). Esta comprobación complementa el binding de I_PAYLOAD, no lo sustituye. Aporta determinismo: un solo plaintext válido para cada control y cada payload, en el que todos los lectores coinciden. No añade autenticidad: quien conoce FK_TIME o FK_ACCESS puede sellar otro control con otra L de la misma P, y quien conoce I_PAYLOAD puede cifrar otro plaintext (§55.1).

En formato 3, además, el head fija el tamaño, la posición y el SHA-256 de cada fichero dentro de BODY (§29.4), y el paso 17 lo comprueba todo. Tampoco añade autenticidad: quien conoce I_PAYLOAD puede cifrar otro BODY coherente con su propio head.

31. CONTROL_CBOR

Una vez abierto, el control es siempre Deterministic CBOR. Una codificación no canónica MUST rechazarse aunque CONTROL_CBOR no participe directamente en un hash.

Schema base:

0 → "datekeys-control"
1 → versión de schema: 1 en formato 1, 2 en formato 2 y 3 en formato 3
2 → header_binding (32 bytes)
3 → payload_identity (32 raw bytes, I_PAYLOAD)
4 → critical_extensions
5 → noncritical_extensions
6 → payload_length (8 bytes: L, entero sin signo big-endian)
7 → padding (código de relleno: 1 = bloque256, 2 = reforzado)

Reglas del schema:

la versión de schema (clave 1) MUST ser la que la tabla de §22 asigna al formato de la cápsula, el VERSION de su PRELUDE: 1 en formato 1, 2 en formato 2 y 3 en formato 3. Otra es ERR_UNSUPPORTED_VERSION en el paso 14 (§69.1, capa 2);
las claves 4 y 5 son opcionales y se omiten cuando no hay extensiones (§58.1); significan lo mismo en las tres versiones;
las claves 6 y 7 MUST existir en las versiones 2 y 3 y MUST NOT existir en la versión 1. Las versiones 2 y 3 tienen las mismas claves; en la 3, L es la longitud de BODY (§29.2);
payload_length MUST ser una cadena de bytes de exactamente 8 bytes con L, la longitud del contenido, como entero sin signo big-endian, con ceros a la izquierda; su valor MUST ser como mucho L_MAX = 2⁵³ − 2⁴⁶ (8936830510563328, §29.1). L = 0 se codifica 48 0000000000000000, y L = 2³² + 1, 48 0000000100000001;
padding MUST ser el entero sin signo 1 o 2 (§29.1);
cualquier violación de las reglas de las claves 6 y 7 es ERR_NON_CANONICAL_CBOR (§57).

payload_length tiene tamaño fijo para que la longitud de CONTROL_CBOR, visible en SEALED_CONTROL_LEN, no dependa de L (§55.2): un entero CBOR en su forma más corta ocuparía 1, 2, 3, 5 o 9 bytes según L. Un CONTROL_CBOR de versión 2 o 3 sin extensiones mide 103 bytes:

a6 00 70 "datekeys-control" 01 <02 o 03> 02 58 20 <header_binding>
03 58 20 <I_PAYLOAD> 06 48 <L, 8 bytes> 07 <código, 01 o 02>

L y P no son longitudes de trama: un lector MUST NOT reservar memoria ni disco según L o P antes de recibir el plaintext que los respalda (§57).

No contiene el payload grande.

DateKeys V1 utiliza un único mecanismo de extensión. No existe un campo core separado para aplicaciones o semánticas superiores. Cualquier semántica adicional se registra como una extensión identificada por namespace. Las claves 6 y 7 son campos del protocolo, no semántica de aplicación.

Una extensión usa conceptualmente:

0 → extension_id
1 → extension_version
2 → data (opcional)

Reglas:

extension_id MUST ser una cadena de texto UTF-8 válida de al menos 1 byte;
extension_version MUST ser un entero sin signo entre 0 y 2³² − 1;
(extension_id, extension_version) identifica el schema;
data, cuando existe, MUST ser una cadena de bytes (bstr) no vacía, opaca para el protocolo base (§54);
una extensión sin datos MUST omitir la clave 2;
cada array de extensiones MUST contener entre 1 y 64 extensiones;
los elementos de cada array MUST estar en orden estrictamente ascendente de los bytes UTF-8 de extension_id, según la comparación de §54, lo que también prohíbe repetir un extension_id dentro del array; el orden no tiene semántica;
un mismo extension_id MUST NOT aparecer simultáneamente en critical_extensions y noncritical_extensions dentro del mismo objeto;
por esas dos reglas, un extension_id aparece como mucho una vez en cada objeto, aunque cambie extension_version; si un schema necesita varios valores, los lleva dentro de su data;
una extensión crítica desconocida MUST provocar rechazo;
una extensión no crítica desconocida MAY ignorarse;
una extensión conocida que aparece en un objeto o array para el que no está registrada se trata allí como desconocida (§54, §72).

El protocolo base no decodifica ni valida el contenido de data (§54).

32. Política `time_only`

Construcción:

CONTROL_CBOR
    ↓
OUTER_TIME_AGE

donde:

OUTER_TIME_AGE =
age file
recipient = tlock(DateKey)
plaintext = CONTROL_CBOR

OUTER_TIME_AGE MUST contener exactamente un stanza, de tipo tlock.

age genera:

FK_TIME = 16 random bytes

y tlock envuelve FK_TIME para la ronda futura.

No existe INNER_ACCESS_AGE.

33. Política `time_and_key`

Construcción:

CONTROL_CBOR
    ↓
INNER_ACCESS_AGE
    ↓
OUTER_TIME_AGE

Primero:

INNER_ACCESS_AGE =
age file
recipients = X25519: en los formatos 2 y 3, 16, credenciales y señuelos (§39)
plaintext = CONTROL_CBOR

INNER_ACCESS_AGE MUST contener stanzas de tipo X25519, exactamente uno por recipient: uno o más en formato 1, y exactamente 16 en los formatos 2 y 3 (§39).

age genera:

FK_ACCESS = 16 random bytes

Después:

OUTER_TIME_AGE =
age file
recipient = tlock(DateKey)
plaintext = exact bytes of INNER_ACCESS_AGE

age genera:

FK_TIME = 16 random bytes

La política implementa:

TIME AND KEY

No dos envolturas paralelas.

34. `SEALED_CONTROL`

En .dkc:

SEALED_CONTROL =
exact bytes of OUTER_TIME_AGE

Debe ser siempre un fichero age completo.

Para time_only, el plaintext interno es CONTROL_CBOR.

Para time_and_key, el plaintext interno es INNER_ACCESS_AGE.

35. tlock strict mode

El recipient/identity tlock V1 MUST usar:

chain hash pinneado;
public key pinneada;
scheme pinneado;
round esperado.

DateKeys MUST desactivar confianza automática en chain hash suministrado por el ciphertext.

La root of trust procede del Provider Profile local.

El stanza tlock tiene exactamente dos argumentos tras el tipo, la ronda y el chain hash, que se comparan como cadenas con las reglas del paso 8 de §63.

36. Comprobación política ↔ estructura

Tras abrir OUTER_TIME_AGE:

Si `access_policy = time_only`

el resultado MUST ser directamente un CONTROL_CBOR canónico válido. Un resultado que empieza por la línea de versión de age (age-encryption.org/v1 seguida de LF) es ERR_POLICY_STRUCTURE_MISMATCH en el paso 12; cualquier otro se decodifica como CONTROL_CBOR en el paso 14, con los códigos de §69.1.

Si `access_policy = time_and_key`

el resultado MUST ser un fichero age v1 válido cuyo header contenga uno o más stanzas en formato 1, o exactamente 16 en los formatos 2 y 3 (§39), todos ellos de tipo X25519, y sin dos stanzas de un solo argumento tras el tipo con el mismo argumento, que en un stanza X25519 es su share efímero. Un resultado cuya cabecera no sigue la gramática de §28.1 no lo es.

age genera un share efímero nuevo para cada stanza X25519: dos stanzas con el mismo share no los produce ningún encoder conforme y, para un mismo recipient, serían dos stanzas para él (§33). Es la parte de «exactamente un stanza por recipient» que se comprueba sin secretos; el resto, y la forma de cada stanza X25519, los comprueba el paso 13 de §63 con las identities ofrecidas.

En los formatos 2 y 3 el límite de 1024 stanzas del parser de la implementación de referencia (§74) no cambia ningún código: una cabecera que lo supera también tiene más de 16 stanzas, y las dos causas dan ERR_POLICY_STRUCTURE_MISMATCH en el paso 12.

Si la estructura no coincide:

ERR_POLICY_STRUCTURE_MISMATCH

36.1 Semántica de autenticidad

time_only NO proporciona autenticidad del creador, ni antes ni después de madurar la condición temporal, salvo que una extensión de firma explícita añada esa propiedad.

La falsificación es posible desde el momento de creación: cifrar hacia una ronda futura solo requiere la clave pública del Provider Profile y la condición temporal pública. Además, header_binding se calcula únicamente a partir de bytes públicos (PRELUDE y PUBLIC_HEADER). Un tercero puede construir otro CONTROL_CBOR con un header_binding correcto, generar su propio I_PAYLOAD, crear su propio PAYLOAD_AGE y sellar ese control hacia la misma DateKey sin esperar a que la ronda madure.

Por tanto capsule_id, DateKey y header_binding proporcionan coherencia interna, no autoría (§55.1).

time_and_key añade una barrera adicional de acceso: un tercero que no posea la identity/capacidad requerida no puede abrir el INNER_ACCESS_AGE. Esta propiedad NO sustituye una firma del creador y no debe presentarse como prueba de autoría.

Los señuelos de §39 no añaden ninguna barrera de acceso ni ninguna autenticidad.

En formato 3, el autor declarado del head (§29.4) es un texto del creador y no prueba autoría, y en esta versión security no prueba nada (§29.3).

37. X25519 recipient V1

V1 adopta el recipient X25519 estándar de age.

Una identity X25519:

I = 32 random bytes from CSPRNG

El recipient correspondiente se deriva según la especificación age.

No se define un KEM propio.

Un recipient X25519 son 32 bytes: la coordenada u de RFC 7748 en little-endian. El escritor MUST rechazar (§62.1):

un recipient no canónico: con el bit 255 a 1, o con u ≥ p = 2²⁵⁵ − 19;
un recipient de orden bajo: aquel para el que X25519(k, u) es la cadena de 32 ceros. Con el recorte de escalares de RFC 7748, el resultado no depende de k.

X25519 ignora el bit 255 y reduce u módulo p, pero age pone los 32 bytes recibidos en el salt de HKDF, y la identity, su clave pública canónica: el stanza de un recipient no canónico no lo abre nadie. Con un recipient de orden bajo, el secreto compartido es cero: age se niega a cifrar, y una librería que no lo comprobara dejaría abrir ese stanza a cualquiera. Las reglas de §63 no detectan ninguno de los dos casos: el stanza no contiene el recipient.

La lista no es exhaustiva. Una u canónica que no está en la curva, sino en su torsión cuadrática (twist), tampoco es la clave pública de ninguna identity, y su stanza tampoco lo abre nadie. Un escritor MAY rechazarla comprobando que u³ + 486662·u² + u es un cuadrado módulo p (símbolo de Legendre).

38. Portable Access Key

Cuando el creador quiere generar una credencial portable, genera:

I_ACCESS = 32 random bytes
R_ACCESS = corresponding X25519 recipient

R_ACCESS se usa como recipient de INNER_ACCESS_AGE. En los formatos 2 y 3 cuenta como una de sus credenciales, como mucho 16, y ocupa una posición aleatoria entre los 16 stanzas (§39).

I_ACCESS se almacena como 32 bytes crudos dentro del .dkk.

Una I_ACCESS portable MUST generarse específicamente para una única capsule_id y MUST NOT reutilizarse en otra DateKeyCap. La reutilización convertiría una misma .dkk en capacidad válida para varias cápsulas y rompería el aislamiento esperado entre objetos.

La representación Bech32 AGE-SECRET-KEY-... MAY mostrarse/exportarse para interoperabilidad humana, pero NO es la representación binaria canónica del campo.

39. Recipients de `INNER_ACCESS_AGE`

Una credencial es un par X25519 que abre INNER_ACCESS_AGE: el escritor recibe su recipient, o genera R_ACCESS (§38), y el lector ofrece su identity, suelta o dentro de una .dkk (§63, paso 9). Contar credenciales es contar recipients distintos.

En los formatos 2 y 3:

INNER_ACCESS_AGE MUST contener exactamente 16 stanzas X25519, uno por hueco;
una cápsula time_and_key MUST tener entre 1 y 16 credenciales, sin repetir ninguna;
cada hueco que no ocupa una credencial lleva un señuelo: la clave pública de una identity X25519 nueva que el escritor genera con un CSPRNG y descarta en el acto. La clave privada de un señuelo MUST NOT almacenarse, registrarse ni entregarse; ningún señuelo se reutiliza ni se deriva de otro valor;
el orden de los 16 stanzas en la cabecera MUST ser una permutación uniformemente aleatoria, obtenida de un CSPRNG sin sesgo —por ejemplo, Fisher–Yates con muestreo por rechazo—, independiente de qué huecos son credenciales y del orden en que el escritor las recibe. La regla vale para la cabecera escrita, no para la llamada a age: filippo.io/age y age-encryption escriben los stanzas en el orden de sus recipients, y una librería que los ordenara o agrupara la rompería;
la permutación y qué huecos son señuelos MUST NOT almacenarse, registrarse ni entregarse, salvo en los vectores oficiales de prueba (§67): revelan el número de credenciales;
toda identity real abre exactamente un stanza, y ninguna abre el de un señuelo.

En formato 1, INNER_ACCESS_AGE contiene (MUST, §33) uno o más stanzas X25519, uno por recipient, sin señuelos ni orden prescrito: es la regla de la v0.8.2.

En todos los formatos, todos los stanzas envuelven la misma:

FK_ACCESS

incluidos los de los señuelos. Por tanto el CONTROL_CBOR y PAYLOAD_AGE no se duplican.

Un señuelo envuelve la misma FK_ACCESS: su clave privada abre la cápsula como una credencial mientras exista. Por eso se descarta en el acto. Nota informativa: las APIs de age no permiten borrarla. generateX25519Identity de age-encryption devuelve una cadena AGE-SECRET-KEY-1… inmutable; age.X25519Identity de Go guarda el escalar sin forma de borrarlo, y la implementación de referencia obtiene sus bytes a través de esa cadena. Un escritor puede generar el escalar en un buffer que pueda borrar, calcular X25519(k, 9), borrar el buffer y dar a age solo el recipient.

Un señuelo es indistinguible de una credencial. Un stanza X25519 de age contiene un share efímero nuevo y la file key cifrada con una clave derivada del secreto compartido con el recipient (C2SP age, §77); el recipient no aparece en él, y los dos tienen la misma forma y la misma longitud, 98 bytes. Es el anonimato de recipient de age X25519, bajo el supuesto de Diffie–Hellman en X25519: saber si un stanza es para una clave pública dada exige el secreto compartido, es decir, la clave privada del recipient o el escalar efímero, que age descarta. Ni siquiera quien conoce FK_ACCESS puede comprobarlo. Quien tiene una credencial sabe cuál es su stanza y nada de los otros 15; varias credenciales juntas solo saben cuántos stanzas abren entre todas. §55.2 enumera lo que los formatos 2 y 3 ocultan y lo que impiden comprobar.

40. Framing `.dkk` V1

offset  size  field
0       4     MAGIC = "DKK1"
4       1     VERSION = 1
5       1     FLAGS = 0
6       2     RESERVED = 0
8       4     BODY_LEN (uint32 BE)
12      ...   BODY_CBOR

V1 MUST exigir:

FLAGS == 0
RESERVED == 0
1 <= BODY_LEN <= 16777216    (16 MiB)

La .dkk conserva VERSION 1 con los tres formatos de .dkc: no contiene nada que dependa del número de credenciales ni del relleno.

BODY_CBOR son exactamente los BODY_LEN bytes que siguen al prelude, y el fichero termina con ellos. La trama se valida en este orden, y el primer fallo decide el código (§69.1):

menos de 4 bytes, o MAGIC distinto de DKK1 → ERR_INVALID_MAGIC;
DKK1 seguido de menos de 8 bytes, un prelude truncado → ERR_INTEGRITY;
VERSION distinto de 1 → ERR_UNSUPPORTED_VERSION;
FLAGS o RESERVED distintos de 0 → ERR_INVALID_FLAGS;
BODY_LEN fuera de su rango; una longitud 0 queda fuera, como en §22 → ERR_INTEGRITY;
menos de BODY_LEN bytes tras el prelude, o algún byte después de BODY_CBOR → ERR_INTEGRITY.

Solo después se decodifica BODY_CBOR, con las capas 2 a 4 de §69.1.

41. `.dkk` BODY_CBOR

Schema:

0 → "datekeys-access-key"
1 → 1
2 → credential_id (16 random bytes)
3 → capsule_id (16 bytes)
4 → access_type
5 → access_material
6 → verification_metadata
7 → critical_extensions
8 → noncritical_extensions

Las claves 6, 7 y 8 son opcionales y se omiten cuando están ausentes (§43, §58.1). Las claves 7 y 8, cuando existen, contienen entre 1 y 64 extensiones (§54).

Para V1 portable X25519:

access_type = "x25519"
access_material = 32 raw identity bytes

42. `credential_id`

Debe ser:

16 random bytes

generados por CSPRNG.

Es un identificador opaco.

No deriva de la key ni de identidad personal.

43. `verification_metadata`

V1 define opcionalmente:

0 → capsule_digest

donde:

capsule_digest =
SHA-256(exact .dkc bytes)

Su función es:

fallo rápido;
detección de fichero equivocado;
UX;
deduplicación.

NO constituye una propiedad de seguridad necesaria para el acceso.

Una identity X25519 solo podrá abrir el INNER_ACCESS_AGE para el que fue utilizada; el digest no sustituye esa propiedad criptográfica.

Si no existe metadata de verificación, la clave verification_metadata MUST omitirse. Un mapa vacío no es una representación canónica válida de ausencia en V1.

44. Extensiones de aplicación en `.dkk`

Información de integración que no pertenezca al protocolo base DEBE ir en:

key 8 → noncritical_extensions

salvo que una futura especificación DateKeys registre una extensión crítica concreta.

De este modo las implementaciones no inventan campos core incompatibles.

La data de esas extensiones viaja en claro junto a la credencial y header_binding no la cubre: el protocolo base no la autentica, y solo informa a quien posee la .dkk (§55.1, §72).

45. Release API

La API recomendada se indexa por condición:

GET /v1/releases/{profile}/{condition}

Ejemplo Quicknet:

GET /v1/releases/datekeys:quicknet:v1/66884212

No requiere capsule_id.

46. Release Queue

La unidad de trabajo es:

profile + condition

No cápsula.

Muchas cápsulas de una misma ronda comparten un único release.

47. Release Cache

Un release publicado puede almacenarse como:

profile
condition
release_material
verified
verified_at

El servidor MUST verificarlo antes de marcarlo como válido.

El SDK MUST verificarlo de nuevo.

48. Multi-relay

La implementación SHOULD soportar varios relays independientes por disponibilidad.

La autenticidad procede de la verificación BLS.

No del hostname.

49. Recuperación directa contra el proveedor

Una implementación conforme SHOULD poder obtener un release directamente del proveedor temporal, sin pasar por la API DateKeys.

Para Quicknet:

.dkc
+
Provider Profile pinneado
+
release obtenido de un relay drand
+
.dkk si la política la exige

debe ser suficiente para ejecutar el flujo de apertura.

La API DateKeys es una capa de conveniencia, disponibilidad y caché, no una autoridad criptográfica obligatoria.

50. Dependencia del histórico de releases

La recuperación años después depende de que el release histórico necesario siga disponible.

Para Quicknet, esto puede provenir de:

un relay drand que conserve/entregue rondas históricas; o
una Release Cache válida conservada por otra fuente.

El protocolo NO debe asumir silenciosamente que cualquier proveedor conservará histórico indefinidamente.

Una aplicación que prometa horizontes largos SHOULD documentar esta dependencia.

51. Verificación de release Quicknet

El SDK MUST comprobar:

expected Provider Profile
expected chain hash
expected round
valid BLS signature

Al descifrar, el paso 10 de §63 fija el orden de estas comprobaciones y sus códigos: primero la ronda (ERR_ROUND_MISMATCH), después la firma (ERR_RELEASE_INVALID). Son los códigos de un release que el llamador suministra directamente: el que llega de una fuente de red y no supera estas comprobaciones lo descarta su fuente en el paso 9, y si ninguna fuente entrega uno que las supere el código es ERR_RELEASE_UNAVAILABLE. El perfil y el chain hash esperados son los del perfil pinneado, cuya clave pública verifica la firma.

Un campo remoto:

verified = true

no tiene valor de seguridad.

52. DNS / MITM

Controlar DNS, TLS termination o un relay no debe permitir fabricar un release válido mientras:

la raíz de confianza esté pinneada;
la condición esperada se calcule localmente;
la firma se verifique.

53. Harvest now, decrypt later

El SDK oficial SHOULD advertir al usuario en horizontes temporales largos.

Debe explicar:

Quicknet V1 no es post-cuántico;
el ciphertext puede permanecer disponible durante años;
la seguridad futura depende del provider y de la criptografía subyacente.

El umbral temporal de la advertencia es política de producto, no parte de la semántica criptográfica del protocolo.

54. Extensiones

PUBLIC_HEADER, CONTROL_CBOR, .dkk y, en formato 3, el head (§29.4) pueden incluir extensiones mediante el mismo mecanismo.

Cada extensión declara:

0 → extension_id
1 → extension_version
2 → data (opcional)

El par:

(extension_id, extension_version)

identifica el schema de la extensión. extension_id es una cadena de texto UTF-8 de al menos 1 byte (§31), y extension_version un entero sin signo entre 0 y 2³² − 1 (4294967295).

La posición del array determina si la extensión es:

critical

noncritical

Reglas:

una extensión crítica desconocida → MUST reject (ERR_EXTENSION_CRITICAL_UNKNOWN);
una extensión no crítica desconocida → MAY ignore;
una extensión conocida que aparece en un objeto o array para el que no está registrada (§72) se trata allí como desconocida: crítica → MUST reject (ERR_EXTENSION_CRITICAL_UNKNOWN); no crítica → MAY ignore, y una implementación MUST NOT interpretar su data;
los elementos de cada array MUST estar en orden estrictamente ascendente de los bytes UTF-8 de extension_id (ver abajo), lo que también prohíbe repetir un extension_id dentro del array;
un mismo extension_id MUST NOT aparecer simultáneamente en critical_extensions y noncritical_extensions dentro del mismo objeto;
por esas dos reglas, un mismo extension_id no aparece más de una vez en el mismo objeto, aunque cambie extension_version; la multiplicidad, si un schema la necesita, va dentro de su data;
cada array de extensiones contiene entre 1 y 64 extensiones: un encoder MUST NOT producir más de 64 y un decoder MUST rechazar un array de más de 64.

Orden de extension_id: dos identificadores se comparan byte a byte sobre su codificación UTF-8, con cada byte como entero sin signo (0x00 a 0xFF); el primer byte distinto decide, y si uno es prefijo propio del otro, el más corto va primero. Nunca se comparan unidades de código UTF-16 ni se aplica la colación de una locale, un orden sin distinción de mayúsculas o una normalización Unicode. Para UTF-8 válido este orden coincide con el de los puntos de código, y difiere del de UTF-16: U+FF61 (ef bd a1) va antes que U+10000 (f0 90 80 80). Un encoder MUST escribir cada array en este orden y un decoder MUST rechazar cualquier otro, o un extension_id repetido, con ERR_NON_CANONICAL_CBOR.

data (clave 2):

MUST ser una cadena de bytes CBOR (bstr, tipo mayor 2) de al menos 1 byte;
una extensión sin datos MUST omitir la clave 2; h'' (0x40) es inválido;
cualquier otro tipo CBOR en la clave 2 es inválido;
su longitud está acotada por la trama del objeto que la contiene (§57);
su contenido es opaco: el protocolo base nunca lo decodifica ni lo valida, y la validez base de PUBLIC_HEADER, CONTROL_CBOR, .dkk y el head nunca depende de él.

Una data vacía o de tipo distinto de bstr y un array de más de 64 extensiones son violaciones del CDDL: MUST rechazarse con ERR_NON_CANONICAL_CBOR (§57).

Solo una implementación que conoce (extension_id, extension_version) en el objeto y el array en que aparece interpreta su data, conforme a su schema registrado (§72):

una extensión crítica conocida cuya data no cumple su schema registrado → MUST reject (ERR_EXTENSION_DATA_INVALID);
una extensión no crítica conocida cuya data no cumple su schema registrado no invalida el objeto: la implementación MUST tratarla como inutilizable, sin usar su data, y MUST notificarlo al llamador.

La información específica de una aplicación que no pertenezca al núcleo DateKeys —incluidos datos de transporte o descubrimiento si una aplicación los necesita— MUST ir en noncritical_extensions y no en campos core del protocolo.

55. Integridad auxiliar

Hashes públicos MAY utilizarse para:

identificación;
caché;
deduplicación;
auditoría;
UX.

No sustituyen:

header MAC de age;
X25519 wrapping;
tlock;
STREAM authentication;
header_binding.

55.1 Modelo de confianza por sección

La tabla resume, para cada sección de un .dkc y para una .dkk, quién puede escribirla, desde qué paso de §63 queda vinculada al resto de la cápsula y mediante qué, y qué no prueba nunca. Ninguna fila prueba autoría: solo una extensión de firma puede aportarla (§36.1, §72). La tabla es normativa: una implementación MUST NOT presentar una sección como prueba de algo que su columna «Nunca prueba» excluye, salvo que lo cubra una extensión de firma.

Sección	Quién puede escribirla	Vinculada desde el paso, mediante	Nunca prueba
`PRELUDE` y `PUBLIC_HEADER`	Cualquiera que tenga el `.dkc`: viajan en claro y ninguna clave los protege.	Paso 15: `header_binding`, dentro de `CONTROL_CBOR`, cubre sus bytes exactos (§26). Los pasos 1 a 8 solo comprueban su estructura.	Autoría ni fecha de creación: `header_binding` se calcula con bytes públicos (§36.1). Antes del paso 15, ni siquiera su coherencia con el control.
`CONTROL_CBOR`	Cualquiera puede sellar un control hacia la DateKey, porque basta la clave pública del perfil (§36.1). En `time_and_key`, uno que abra una credencial dada solo quien conozca la clave pública de su recipient.	Paso 11: el MAC de la cabecera `age` y STREAM de `OUTER_TIME_AGE`, y en `time_and_key` los de `INNER_ACCESS_AGE` en el paso 13, autentican sus bytes frente a quien no conoce la file key. Paso 15: `header_binding` lo vincula a `PUBLIC_HEADER`.	Que lo escribiera el creador de `PUBLIC_HEADER`: un tercero puede sellar otro control con un `header_binding` correcto. Tras la apertura, quien conoce `FK_TIME` o `FK_ACCESS` puede reescribirlo.
`PAYLOAD_AGE`	Quien conoce `R_PAYLOAD`: antes de la apertura, solo quien selló el control; después, cualquiera que haya abierto `CONTROL_CBOR` y obtenido `I_PAYLOAD`.	Paso 17: `I_PAYLOAD` desenvuelve `FK_PAYLOAD`, y el MAC de la cabecera y STREAM autentican cada byte (§30.1). En los formatos 2 y 3, L y el código de `CONTROL_CBOR` fijan además su longitud y su relleno (§29.1).	Autoría; tampoco que siga siendo el payload original después de que alguien haya abierto la cápsula, porque puede cifrar otro para `R_PAYLOAD`. Tampoco que L sea la longitud original: quien puede reescribir el control puede declarar otra L de la misma P (§30.1).
Contenido de formato 3: `security`, head y ficheros (§29.2)	Quien escribe `PAYLOAD_AGE`, porque es su plaintext.	Paso 17: los autentican el MAC de la cabecera y STREAM de `PAYLOAD_AGE`, y el head fija el tamaño y el SHA-256 de cada fichero (§29.4).	Autoría ni fecha: el autor declarado, el comentario, las rutas y las mtimes son texto del creador. En esta versión, `security` tampoco prueba nada (§29.3, §29.7).
Cuerpo de la `.dkk`	Cualquiera que tenga la `.dkk`: no lleva MAC ni firma.	Paso 9.a: su `capsule_id` debe ser el de `PUBLIC_HEADER`, un valor público, y su `capsule_digest`, cuando existe y se comprueba, la ata a los bytes exactos de un `.dkc` (§43). Paso 13: `access_material` abre `INNER_ACCESS_AGE` solo si es la identity de uno de sus recipients.	Que la emitiera el creador de la cápsula. La `data` de sus extensiones no queda vinculada a nada.

En consecuencia, una afirmación de la que dependa una decisión de seguridad del lector —autorización, identidad, integridad o fecha— no puede apoyarse en PUBLIC_HEADER ni en una .dkk sin una extensión de firma, y la data de las extensiones de una .dkk solo informa a quien la posee (§72).

55.2 Consideraciones de privacidad

Esta sección enumera qué revela una cápsula y a quién. No añade reglas de lectura: resume las consecuencias de §22, §24, §29.1, §31 y §39. Describe los formatos 2 y 3; el formato 1 revela más (al final).

Visible para quien tenga el `.dkc`, antes y después de la fecha

VERSION, que es el formato, PUBLIC_HEADER_LEN y SEALED_CONTROL_LEN. VERSION 1 revela un escritor anterior a la v0.9, y VERSION 2, uno de la v0.9 (§62.1);
capsule_id, que permite reconocer copias de la misma cápsula;
la DateKey: el perfil y la ronda, y por tanto el instante de apertura;
access_policy: si hace falta una credencial. Sigue visible para que el paso 9 pueda fallar sin red (ERR_ACCESS_REQUIRED);
las extensiones de PUBLIC_HEADER, con su data;
el stanza tlock de OUTER_TIME_AGE: la ronda y el chain hash;
la cabecera de PAYLOAD_AGE y su longitud, que da P exactamente: 184 + P + 16·max(1, ⌈P / 65536⌉). P acota L: entre 0 y 256 si P = 256; si no, a un intervalo de 256 bytes con bloque256, y con reforzado, de 256 bytes hasta L = 8192 y de como mucho P / 16 por encima. Con bloque256 el intervalo es de 256 bytes a cualquier tamaño: un fichero público conocido puede reconocerse por su tamaño. En formato 3, L es la longitud de BODY, así que P acota además el número de ficheros y la longitud de sus rutas y del comentario: con el área de 512 bytes y pocos ficheros, n ≤ (P − 579)/45, es decir, como mucho 4 ficheros con P = 768. El tamaño del área depende de la versión del escritor, no de lo que lleve security (§29.2);
la longitud de CONTROL_CBOR, que se deduce de SEALED_CONTROL_LEN (§62.1): 103 bytes más los de sus extensiones. Revela el tamaño de las extensiones de control, no su contenido. No depende de L, que ocupa siempre 8 bytes, ni del número de credenciales, porque INNER_ACCESS_AGE tiene siempre 16 stanzas.

El código de relleno va sellado, pero P lo delata a veces: los dos códigos dan la misma P para L ≤ 8192, y por encima una P que reforzado no produce revela bloque256, y con él un escritor que no usa el código por defecto (§29.1).

Oculto hasta la fecha

el contenido y su longitud exacta L;
el código de relleno, salvo lo que delata P;
I_PAYLOAD y todo CONTROL_CBOR, incluida la data de sus extensiones;
en formato 3, security, el head y los ficheros: sus rutas, sus tamaños, sus hashes y sus mtimes, el comentario y el autor declarado, y su número, salvo la cota que da P;
en time_and_key, el número de credenciales y la cabecera de INNER_ACCESS_AGE. En time_only no hay credenciales, y access_policy lo dice.

Después de la fecha

Publicada la ronda, cualquiera puede abrir OUTER_TIME_AGE:

time_only: cualquiera lee CONTROL_CBOR y el contenido, con L y el código, y en formato 3, el head y todos los ficheros. Nada queda oculto;
time_and_key: cualquiera ve la cabecera de INNER_ACCESS_AGE, siempre con 16 stanzas; CONTROL_CBOR y el contenido siguen ocultos para quien no tiene una credencial. Quien tiene una lee L, el código, el contenido y las extensiones de control, y sabe cuál es su stanza; no sabe cuáles de los otros 15 son señuelos. Varias credenciales juntas solo saben cuántos stanzas abren entre todas: una cota inferior del número de credenciales.

Nunca visible

Bajo el supuesto de Diffie–Hellman en X25519 (§39):

los recipients: un stanza X25519 no contiene la clave pública de su recipient, y comprobar si un stanza es para una clave pública dada exige su clave privada o el escalar efímero;
si un stanza es de un señuelo;
si existe una .dkk portable y cuál es su stanza, para quien no la tiene;
el número de credenciales, salvo la cota inferior de arriba.

Ese supuesto no resiste a un adversario cuántico futuro (§7.7): quien conserve el .dkc y conozca claves públicas candidatas podría recuperar los escalares efímeros y comprobar para cuáles hay un stanza, e identificar así a los recipients reales.

Lo que los formatos 2 y 3 impiden comprobar

En formato 1, quien esperaba n recipients podía contar los stanzas. En los formatos 2 y 3 nadie salvo el escritor puede saber cuántas partes pueden abrir la cápsula.
Nadie puede comprobar que el escritor descartó las claves privadas de los señuelos (§39). Un SDK comprometido (§7.5) o un dispositivo del creador comprometido (§7.8) puede conservar una como credencial oculta, y nadie lo notaría.

Fuera del `.dkc`

una .dkk lleva en claro la credencial, access_material, y además capsule_id, credential_id, el capsule_digest opcional, que la ata a los bytes exactos de un .dkc, y la data de sus extensiones (§41, §43, §44);
pedir el release revela a la Release API y a los relays el perfil, la ronda y la dirección de quien pregunta, pero no capsule_id (§45, §48);
el nombre del fichero .dkc, sus fechas en el sistema de ficheros y el canal de entrega no pertenecen al protocolo (§6). En formato 3, los nombres y las mtimes de los ficheros que guarda la cápsula sí van dentro, cifrados en el head (§29.4).

Formato 1

Una cápsula de formato 1 no oculta ni el número de credenciales ni L:

SEALED_CONTROL_LEN crece 98 bytes por stanza de INNER_ACCESS_AGE: en los fixtures de la v0.8.2, 646 bytes con una credencial y 842 con tres;
la longitud de PAYLOAD_AGE, 184 + L + 16·max(1, ⌈L / 65536⌉), da L exacta.

El protocolo no rellena la data de las extensiones. Una extensión registrada que necesite ocultar su longitud define su propio relleno (§72).

56. Atomic plaintext output

El descifrado SHOULD usar:

fichero temporal;
stream transaccional;
mecanismo equivalente.

No debe presentar plaintext parcial como válido si falla cualquier autenticación posterior.

En formato 2, un lector MUST NOT presentar como válidos los L primeros bytes, el contenido, antes de que el paso 17 termine sin error, con la comprobación de la longitud y del relleno (§63, paso 18). Un lector que escribe el contenido en streaming MUST NOT escribir el relleno y MUST señalar el error del paso 17, para que se descarte lo escrito como en el resto de esta sección. Esa comprobación solo termina después del último byte del contenido: un lector no transaccional, o un llamador que ignora el error, tendría un contenido de aspecto completo de un objeto inválido.

En formato 3, un lector MUST NOT presentar como válidos ningún fichero, el head ni ningún veredicto antes de que el paso 17 termine sin error (paso 18). Un lector que escribe los ficheros en un sistema de ficheros mientras los descifra:

MUST escribirlos en un lugar temporal y moverlos a su destino solo en el paso 18, y ante cualquier fallo MUST borrarlos;
MUST crearlos dentro de un directorio que él mismo crea y que no existía, con las rutas del head (§29.5), sin seguir enlaces simbólicos, sin sobrescribir nada y sin escribir fuera de él;
no crea nada para una cápsula sin ficheros.

Un lector que entrega los ficheros en un ZIP MUST usar como nombre de cada entrada su ruta del head, en UTF-8 y con el bit 11 del campo de flags, y MUST NOT añadir entradas que el head no tiene. El ZIP se entrega como un fichero único, con las reglas de esta sección.

Nota informativa: la implementación de referencia reclama el directorio de destino con os.Mkdir, que falla si ya existe; escribe el árbol en DIR/.datekeys-* con os.OpenRoot, O_EXCL y permisos 0600; tras el paso 18 lleva cada entrada al primer nivel con Root.Rename; y ante cualquier fallo borra el directorio que creó. La página de datekeys-ts escribe entradas almacenadas, sin compresión, descriptores de datos ni entradas de carpeta; pasa a ZIP64 con 65 535 entradas o con algún tamaño u offset de 2³² − 1 o más; y guarda la mtime como hora DOS en UTC, recortada a 1980–2107, con el campo extra 0x000A siempre y el 0x5455 si cabe en 32 bits con signo. Como las entradas van sin comprimir, cada fichero es un tramo continuo del ZIP y puede descargarse suelto.

57. Límites del parser

Encoders y decoders MUST aplicar estos límites de trama:

1 byte <= PUBLIC_HEADER <= 1 MiB
1 byte <= SEALED_CONTROL <= 64 MiB
1 byte <= DKK BODY <= 16 MiB

un encoder MUST NOT producir un objeto que los supere;
un decoder MUST rechazar un objeto que los supere;
una trama vacía no contiene ningún objeto válido: una longitud 0 queda fuera de rango (§22, §40);
cada trama acota todo lo que contiene, incluida la data de las extensiones (§54); CONTROL_CBOR queda acotado por SEALED_CONTROL.

PAYLOAD_AGE no tiene trama propia: va hasta EOF, se procesa en streaming y es, como mínimo, una cabecera age bien formada (§22, §28.1). En los formatos 2 y 3 su plaintext mide exactamente P = regla(L) (§29.1).

Los tamaños se validan antes de reservar memoria.

L (clave 6 de CONTROL_CBOR) y P no son longitudes de trama. Cualquiera puede sellar un control time_only que declara L = L_MAX junto a un PAYLOAD_AGE de 456 bytes (§36.1). Un lector MUST NOT reservar memoria ni disco según L o P antes de recibir el plaintext que los respalda: los acota el ciphertext.

En formato 3 (§29.2):

AREA_LEN, SECURITY_LEN y HEAD_LEN van en el plaintext de PAYLOAD_AGE, no en la trama del .dkc: se comprueban en el paso 17, con ERR_INTEGRITY. Un lector MUST NOT reservar memoria según ellas, ni según size, start o end, antes de recibir los bytes que declaran;
el área mide como mucho 64 KiB y el head, 16 MiB: un lector puede tener los dos enteros en memoria;
los límites del head (§29.4 a §29.6) son normativos y quedan fijados con el formato 3 (§22).

Límites del escritor que el lector no comprueba como trama (§62.1):

time_and_key admite entre 1 y 16 credenciales (§39); un lector de los formatos 2 y 3 solo ve 16 stanzas;
L es como mucho L_MAX = 2⁵³ − 2⁴⁶ (§29.1); un lector lo comprueba en CONTROL_CBOR (§31), con ERR_NON_CANONICAL_CBOR.

Correspondencia de errores:

una longitud de trama (PUBLIC_HEADER_LEN, SEALED_CONTROL_LEN y el BODY_LEN de la .dkk) fuera de estos límites, incluida una longitud 0, o un objeto que supera el límite de su trama → ERR_INTEGRITY;
cualquier violación de una regla normativa de datekeys.cddl, incluidas las restricciones de tipo, de tamaño y de rango, el orden de los extension_id, el máximo de 64 extensiones por array, y las de las claves 6 y 7 de CONTROL_CBOR (§31) → ERR_NON_CANONICAL_CBOR, salvo los casos con código propio: versión de schema (clave 1) que el objeto no admite —para CONTROL_CBOR, la que no corresponde al formato de su cápsula (§22, §31)— → ERR_UNSUPPORTED_VERSION (§70); compact_datekey → ERR_DATEKEY_INVALID o ERR_DATEKEY_NON_CANONICAL (§19); access_type no soportado o access_material de longitud incorrecta → ERR_ACCESS_INVALID; en el Provider Profile, un profile_id, provider, network o scheme que no cumple su regla, o una clave pública (clave 6) fuera de la suya → ERR_UNKNOWN_PROFILE (§12.1, §13);
en formato 3, una violación de la trama del contenido (§29.2) → ERR_INTEGRITY; una de las reglas del head con código propio (§29.4 a §29.6, capa 4 de §69.1) → ERR_HEAD_INVALID; y las de security, ningún código (§29.3);
un código propio se aplica a un campo que ya tiene el tipo CBOR de su regla: un compact_datekey, access_type o nombre del perfil que no es una cadena de texto, o un access_material o una clave pública que no es una cadena de bytes, es ERR_NON_CANONICAL_CBOR;
las reglas que datekeys.cddl marca como límites de la implementación de referencia no son normativas mientras §74 deje abiertos los límites definitivos de campos; quien las aplica usa esta misma correspondencia (§74 las enumera).

Cuando unos bytes violan varias reglas, el código es el de la primera capa que falla, en el orden de §69.1.

58. Canonical CBOR

Todas las estructuras CBOR del protocolo MUST:

usar Deterministic CBOR con el perfil CBOR del protocolo definido en esta sección;
rechazar siempre codificaciones no canónicas;
usar enteros de clave según los schemas normativos.

Perfil CBOR del protocolo: Deterministic CBOR (RFC 8949 §4.2.1) restringido a:

tipos mayores 0 (entero sin signo), 2 (cadena de bytes), 3 (cadena de texto), 4 (array) y 5 (mapa);
claves de mapa que son enteros sin signo;
longitudes definidas;
enteros y longitudes en su forma más corta;
claves de mapa en orden ascendente estricto, sin duplicados;
mapas cerrados: una clave no prevista por el schema MUST rechazarse;
cadenas de texto en UTF-8 válido.

Con claves enteras sin signo en su forma más corta, el orden por bytes de RFC 8949 §4.2.1 coincide con el orden numérico.

Se rechazan expresamente, con ERR_NON_CANONICAL_CBOR:

enteros negativos (tipo mayor 1);
tags (tipo mayor 6);
flotantes y valores simples, incluidos false, true, null y undefined (tipo mayor 7);
longitudes indefinidas;
claves de mapa que no son enteros sin signo.

Los schemas del protocolo acotan todo entero sin signo a 2⁵³ − 1 (9007199254740991) como máximo (§11, §54), de modo que cada uno se representa exactamente como double IEEE 754.

L (clave 6 de CONTROL_CBOR) no es un entero CBOR: es una cadena de 8 bytes con un entero sin signo big-endian de como mucho 2⁵³ − 2⁴⁶ (§31), también exacto como double. Un decodificador lee los 8 bytes: uno que solo leyera los 4 últimos tomaría 48 0000000100000001, L = 2³² + 1, por L = 1.

En la data de una extensión, el perfil se aplica a la cabecera de la cadena de bytes (tipo mayor 2 y longitud en su forma más corta), nunca a su contenido (§54). Las extensiones registradas cuya data sea CBOR siguen además §72.

En formato 3, SECURITY_CBOR y HEAD_CBOR siguen este perfil, y también el contenido de las claves 2 y 3 de security, que se valida aparte (§29.3). En SECURITY_CBOR y en ese contenido, lo que este perfil rechaza no tiene código ni detiene la apertura: solo cambia los veredictos (§29.7).

58.1 Regla global para campos opcionales

V1 usa una única convención:

Un campo opcional semánticamente ausente MUST omitirse.

No se debe representar ausencia mediante:

{}
[]
null
""
h''

salvo que el schema de ese campo defina expresamente uno de esos valores como dato real. null no puede serlo nunca: el perfil de §58 excluye los valores simples.

Por tanto:

metadata opcional ausente → clave omitida;
arrays opcionales sin elementos → clave omitida;
mapas opcionales sin entradas → clave omitida;
listas de extensiones vacías → clave omitida;
extensión sin data → clave 2 omitida; h'' es inválido (§54);
las claves 6 y 7 de CONTROL_CBOR de las versiones 2 y 3 son obligatorias y nunca se omiten; L = 0 es un dato real (48 0000000000000000), no una ausencia, y ningún código de relleno representa «sin relleno» (§29.1, §31);
en formato 3, un head sin comentario, sin autor o sin ficheros omite su clave 3, 4 o 5; una entrada sin mtime omite su clave 5; y security sin firma ni sello omite sus claves 2 y 3 (§29.3, §29.4).

Esto reduce representaciones equivalentes y simplifica vectores canónicos.

59. Supply-chain security

Implementaciones oficiales SHOULD:

pinnear dependencias criptográficas;
publicar SBOM;
firmar releases;
publicar hashes;
publicar perfiles firmados;
usar builds reproducibles cuando sea viable;
fuzzear parsers;
publicar vectores;
someter v1.0 a revisión criptográfica externa.

60. Interfaces Go conceptuales

type Condition any
type Release any

type TimeProvider interface {
    ProfileID() string

    Resolve(time.Time) (Condition, error)
    EffectiveTime(Condition) (time.Time, error)

    FetchRelease(
        context.Context,
        Condition,
    ) (Release, error)

    VerifyRelease(
        Condition,
        Release,
    ) error
}

61. Flujo de cifrado `time_only`

Un orden válido para escribir una cápsula de formato 3. Un escritor MAY seguir otro que produzca un objeto equivalente y cumpla §62.1.

1. Validar las opciones (§62.1): ninguna credencial; instante pedido
   posterior al reloj del escritor; al menos un fichero o un
   comentario; rutas (§29.5) y textos (§29.6) válidos; código de
   relleno 1 o 2; extensiones conformes a §54 y §72.
2. Medir el contenido (§29.2, §29.4): el tamaño y, si se incluye, la
   mtime de cada fichero; HEAD_CBOR con sus SHA-256 y su sal a cero,
   que mide lo mismo que el definitivo, de como mucho 16 MiB; y
   L = 12 + 512 + |HEAD_CBOR| + C, como mucho L_MAX.
3. Primera pasada: el SHA-256 de cada fichero.
4. Resolver DateKey localmente (§15).
5. Generar capsule_id (CSPRNG, §21).
6. Generar I_PAYLOAD X25519 nueva (CSPRNG, §29).
7. Construir PUBLIC_HEADER (versión de schema 1).
8. Medir SEALED_CONTROL_LEN (§62.1): la longitud del OUTER_TIME_AGE
   del paso 13 con un CONTROL_CBOR de 103 bytes más sus extensiones.
   Más de 64 MiB → error (§57).
9. Construir PRELUDE: VERSION = 3 y las longitudes de los pasos 7 y 8.
10. Calcular header_binding = SHA-256(PRELUDE || PUBLIC_HEADER).
11. Crear CONTROL_CBOR, versión de schema 3:
      header_binding
      I_PAYLOAD
      critical_extensions
      noncritical_extensions
      payload_length = L
      padding = código
12. Construir HEAD_CBOR, con una sal nueva (CSPRNG) y los SHA-256 del
    paso 3, y SECURITY_CBOR vacío (§29.3). Decodificar CONTROL_CBOR,
    HEAD_CBOR y SECURITY_CBOR con las reglas del lector (§62.1,
    regla 17).
13. Crear OUTER_TIME_AGE:
      age genera FK_TIME (16 bytes)
      recipient = tlock(DateKey)
      plaintext = CONTROL_CBOR
    Su longitud MUST ser la del paso 8.
14. SEALED_CONTROL = OUTER_TIME_AGE.
15. Escribir PRELUDE || PUBLIC_HEADER || SEALED_CONTROL.
16. Escribir PAYLOAD_AGE a continuación:
      age genera FK_PAYLOAD (16 bytes)
      recipient = R_PAYLOAD
      plaintext = BODY || 0x00^(P − L), P = regla(L) (§29.1), con
        BODY = 512 || |SECURITY_CBOR| || |HEAD_CBOR| (uint32 BE)
            || SECURITY_CBOR || ceros hasta 512 bytes
            || HEAD_CBOR || los ficheros en el orden del head
    Segunda pasada: si un fichero no mide lo que declara su entrada o
    su SHA-256 cambia → error, y lo escrito se descarta (§62.1,
    reglas 9 y 18).

File keys utilizadas:

FK_PAYLOAD
FK_TIME

62. Flujo de cifrado `time_and_key`

Un orden válido para escribir una cápsula de formato 3, como en §61.

1. Validar las opciones (§62.1): entre 1 y 16 credenciales —los
   recipients X25519 dados y, si se pide, una clave portable—, sin
   repetir ninguna, canónicas y no de orden bajo (§37); el resto,
   como en §61.
2. Medir el contenido y hacer la primera pasada, como en §61, pasos
   2 y 3.
3. Resolver DateKey localmente.
4. Generar capsule_id.
5. Generar I_PAYLOAD X25519 nueva.
6. Si se pide una clave portable: generar I_ACCESS (§38).
7. Completar 16 recipients con señuelos (§39): por cada hueco libre,
   generar un escalar X25519 nuevo (CSPRNG), calcular su clave
   pública y borrar el escalar. Permutar los 16 al azar (CSPRNG,
   sin sesgo).
8. Construir PUBLIC_HEADER.
9. Medir SEALED_CONTROL_LEN (§62.1): la del OUTER_TIME_AGE del paso
   14, que contiene un INNER_ACCESS_AGE de 16 stanzas. Más de 64 MiB
   → error (§57).
10. Construir PRELUDE (VERSION = 3).
11. Calcular header_binding.
12. Crear CONTROL_CBOR, versión de schema 3, con los campos de §61,
    paso 11, y construir HEAD_CBOR y SECURITY_CBOR como en §61,
    paso 12.
13. Crear INNER_ACCESS_AGE:
      age genera FK_ACCESS
      recipients = los 16 del paso 7, en ese orden
      plaintext = CONTROL_CBOR
    Sus 16 stanzas MUST quedar en el orden del paso 7 (§39).
14. Crear OUTER_TIME_AGE:
      age genera FK_TIME
      recipient = tlock(DateKey)
      plaintext = exact INNER_ACCESS_AGE bytes
    Su longitud MUST ser la del paso 9.
15. SEALED_CONTROL = OUTER_TIME_AGE.
16. Escribir PRELUDE || PUBLIC_HEADER || SEALED_CONTROL.
17. Escribir PAYLOAD_AGE como en §61, paso 16.
18. Si se generó I_ACCESS: escribir I_ACCESS cruda en una .dkk
    (§40 a §43), con el capsule_digest del .dkc completo si se
    incluye.

Las tres file keys son:

FK_PAYLOAD
FK_ACCESS
FK_TIME

y MUST ser independientes.

62.1 Reglas del escritor

Un escritor conforme con esta versión cumple estas reglas, siga o no el orden de §61 y §62.

MUST:

Formato. Escribir el formato 3: VERSION = 3 (§22) y CONTROL_CBOR de versión 3 (§31). MUST NOT escribir los formatos 1 ni 2; solo un generador de vectores de prueba MAY hacerlo (§70).
Instante. Rechazar un requested_unlock_at que no sea posterior al instante actual de su reloj. La ronda se resuelve después, con §15. Esta regla solo evita un error del usuario: con el reloj retrasado, un escritor puede sellar hacia una ronda ya publicada. El SDK oficial SHOULD mostrar el instante efectivo de la ronda (§15) y MAY comparar la ronda con la última publicada cuando tiene red.
Credenciales. Con time_only, rechazar cualquier credencial. Con time_and_key, exigir entre 1 y 16 credenciales —recipients X25519 y, si se pide, la clave portable (§38)—, rechazar una clave pública repetida y rechazar todo recipient que no sea X25519, que no sea canónico o que sea de orden bajo (§37). Sin credenciales nadie abriría la cápsula; una repetida daría a su identity dos stanzas, y la cápsula fallaría para ella en el paso 13.
Huecos. Completar los 16 recipients con señuelos y dejar los 16 stanzas en un orden uniformemente aleatorio (§39). Las claves privadas de los señuelos MUST NOT almacenarse, registrarse ni entregarse; la permutación y qué huecos son señuelos, tampoco, salvo en los vectores oficiales de prueba (§67).
Aleatoriedad. Obtener de un CSPRNG, nuevos para cada cápsula, capsule_id (§21), I_PAYLOAD (§29), I_ACCESS (§38), credential_id (§42), los señuelos y el orden de los stanzas. I_PAYLOAD y los señuelos MUST NOT reutilizarse ni derivarse de otro valor: una I_PAYLOAD compartida o derivada rompe la confidencialidad de §29, y la clave privada de un señuelo abre la cápsula (§39).
Contenido. Conocer L antes de sellar CONTROL_CBOR, con L ≤ L_MAX, y usar el código 1 o 2 (§29.1). En formato 3, L es la longitud de BODY (§29.2): la dan los tamaños de los ficheros y la longitud del head, que no depende de sus SHA-256 ni de su sal. Un escritor cuya fuente no declara su longitud MAY volcarla antes a un fichero temporal para medirla; MUST NOT suponer L. Si el contenido no mide exactamente L bytes, la cápsula fallaría en el paso 17, cuando ya no puede repararse: se aplica la regla 9.
Longitud del control. Escribir en SEALED_CONTROL_LEN la longitud exacta de SEALED_CONTROL. header_binding cubre el PRELUDE y va dentro de CONTROL_CBOR, así que esa longitud debe conocerse antes de calcular header_binding. La de un fichero age depende solo de la longitud de su plaintext y de la forma de sus stanzas, y la de CONTROL_CBOR de versión 2 o 3 no depende de header_binding, I_PAYLOAD, L ni el código, todos de tamaño fijo. El escritor MAY medirla sellando antes un CONTROL_CBOR provisional de la misma longitud, con header_binding e I_PAYLOAD a cero, o calcularla con la nota de abajo. En los dos casos MUST comprobar que el sellado real mide lo mismo.
Límites. Respetar los límites de §57 y las reglas de extensiones de §54 y §72.
Errores. Ante cualquier error, informar de él y no presentar lo escrito como una cápsula. Un escritor en streaming no puede recuperar lo que ya escribió: quien recibe su salida MUST descartarla, como en §56.

SHOULD:

Código por defecto. El SDK oficial SHOULD usar el código 2.
Autocomprobación. Antes de sellar, el escritor SHOULD decodificar su PUBLIC_HEADER y su CONTROL_CBOR con las reglas del lector (§63, pasos 4 y 14). Después SHOULD comprobar:
- que INNER_ACCESS_AGE tiene 16 stanzas X25519 con shares distintos, y que cada identity que genera y conserva, como I_ACCESS, abre exactamente uno;
- que I_PAYLOAD abre la cabecera de PAYLOAD_AGE;
- que entregó a age exactamente P bytes de plaintext y que PAYLOAD_AGE mide 184 + P + 16·max(1, ⌈P / 65536⌉). Sin esta comprobación, un relleno omitido revelaría L exacta y la cápsula fallaría en el paso 17.
Una cápsula que el lector rechaza solo se descubre tras la fecha.
Borrado. El escritor SHOULD borrar de la memoria, en cuanto dejan de necesitarse, I_PAYLOAD, CONTROL_CBOR y sus copias, las copias de I_ACCESS que no entrega en la .dkk y los buffers del contenido; los que usa la autocomprobación, después de ella. Los escalares de los señuelos se descartan en el acto (regla 4, §39).

En formato 3, además, MUST:

Área. Escribir AREA_LEN = 512 y SECURITY_CBOR en todas las cápsulas, sin que dependa de ninguna opción ni de lo que el escritor sepa hacer (§29.2). En esta versión, 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).
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.
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.
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.
Autodecodificación. Decodificar CONTROL_CBOR, HEAD_CBOR y SECURITY_CBOR con las reglas del lector (§63, pasos 14 y 17) antes de escribir la cápsula. A diferencia de la regla 11, es un MUST: un head que el lector rechaza solo se descubre tras la fecha.
Ficheros estables. Escribir cada fichero con el tamaño y el SHA-256 de su entrada. Si un fichero cambia entre la medida y la escritura, abortar, como en la regla 9.

Nota informativa: longitudes en Quicknet. Con age estándar, un stanza X25519 mide 98 bytes, y el stanza tlock, 249 + d, con d el número de dígitos decimales de la ronda. Con c(n) = max(1, ⌈n / 65536⌉) y k stanzas X25519 (16 en los formatos 2 y 3):

PAYLOAD_AGE      = 184 + P + 16·c(P)                ; P = L en formato 1
INNER_ACCESS_AGE = 86 + 98·k + C + 16·c(C)          ; C = |CONTROL_CBOR|
OUTER_TIME_AGE   = 335 + d + n + 16·c(n)            ; n = C en time_only,
                                                    ; |INNER_ACCESS_AGE| en time_and_key

Sin extensiones de control, C = 103: en la ronda 1000, SEALED_CONTROL_LEN vale 458 en time_only y 2128 en time_and_key. Las fórmulas dan también las longitudes de los cinco fixtures de formato 1 (§67), con C = 91 (127 en time_only_extensions) y k = 1 o 3 en los dos time_and_key.

63. Flujo de descifrado

1. Parsear DKC1: MAGIC y PRELUDE completo (§23).

2. Validar PRELUDE: version, que es el formato (1, 2 o 3), flags,
   reserved, longitudes y límites (§22, §23). Los pasos siguientes
   aplican las reglas de ese formato.

3. Leer PUBLIC_HEADER exacto.

4. Validar PUBLIC_HEADER con las capas de §69.1: tipo y versión de
   schema (§70), la versión 1 en los tres formatos, CBOR canónico y
   CDDL; después, en orden de clave, DateKey canónica (clave 3),
   Provider Profile pinneado y extensiones críticas (clave 5, §54):
       alguna desconocida → ERR_EXTENSION_CRITICAL_UNKNOWN;
       todas conocidas, alguna con data inválida
           → ERR_EXTENSION_DATA_INVALID.

5. Leer SEALED_CONTROL exacto (faltan bytes → ERR_INTEGRITY).
   SHOULD: inspeccionar su cabecera age, la de OUTER_TIME_AGE (§28.1),
   antes de usar red o secretos:
       exactamente un stanza;
       de tipo tlock.

6. SHOULD: localizar PAYLOAD_AGE mediante las longitudes del PRELUDE
   e inspeccionar únicamente su cabecera age (§28.1):
       exactamente un stanza;
       de tipo X25519.

7. Resolver/verificar localmente la condición temporal, incluida la
   cota de round_time de §15 (ERR_DATEKEY_INVALID).

8. SHOULD, cuando se haya realizado la inspección previa, comprobar los
   argumentos del stanza tlock, en este orden:
       exactamente dos argumentos tras el tipo
           → si no, ERR_POLICY_STRUCTURE_MISMATCH;
       el primero es la representación decimal canónica de
       DateKey.round: solo dígitos ASCII 0-9, sin signo y sin ceros a
       la izquierda
           → si no, ERR_ROUND_MISMATCH;
       el segundo es el chain_hash del Provider Profile pinneado en
       hexadecimal en minúsculas, 64 caracteres
           → si no, ERR_PROFILE_MISMATCH.
   Los argumentos se comparan como cadenas de bytes exactas: nunca se
   interpretan como números ni se normalizan mayúsculas o ceros.

9. Antes de pedir el release, y sin ninguna petición de red:
   a. Si access_policy = time_and_key y se ofrece una .dkk:
        primero la .dkk como objeto, con las capas de §69.1: su trama
        (§40) y su schema (§41), con los códigos de §57;
        access_type y access_material (claves 4 y 5)
        → ERR_ACCESS_INVALID; después sus extensiones críticas
        (clave 7), como en el paso 4;
        después, su vínculo con esta cápsula (§55.1): capsule_id
        (clave 3) distinto del de PUBLIC_HEADER → ERR_ACCESS_INVALID;
        capsule_digest (clave 6), si existe y la implementación lo
        comprueba, lo que es opcional (§43), distinto del SHA-256 del
        .dkc → ERR_ACCESS_INVALID.
   b. Si access_policy = time_and_key y no se ofrece ninguna
      credencial, .dkk o identity → ERR_ACCESS_REQUIRED, sin consultar
      el reloj.
   c. Si el instante actual es anterior al round_time de la DateKey
      → ERR_RELEASE_UNAVAILABLE, sin pedir el release.
   Con time_only, las credenciales ofrecidas no intervienen: no se
   validan ni se usan, y ningún error suyo se informa.
   Solo entonces, obtener el release. Una fuente que obtiene releases
   por red (relay, Release API o caché) MUST verificar cada respuesta
   con las reglas del paso 10 y descartar la que no las cumple. Si
   ninguna fuente entrega un release, por cualquier causa, incluida la
   de haber descartado todas sus respuestas
      → ERR_RELEASE_UNAVAILABLE.

10. Verificar el release localmente (§17, §51), en este orden:
       ronda del release distinta de DateKey.round
           → ERR_ROUND_MISMATCH, aunque su firma sea válida para esa
             otra ronda;
       firma que no es la codificación canónica (§12.2) de un punto
       del grupo de firmas del scheme —G1, 48 bytes, en Quicknet—, que
       es el punto en el infinito o que no verifica con la clave
       pública pinneada como firma de la ronda según el scheme de drand
           → ERR_RELEASE_INVALID.
    Estos códigos se informan para un release que el llamador
    suministra directamente, como en los vectores oficiales: el que
    llega por red sin cumplir estas reglas lo descarta su fuente en el
    paso 9.

11. Abrir OUTER_TIME_AGE.
    La identity tlock MUST recibir y validar el conjunto completo de stanzas
    y MUST rechazar el fichero salvo que contenga exactamente un stanza tlock
    (→ ERR_POLICY_STRUCTURE_MISMATCH).
    La ronda y el chain hash MUST coincidir con la DateKey y con el
    Provider Profile pinneado, con las reglas y los códigos del paso 8.
    El cuerpo del stanza tlock es el ciphertext IBE-CCA con el que tlock
    (drand/tlock, §77) envuelve la file key para la ronda:
        U || V || W
    con |U| el tamaño de punto del grupo de claves del scheme —96 bytes,
    G2, en Quicknet; 48, G1, en pedersen-bls-unchained— y
    |V| = |W| = 16: 128 bytes en Quicknet. U MUST ser la codificación
    canónica (§12.2) de un punto de ese grupo distinto del punto en el
    infinito. El descifrado es el de tlock con la firma verificada en el
    paso 10; en Quicknet, con e el pairing de G1 × G2:
        sigma   = V XOR H2(e(firma, U))
        FK_TIME = W XOR H4(sigma)
        r       = H3(sigma, FK_TIME)
    y MUST comprobar r·G == U, con G el generador del grupo de U. H2, H3
    y H4 son las del paquete encrypt/ibe de drand/kyber, que tlock
    importa (§77), sobre SHA-256 con las etiquetas IBE-H2, IBE-H3 e
    IBE-H4. H2 resume el elemento de GT serializado como fija
    «Serialización de GT en H2», tras este flujo.
    Un cuerpo de otra longitud, un U que no cumple §12.2 o que es el
    punto en el infinito, una comprobación r·G == U que falla o una
    file key que no mide 16 bytes → ERR_INTEGRITY.
    La apertura autentica además la cabecera age mediante su MAC.

12. Verificar que la estructura resultante coincide con access_policy
    (§36). En los formatos 2 y 3 con time_and_key, la cabecera de
    INNER_ACCESS_AGE MUST tener exactamente 16 stanzas (§39)
       → si no, ERR_POLICY_STRUCTURE_MISMATCH.

13. Si time_and_key:
       la identity X25519 que abre INNER_ACCESS_AGE MUST recibir y validar
       el conjunto completo de stanzas;
       MUST existir uno o más stanzas en formato 1, y exactamente 16
       en los formatos 2 y 3;
       todos MUST ser X25519;
       debe existir exactamente un stanza por recipient;
       después, abrir INNER_ACCESS_AGE con la identity adecuada.
    Se prueba cada identity ofrecida con cada stanza, y los códigos van
    en este orden:
       las reglas de stanzas del paso 12
           → ERR_POLICY_STRUCTURE_MISMATCH;
       un stanza X25519 mal formado según la especificación age, que
       exige un único argumento tras el tipo, el share efímero en
       Base64 sin padding, de 32 bytes y que no es de orden bajo, y un
       cuerpo de 32 bytes
           → ERR_INTEGRITY;
       alguna identity desenvuelve más de un stanza, aunque otra
       desenvuelva exactamente uno
           → ERR_POLICY_STRUCTURE_MISMATCH;
       ninguna identity desenvuelve ningún stanza
           → ERR_ACCESS_INVALID;
       el MAC de la cabecera, STREAM, truncado o datos tras el final
           → ERR_INTEGRITY.

14. Parsear CONTROL_CBOR canónico, con las capas de §69.1. En la
    capa 2, su versión de schema (clave 1) MUST ser la que §22 asigna
    al formato de la cápsula, el VERSION del paso 2 (§31)
       → si no, ERR_UNSUPPORTED_VERSION.
    En la capa 3, las reglas de las claves 6 y 7 (§31): presentes en
    las versiones 2 y 3 y ausentes en la 1, L de 8 bytes y como mucho
    2⁵³ − 2⁴⁶, código 1 o 2
       → si no, ERR_NON_CANONICAL_CBOR.
    Validar sus extensiones críticas (clave 4) como en el paso 4.

15. Verificar header_binding (§26)
       → ERR_HEADER_BINDING.
    Desde aquí la data de las extensiones de PUBLIC_HEADER queda
    vinculada al control abierto: coherencia interna (§36.1), no
    autoría, salvo que la cubra una extensión de firma (§72).

16. Recuperar I_PAYLOAD. En los formatos 2 y 3, recuperar también L y el código
    de relleno (claves 6 y 7) y calcular P = regla(L) (§29.1). Este
    paso no falla: el paso 14 ya validó las dos claves. L y P no
    son longitudes de trama: no se reserva memoria ni disco según
    ellas (§57).

17. Abrir PAYLOAD_AGE usando I_PAYLOAD.
    La identity de payload MUST recibir y validar el conjunto completo de
    stanzas y MUST rechazar el fichero salvo que contenga exactamente un
    stanza X25519 (→ ERR_POLICY_STRUCTURE_MISMATCH) para R_PAYLOAD.
    Un stanza mal formado o que I_PAYLOAD no desenvuelve, porque no es
    para R_PAYLOAD (§30.1), el MAC de la cabecera, STREAM, truncado o
    datos tras el final → ERR_INTEGRITY.
    En los formatos 2 y 3, además (§29.1):
       el plaintext MUST medir exactamente P bytes;
       sus bytes L a P − 1 MUST valer 0x00;
           → si no, ERR_INTEGRITY.
    Un lector en streaming conoce P antes de descifrar el primer byte
    (paso 16): MAY fallar en cuanto el plaintext supera P bytes o, en
    formato 2, aparece un byte de relleno distinto de 0x00; un
    plaintext de menos de P bytes se detecta al final del STREAM. Un
    lector que conoce la longitud de PAYLOAD_AGE MAY comprobar, tras las
    reglas de stanzas,
    que es 184 + P + 16·max(1, ⌈P / 65536⌉) (§62.1). Todos estos
    fallos tienen el mismo código, así que el momento en que se
    detectan no lo cambia.
    En formato 3, los L primeros bytes del plaintext son BODY
    (§29.2), y el paso se divide en estos subpasos, en este orden:
       17.1  descifrar PAYLOAD_AGE hasta EOF, con las comprobaciones
             de arriba salvo la del relleno, que es 17.8;
       17.2  la trama del contenido y el área (§29.2)
                → ERR_INTEGRITY;
       17.3  SECURITY_CBOR, capas 2 y 3 (§29.3), sin código;
       17.4  HEAD_CBOR, capas 2 a 4 (§29.4 a §29.6)
                → ERR_UNSUPPORTED_VERSION, ERR_NON_CANONICAL_CBOR,
                  ERR_HEAD_INVALID o los de sus extensiones críticas;
       17.5  el end del último fichero es C, o C es 0 sin ficheros
                → si no, ERR_INTEGRITY;
       17.6  los veredictos de security (§29.7), sin código;
       17.7  el SHA-256 de cada fichero (§29.4) → ERR_INTEGRITY;
       17.8  el relleno, como arriba → ERR_INTEGRITY.
    Precedencia en formato 3: un fallo de age después de su cabecera
    —MAC, STREAM, truncado o datos tras el final— o un plaintext de
    longitud distinta de P es ERR_INTEGRITY y prevalece sobre todo lo
    demás. Si no hay ninguno, decide el primer subpaso que falla de
    17.2, 17.4, 17.5, 17.7 y 17.8, y dentro de él la primera capa
    (§69.1); 17.3 y 17.6 nunca fallan: solo fijan los veredictos
    (§29.3). Tras un fallo, el lector deja de entregar ficheros y
    sigue leyendo PAYLOAD_AGE hasta EOF. Solo MAY detenerse antes con
    ERR_INTEGRITY, y solo cuando ese ya es el código final: por un
    fallo de age o de la longitud del plaintext, o por un subpaso de
    ERR_INTEGRITY sin un fallo anterior de otro código. Cualquier otro
    código del paso 17 MUST informarse solo después de leer
    PAYLOAD_AGE hasta EOF, sin ningún fallo de age y con un plaintext
    de exactamente P bytes.

18. Commit del resultado solo si el paso 17 termina sin error, con
    todas sus comprobaciones:
       formato 1 → el plaintext completo de PAYLOAD_AGE;
       formato 2 → sus L primeros bytes, el contenido. El relleno
       nunca se entrega (§56).
       formato 3 → los ficheros, cada uno con su ruta, y el
       comentario, el autor declarado y los veredictos (§29.7);
       nunca la trama, el área ni el relleno (§56).

La inspección de los pasos 5, 6 y 8 es un SHOULD de fail-fast; la lectura de SEALED_CONTROL en el paso 5 es obligatoria (§23). La aplicación de las reglas de cardinalidad durante los pasos 11, 13 y 17 es un MUST. Una implementación no puede considerar válido un .dkc únicamente porque age haya podido desenvolver una file key: debe verificar también que el conjunto completo de stanzas cumple la política DateKeys V1 y, en los formatos 2 y 3, que INNER_ACCESS_AGE tiene 16 stanzas y que el plaintext de PAYLOAD_AGE tiene la longitud y el relleno de su L (§29.1); en formato 3, también la trama, el head y el SHA-256 de cada fichero (§29.2, §29.4).

Precedencia: el código que se informa es el del primer paso que falla y, dentro de un objeto, el de la primera capa que falla (§69.1). Una implementación que omite la inspección de los pasos 5, 6 u 8 detecta los mismos fallos, con el mismo código, en los pasos 11 y 17, salvo que antes falle otro paso; §69.1 delimita lo que eso cambia, y los vectores oficiales suponen que esa inspección se realiza.

La .dkk es una entrada distinta del .dkc. Una implementación MAY decodificarla al recibirla, antes del paso 1, pero MUST informar de cualquier error suyo —de trama, de schema o de sus campos— solo en el paso 9.a, en el orden de ese paso, y nunca si access_policy es time_only.

PAYLOAD_AGE comienza exactamente en:

16 + PUBLIC_HEADER_LEN + SEALED_CONTROL_LEN

Una implementación MAY saltar directamente a ese offset y leer solo la cabecera age necesaria para la inspección previa. No es necesario leer ni descifrar el payload completo y esta comprobación no rompe el procesamiento en streaming.

Siempre que sea viable, una implementación SHOULD validar todo lo verificable localmente antes de realizar una petición de red o utilizar un secreto. Además de fallar antes, esta regla evita que cápsulas inválidas generen consultas observables en relays o en la Release API.

Serialización de GT en H2. H2, del paso 11, es SHA-256 de la etiqueta IBE-H2 seguida de los 576 bytes del elemento de GT, truncado a los 16 bytes de V. Esos bytes MUST ser la serialización de kilic/bls12-381, la que usa drand/kyber (§77), sobre la torre Fp2 = Fp[u]/(u² + 1), Fp6 = Fp2[v]/(v³ − (u + 1)) y Fp12 = Fp6[w]/(w² − v): en cada nivel, los coeficientes de mayor a menor grado, y cada elemento de Fp, entre 0 y p − 1, en 48 bytes big-endian:

Fp12 = c0 + c1·w           →  c1 || c0          (288 bytes cada uno)
Fp6  = c0 + c1·v + c2·v²   →  c2 || c1 || c0    (96 bytes cada uno)
Fp2  = c0 + c1·u           →  c1 || c0          (48 bytes cada uno)

Es el orden de las coordenadas de G2 en §12.2, c1 antes que c0, en cada nivel de la torre. Una serialización que empieza por c0 en cada nivel, como Fp12.toBytes de noble, da otro H2 y otra file key. Vector (testdata/vectors/tlock_ibe.json): con G1 y G2 los generadores de sus grupos, H2(e(G1, G2)) = cb87319f24560b5231579a09ad79f12e; fija a la vez el pairing e y la serialización.

64. Mutation tests obligatorios

Las listas valen para los tres formatos: el corpus oficial las aplica a fixtures de formato 3 y conserva las de los formatos 1 y 2 como casos de compatibilidad (§70).

Antes de v1.0 deben fallar, como mínimo:

PUBLIC_HEADER_A + SEALED_CONTROL_B
SEALED_CONTROL_A + PAYLOAD_AGE_B
DateKey A + release de round B
chain hash cambiado
version cambiada a 4
flags != 0
reserved != 0
payload truncado
payload age modificado
control modificado
dk1_ JSON no canónico
perfil desconocido
release de otra ronda
access_policy=time_only con estructura time_and_key
access_policy=time_and_key con estructura time_only
stanza adicional en OUTER_TIME_AGE
stanza adicional en PAYLOAD_AGE
stanza de tipo distinto de X25519 en INNER_ACCESS_AGE
ronda del stanza tlock distinta de DateKey.round
chain hash del stanza tlock distinto del Provider Profile pinneado
data de extensión de tipo distinto de bstr
data de extensión vacía (h'')
65 extensiones en un mismo array

y, con el código y el paso de §63 en que fallan, las de la codificación canónica de puntos (§12.2):

U del stanza tlock con c0 + p                     ERR_INTEGRITY, paso 11
U del stanza tlock en el infinito                 ERR_INTEGRITY, paso 11
U con el bit de infinito y carga                  ERR_INTEGRITY, paso 11
cuerpo del stanza tlock de 127 bytes              ERR_INTEGRITY, paso 11
cuerpo del stanza tlock de 129 bytes              ERR_INTEGRITY, paso 11
firma del release con x + p                       ERR_RELEASE_INVALID, paso 10
firma del release en el infinito                  ERR_RELEASE_INVALID, paso 10
firma del release con el bit de infinito y carga  ERR_RELEASE_INVALID, paso 10
firma del release negada                          ERR_RELEASE_INVALID, paso 10
firma negada y U con c0 + p                       ERR_RELEASE_INVALID, paso 10

En las mutaciones de U y del cuerpo, la cabecera age de OUTER_TIME_AGE conserva un MAC válido, que el creador, o cualquiera una vez publicada la ronda, puede calcular: solo las reglas del paso 11 las rechazan. La firma con x + p necesita un release publicado cuya x cumpla x + p < 2³⁸¹. La firma negada es una codificación canónica que no verifica; junto a un U con c0 + p, fija que el paso 10 termina antes de que el paso 11 lea U.

y, con el código y el paso de §63 en que fallan, las del formato 2 (§22, §29.1, §31, §39), sobre fixtures de formato 2 salvo donde se indica:

VERSION 4                                          ERR_UNSUPPORTED_VERSION, paso 2
time_only con VERSION 3                            ERR_UNSUPPORTED_VERSION, paso 14
time_only de formato 1 con VERSION 2               ERR_UNSUPPORTED_VERSION, paso 14
time_and_key de formato 1, un stanza, con VERSION 2, y la identity
                                                   ERR_POLICY_STRUCTURE_MISMATCH, paso 12
time_only con VERSION 1                            ERR_UNSUPPORTED_VERSION, paso 14
time_and_key con VERSION 1 y la identity           ERR_UNSUPPORTED_VERSION, paso 14
INNER_ACCESS_AGE con 15 stanzas                    ERR_POLICY_STRUCTURE_MISMATCH, paso 12
INNER_ACCESS_AGE con 17 stanzas                    ERR_POLICY_STRUCTURE_MISMATCH, paso 12
16 stanzas, dos para un mismo recipient, y la identity de ese recipient
                                                   ERR_POLICY_STRUCTURE_MISMATCH, paso 13
identity que no es recipient de ninguno de los 16  ERR_ACCESS_INVALID, paso 13
CONTROL_CBOR de versión 2 sin la clave 6           ERR_NON_CANONICAL_CBOR, paso 14
CONTROL_CBOR de versión 2 sin la clave 7           ERR_NON_CANONICAL_CBOR, paso 14
código de relleno 0                                ERR_NON_CANONICAL_CBOR, paso 14
código de relleno 3                                ERR_NON_CANONICAL_CBOR, paso 14
L = 2⁵³ − 2⁴⁶ + 1                                  ERR_NON_CANONICAL_CBOR, paso 14
L de 7 bytes                                       ERR_NON_CANONICAL_CBOR, paso 14
L de 9 bytes                                       ERR_NON_CANONICAL_CBOR, paso 14
L como entero CBOR                                 ERR_NON_CANONICAL_CBOR, paso 14
último byte de relleno distinto de 0x00            ERR_INTEGRITY, paso 17
plaintext de P − 1 bytes                           ERR_INTEGRITY, paso 17
plaintext de P + 256 bytes                         ERR_INTEGRITY, paso 17
plaintext sin relleno, de L bytes                  ERR_INTEGRITY, paso 17
código 2 cambiado a 1, con L = 78000               ERR_INTEGRITY, paso 17
L − 1, con el último byte del contenido distinto de 0
                                                   ERR_INTEGRITY, paso 17

Las mutaciones de VERSION editan un byte de un fixture. Todas las de time_and_key ofrecen la identity, access_material en su forma AGE-SECRET-KEY-1…, y no la .dkk: cualquier cambio del .dkc rompe el capsule_digest de una .dkk que lo lleva, como las que escribe la implementación de referencia, y la mutación fallaría antes, en el paso 9.a, con ERR_ACCESS_INVALID (§43, §69.1). Las de INNER_ACCESS_AGE las construye quien conoce FK_ACCESS, como el creador. Las de CONTROL_CBOR sellan otro control, lo que en time_only puede hacer cualquiera (§36.1). Las que cambian la longitud de SEALED_CONTROL, también las de 15 y 17 stanzas, recalculan el PRELUDE y header_binding. Las del plaintext las construye quien conoce I_PAYLOAD. Todas conservan MAC válidos: solo las reglas de su paso las rechazan.

y, con el código y el paso de §63 en que fallan, las del formato 3 (§29.2 a §29.6), sobre fixtures de formato 3:

VERSION 4                                          ERR_UNSUPPORTED_VERSION, paso 2
time_only con VERSION 2                            ERR_UNSUPPORTED_VERSION, paso 14
AREA_LEN 0, 511, 513 o 66048                       ERR_INTEGRITY, paso 17
SECURITY_LEN 0, o mayor que AREA_LEN               ERR_INTEGRITY, paso 17
HEAD_LEN 0, o 2²⁴ + 1                              ERR_INTEGRITY, paso 17
12 + AREA_LEN + HEAD_LEN = L + 1                   ERR_INTEGRITY, paso 17
L < 12                                             ERR_INTEGRITY, paso 17
un byte distinto de 0x00 en el área                ERR_INTEGRITY, paso 17
head de versión 2                                  ERR_UNSUPPORTED_VERSION, paso 17
head con otro type tag                             ERR_NON_CANONICAL_CBOR, paso 17
head con un byte de más dentro de HEAD_LEN         ERR_NON_CANONICAL_CBOR, paso 17
rutas "b" y "a", en ese orden                      ERR_NON_CANONICAL_CBOR, paso 17
rutas "b/.." y "a", en ese orden                   ERR_NON_CANONICAL_CBOR, paso 17
ruta ".."                                          ERR_HEAD_INVALID, paso 17
ruta "/a"                                          ERR_HEAD_INVALID, paso 17
rutas "A.txt" y "a.txt"                            ERR_HEAD_INVALID, paso 17
rutas "ab" y "a", U+200C, "b"                      ERR_HEAD_INVALID, paso 17
ruta "CON.txt"                                     ERR_HEAD_INVALID, paso 17
ruta "CON.txt" en formas de ancho completo         ERR_HEAD_INVALID, paso 17
ruta "ABCDEF~1"                                    ERR_HEAD_INVALID, paso 17
ruta con U+202E                                    ERR_HEAD_INVALID, paso 17
ruta ".datekeys-x"                                 ERR_HEAD_INVALID, paso 17
comentario con U+202E                              ERR_HEAD_INVALID, paso 17
ruta de 1025 bytes                                 ERR_NON_CANONICAL_CBOR, paso 17
ruta "a."                                          ERR_HEAD_INVALID, paso 17
rutas "A" y "a/b"                                  ERR_HEAD_INVALID, paso 17
65 536 carpetas implícitas                         ERR_HEAD_INVALID, paso 17
autor declarado con LF                             ERR_HEAD_INVALID, paso 17
start de la primera entrada distinto de 0          ERR_HEAD_INVALID, paso 17
end − start distinto de size                       ERR_HEAD_INVALID, paso 17
ruta "a" seguida de VS16                           ERR_HEAD_INVALID, paso 17
ruta con dos ZWJ seguidos                          ERR_HEAD_INVALID, paso 17
comentario con la etiqueta U+E0041                 ERR_HEAD_INVALID, paso 17
comentario con el selector de variante VS17        ERR_HEAD_INVALID, paso 17
start de una entrada distinto del end de la anterior
                                                   ERR_HEAD_INVALID, paso 17
end del último fichero distinto de C               ERR_INTEGRITY, paso 17
un byte de un fichero cambiado                     ERR_INTEGRITY, paso 17
ruta ".." y un byte de relleno distinto de 0x00    ERR_HEAD_INVALID, paso 17
ruta ".." y el chunk siguiente de STREAM corrupto  ERR_INTEGRITY, paso 17
ruta ".." y corte exacto tras el chunk que la contiene
                                                   ERR_INTEGRITY, paso 17

Las mutaciones del formato 3 cambian el plaintext de PAYLOAD_AGE: las construye quien conoce I_PAYLOAD, sellan otro control cuando cambia L y conservan MAC válidos, salvo el chunk corrupto y el corte, que rompen STREAM. La forma de ancho completo de «CON.txt» falla por R6c. Tres casos más se abren, sin código, con su veredicto: security de versión 2 (X), una firma de alg 1 (F1) y un sello de seal_type 1 (S1).

65. Test vectors Quicknet

Deben incluir:

timestamp exactamente en frontera;
un segundo antes;
un segundo después;
timestamp con fracción de segundo inmediatamente posterior a una frontera de ronda;
fecha 2030-01-01;
fechas próximas al genesis.

Cada vector:

requested timestamp
expected round
effective timestamp

66. Test vectors `dk1_`

Cada vector:

logical object
exact canonical JSON bytes
exact Base64URL bytes
final dk1_ string

La cadena textual debe ser única.

67. Test vectors `.dkc`

Los vectores .dkc V1 son fixtures de descifrado y validación, no pruebas que exijan reproducir byte a byte una llamada pública a age.Encrypt.

La implementación de age genera internamente randomness que su API pública no permite inyectar de forma estable. El protocolo NO exige parchear age ni tlock para controlar:

file keys internas;
efímeros X25519;
nonces internos.

Cada vector oficial incluirá:

bytes .dkc fijos previamente generados;
PUBLIC_HEADER esperado;
PRELUDE esperado;
DateKey esperada;
header_binding esperado;
estructura esperada (time_only o time_and_key);
identity .dkk cuando corresponda;
CONTROL_CBOR esperado después de abrir;
I_PAYLOAD esperado;
plaintext final esperado;
resultado esperado de cada etapa de verificación;
el formato (1, 2 o 3);
en los formatos 2 y 3: L, el código de relleno y P esperados, y en time_and_key, los 16 stanzas de INNER_ACCESS_AGE, con el que abre cada credencial;
en formato 2, el plaintext final esperado son los L primeros bytes del plaintext de PAYLOAD_AGE;
en formato 3, el head y security esperados, cada fichero con su ruta, su tamaño, su SHA-256, su mtime y sus bytes, y los veredictos.

Qué stanza abre cada credencial es un dato de prueba: fuera de los vectores, un escritor no lo entrega (§39).

Los fixtures de la v0.8.2 se conservan como fixtures de compatibilidad de formato 1: un lector MUST abrirlos con la semántica de la v0.8.2 (§70). Los de la v0.9 se conservan como fixtures de compatibilidad de formato 2, con la semántica de la v0.9. Los de formato 2 cubren, como mínimo:

las dos políticas;
los dos códigos de relleno, con un mismo L ≥ 8193 para el que dan P distintas;
L = 0 (P = 256);
una credencial y 15 señuelos;
varias credenciales, entre ellas una clave portable;
16 credenciales, sin señuelos;
extensiones en PUBLIC_HEADER y en CONTROL_CBOR.

Son format2_time_only.dkc (código 2, L = 78 000, P = 79 872), format2_time_only_bloque256.dkc (el mismo contenido con el código 1, P = 78 080), format2_empty_payload.dkc, format2_time_only_extensions.dkc, format2_time_and_key_portable.dkc con su .dkk, format2_time_and_key_recipients.dkc con su .dkk (tres recipients y una clave portable) y format2_time_and_key_sixteen.dkc. Un relleno que ocupa varios chunks de STREAM (L = 5 000 000 con el código 2, P = 5 111 808) se prueba mejor con un test que genera la cápsula al ejecutarse que con un fixture de 5 MB.

Los de formato 3 cubren, como mínimo:

un solo fichero;
un árbol con carpetas;
un comentario sin ficheros;
los dos códigos de relleno;
time_and_key con clave portable;
un área de 1024 bytes, que el lector acepta;
security de versión 2, con el veredicto X;
una firma de alg 1 con una clave de 32 bytes y una firma de 64, aleatorias, con el veredicto F1;
esa firma y un sello de seal_type 1 con un token aleatorio, con F1 y S1.

Serán format3_single.dkc, format3_tree.dkc, format3_comment_only.dkc, format3_bloque256.dkc, format3_time_and_key_portable.dkc con su .dkk, format3_area_1024.dkc, format3_security_v2.dkc, format3_signature_unsupported.dkc y format3_seal_unsupported.dkc (por implementar). Los vectores de rutas y del head van en testdata/vectors/paths.json, head_schema.json y path_fold.json, y los de security, en security.json.

Los vectores de rutas y del head cubren, como mínimo: U+00A0 y U+3000 al principio y al final de un segmento, con el veredicto que dan las tablas, que para U+3000 es el rechazo por R6c; best-fit; alias 8.3, «~1» incluido; Cn; ["b/..", "a"]; U+206A a U+206F, las etiquetas y otros ignorables fuera de la lista blanca; «.» seguido de ZWJ y un segmento hecho solo de ZWJ; 127 veces «ΐ»; U+F03A; «.datekeys-x» en el primer nivel y en otro; el orden de U+FF5E y U+1F600; «ab» con y sin ZWNJ; «¿», «§» y «♥», que se aceptan; VS16 tras un emoji que lo admite, que se acepta, y tras «a», que no; ZWJ al principio, al final y dos seguidos; y la bandera arcoíris, que se acepta, y la de Escocia, que no. Los de head_schema.json cubren además un comentario con etiquetas y con selectores de variante sueltos. Los de security.json cubren: el mapa exterior con la clave 2 que no es una cadena de bytes, con una clave 4 o con un byte de más dentro de SECURITY_LEN (X); alg 0 o una clave vacía dentro de la clave 2 (F1, con el sello intacto); y un seal que incumple su schema con un seal_type desconocido (S2).

Los vectores de las reglas de relleno (§29.1) van en un fichero propio, testdata/vectors/padding.json, con L, código, P, la longitud de PAYLOAD_AGE, L_MAX y, como dato informativo, E, S y lastBits.

La conformidad se demuestra descifrando/verificando el fixture y comparando resultados intermedios y plaintext.

68. Test vectors `.dkk`

Los vectores .dkk son igualmente fixtures de parseo, validación y uso.

Cada vector incluirá:

bytes .dkk fijos;
credential_id esperado;
capsule_id esperado;
access_type esperado;
32 bytes crudos esperados de X25519 identity;
verification_metadata esperado cuando exista;
extensiones esperadas, con los bytes exactos de su data;
resultado esperado al utilizar la identity contra el INNER_ACCESS_AGE asociado.

Al menos un vector oficial .dkk MUST incluir una extensión con data.

Al menos un vector oficial .dkk MUST acompañar a una cápsula de formato 2, y otro, a una de formato 3. El formato de la .dkk no cambia (§40).

No se exige reproducir los bytes de una .dkk partiendo de una generación aleatoria nueva.

69. Errores normativos

ERR_INVALID_MAGIC
ERR_UNSUPPORTED_VERSION
ERR_INVALID_FLAGS
ERR_NON_CANONICAL_CBOR
ERR_UNKNOWN_PROFILE
ERR_PROFILE_MISMATCH
ERR_DATEKEY_INVALID
ERR_DATEKEY_NON_CANONICAL
ERR_ROUND_MISMATCH
ERR_RELEASE_UNAVAILABLE
ERR_RELEASE_INVALID
ERR_ACCESS_REQUIRED
ERR_ACCESS_INVALID
ERR_POLICY_STRUCTURE_MISMATCH
ERR_HEADER_BINDING
ERR_INTEGRITY
ERR_EXTENSION_CRITICAL_UNKNOWN
ERR_EXTENSION_DATA_INVALID
ERR_HEAD_INVALID

ERR_HEAD_INVALID es nuevo en la v0.10: un head de formato 3 bien codificado cuyos campos incumplen sus reglas (§29.4 a §29.6).

69.1 Precedencia de errores

Cuando unos bytes violan varias reglas, una implementación MUST informar del código de la primera capa que falla, de modo que el código no dependa de su estrategia interna de validación: validar el schema entero antes que los campos o al revés, detenerse en el primer error o recorrer todo el objeto. §57 dice qué código corresponde a cada regla; esta sección, cuál se informa cuando fallan varias.

Cada objeto —Provider Profile, PUBLIC_HEADER, CONTROL_CBOR, .dkk y, en formato 3, el head y SECURITY_CBOR— se valida en cuatro capas, en este orden. SECURITY_CBOR nunca da código: sus fallos solo cambian los veredictos (§29.3).

Trama. La del .dkc para PUBLIC_HEADER (§22, §23) y la de la .dkk para su cuerpo (§40): magic, prelude completo, versión de trama —el formato, 1, 2 o 3, en el .dkc (§23), y 1 en la .dkk (§40)—, FLAGS, RESERVED, longitudes y límites de §57, y la presencia de los bytes que declara cada longitud, en el orden de esas secciones: ERR_INVALID_MAGIC; un prelude truncado, ERR_INTEGRITY, antes que la versión; después ERR_UNSUPPORTED_VERSION, ERR_INVALID_FLAGS y ERR_INTEGRITY. Un objeto que supera el límite de su trama es ERR_INTEGRITY. El Provider Profile y CONTROL_CBOR no tienen trama propia; CONTROL_CBOR queda acotado por SEALED_CONTROL. En formato 3, la trama del head y de SECURITY_CBOR es la del contenido (§29.2): sus tres longitudes y sus rangos, que quepan en L y los ceros del área, con ERR_INTEGRITY en el paso 17.
Tipo y versión de schema, leídos antes que nada de las claves 0 y 1 (§70). El objeto MUST empezar, con cada cabecera en su forma más corta y dentro del perfil de §58, por: una cabecera de mapa de longitud definida que anuncia al menos dos entradas y no más de la mitad de los bytes que la siguen, porque cada entrada ocupa al menos dos; la clave 0; una cadena de texto, el type tag; la clave 1; y un entero sin signo de como mucho 2⁵³ − 1, la versión. Cualquier otra cosa ahí, incluida una versión de 2⁵³ o más, es ERR_NON_CANONICAL_CBOR. Después, un type tag distinto del propio del schema es ERR_NON_CANONICAL_CBOR, sea cual sea la versión. Solo entonces una versión que el objeto no admite es ERR_UNSUPPORTED_VERSION, sea lo que sea lo que la sigue: claves desconocidas, elementos fuera del perfil, truncado o bytes sobrantes. El Provider Profile, PUBLIC_HEADER, la .dkk, el head y SECURITY_CBOR admiten la versión 1; CONTROL_CBOR, la que §22 asigna al formato de su cápsula (§31). Es la única regla de esta capa que depende de otro objeto.
Codificación y schema. El perfil de §58, la igualdad con la recodificación y toda regla normativa de datekeys.cddl para el objeto, incluidos tipos, tamaños, rangos, el máximo de 64 extensiones, el orden y la unicidad de extension_id (§54), en el head R1 y R8 (§29.5), en CONTROL_CBOR las reglas de las claves 6 y 7 —presentes en las versiones 2 y 3 y ausentes en la 1, L de 8 bytes y como mucho L_MAX, código 1 o 2 (§31)— y los límites de implementación que se apliquen con ese código (§74): ERR_NON_CANONICAL_CBOR. Quedan fuera las reglas a las que §57 asigna código propio —la sintaxis de compact_datekey, access_type, la longitud de access_material, los nombres y la clave pública del Provider Profile—: de ellas, esta capa solo comprueba el tipo CBOR del campo, y el resto pasa a la capa 4.
Campos semánticos con código propio (§57), cada uno ya con el tipo CBOR de su regla, en orden ascendente de clave:
- Provider Profile: los campos del punto 2 de §12.1 → ERR_UNKNOWN_PROFILE; después, porque relaciona varias claves, la autocomprobación de chain_hash → ERR_PROFILE_MISMATCH;
- PUBLIC_HEADER, en el paso 4 de §63: la DateKey de la clave 3 (§19) → ERR_DATEKEY_INVALID o ERR_DATEKEY_NON_CANONICAL, y su perfil pinneado → ERR_UNKNOWN_PROFILE; después, las extensiones críticas de la clave 5;
- CONTROL_CBOR, en el paso 14: las extensiones críticas de la clave 4;
- .dkk, en el paso 9.a: access_type y access_material, claves 4 y 5 → ERR_ACCESS_INVALID; después, las extensiones críticas de la clave 7;
- el head, en el paso 17: el comentario y el autor declarado, claves 3 y 4 (§29.6), y los ficheros de la clave 5, con las reglas y el orden de §29.5 → ERR_HEAD_INVALID; después, las extensiones críticas de la clave 6.
En un array de extensiones críticas, primero cualquier extensión desconocida, también una conocida que no está registrada para ese objeto y ese array → ERR_EXTENSION_CRITICAL_UNKNOWN; solo si todas son conocidas, una con data inválida → ERR_EXTENSION_DATA_INVALID (§54). En esta capa, las extensiones no críticas nunca producen error.

Entre objetos y entre pasos decide el orden de §63: el primer paso que falla determina el código. Las comprobaciones que relacionan un objeto con otro, o con el perfil resuelto, pertenecen a su paso y no a la capa 4 del objeto: la cota de round_time (paso 7, §15), los argumentos del stanza tlock (paso 8), el vínculo de una .dkk con su .dkc (paso 9.a), la estructura frente a access_policy y, en los formatos 2 y 3, los 16 stanzas de INNER_ACCESS_AGE (paso 12), la versión de CONTROL_CBOR frente al formato (paso 14, en su capa 2), header_binding (paso 15), y la longitud y el relleno del plaintext de PAYLOAD_AGE frente a L y el código (paso 17), y en formato 3, el end del último fichero frente a C y el SHA-256 de cada fichero (paso 17). En formato 3, dentro del paso 17 decide el orden de sus subpasos: un fallo de age o de la longitud del plaintext prevalece, y si no lo hay, decide el primer subpaso que falla (§63). La presencia de los bytes de SEALED_CONTROL se comprueba en el paso 5, después de validar PUBLIC_HEADER en el paso 4.

Alcance. La garantía vale para un mismo conjunto de comprobaciones. §63 deja opcionales la inspección previa de los pasos 5, 6 y 8 (SHOULD) y la comprobación de capsule_digest en el paso 9.a (§43). Una implementación que omite alguna detecta esos fallos más tarde, o no los detecta, y puede informar antes el código de otro paso; los vectores oficiales y los ejemplos de abajo suponen que se realizan todas. La lectura de SEALED_CONTROL en el paso 5 no es opcional: si faltan sus bytes, el código es ERR_INTEGRITY en ese paso (§23). Los códigos del paso 10 son los de un release que el llamador suministra directamente, como en los vectores oficiales: una fuente que obtiene releases por red descarta el que no cumple las reglas del paso 10, y si ninguna entrega uno que las cumpla el código es ERR_RELEASE_UNAVAILABLE, en el paso 9 (§63). Ninguna otra elección de la implementación puede cambiar el código: ni el orden de sus comprobaciones dentro de una capa, ni decodificar la .dkk antes del paso 1 (§63), ni el orden en que prueba las identities del paso 13, ni el momento en que un lector en streaming detecta un fallo del paso 17, ni la comprobación opcional de la longitud de PAYLOAD_AGE en ese paso, que tiene el mismo código. En formato 3, eso exige que un lector solo se detenga antes de EOF con ERR_INTEGRITY, y solo cuando ese ya es el código final (§63, paso 17).

Ejemplos, reproducibles con los vectores oficiales o con los tests de la implementación de referencia (§76):

Entrada	Código
Type tag de otro schema y versión 2	`ERR_NON_CANONICAL_CBOR`
Versión 2, una clave desconocida y una DateKey inválida	`ERR_UNSUPPORTED_VERSION`
`access_policy` 2 y la DateKey `dk1_x`	`ERR_NON_CANONICAL_CBOR`
DateKey `dk1_x` y una extensión crítica desconocida	`ERR_DATEKEY_INVALID`
Extensión crítica con `data` inválida seguida, en el array, de otra desconocida	`ERR_EXTENSION_CRITICAL_UNKNOWN`
Extensión crítica con `data` inválida seguida, en el array, de una conocida registrada solo como no crítica	`ERR_EXTENSION_CRITICAL_UNKNOWN`
Provider Profile con un `provider` inválido y un `chain_hash` que no corresponde	`ERR_UNKNOWN_PROFILE`
`.dkk` de otra cápsula con una extensión crítica desconocida	`ERR_EXTENSION_CRITICAL_UNKNOWN`, paso 9
Cápsula `time_and_key` con `FLAGS` 1 y una `.dkk` sin magic `DKK1`	`ERR_INVALID_FLAGS`, paso 2
Cápsula `time_only` válida y una `.dkk` sin magic `DKK1`	se abre: la `.dkk` no interviene
Cápsula `time_and_key` sin credenciales y con el reloj antes de `round_time`	`ERR_ACCESS_REQUIRED`, paso 9
Release de otra ronda con una firma válida para esa ronda, suministrado directamente	`ERR_ROUND_MISMATCH`, paso 10
El mismo release, única respuesta de un relay	`ERR_RELEASE_UNAVAILABLE`, paso 9
Firma del release negada y U del stanza tlock con c0 + p	`ERR_RELEASE_INVALID`, paso 10
Dos identities: una desenvuelve un stanza de `INNER_ACCESS_AGE` y la otra dos	`ERR_POLICY_STRUCTURE_MISMATCH`, paso 13
`CONTROL_CBOR` con una extensión crítica desconocida y el `header_binding` de otra cabecera	`ERR_EXTENSION_CRITICAL_UNKNOWN`, paso 14
Ronda fuera del perfil y cabecera de `PAYLOAD_AGE` mal formada	`ERR_INTEGRITY`, paso 6
Cápsula de formato 2 con 15 stanzas en `INNER_ACCESS_AGE` y una identity que abre uno	`ERR_POLICY_STRUCTURE_MISMATCH`, paso 12
`CONTROL_CBOR` de versión 1 en una cápsula de formato 2, con una clave desconocida	`ERR_UNSUPPORTED_VERSION`, paso 14
Código de relleno 3 y una extensión crítica desconocida en `CONTROL_CBOR`	`ERR_NON_CANONICAL_CBOR`, paso 14
Código de relleno 3 y el `header_binding` de otra cabecera	`ERR_NON_CANONICAL_CBOR`, paso 14
Extensión crítica desconocida en `CONTROL_CBOR` y un byte de relleno distinto de 0x00	`ERR_EXTENSION_CRITICAL_UNKNOWN`, paso 14
Byte de relleno distinto de 0x00 y un stanza adicional en `PAYLOAD_AGE`	`ERR_POLICY_STRUCTURE_MISMATCH`, paso 6
Cápsula `time_and_key` de formato 1 con `VERSION` 2 y su `.dkk`, con `capsule_digest`	`ERR_ACCESS_INVALID`, paso 9
`CONTROL_CBOR` de versión 2 en una cápsula de formato 3	`ERR_UNSUPPORTED_VERSION`, paso 14
Cápsula de formato 3 con una ruta «..» y el chunk siguiente de `PAYLOAD_AGE` corrupto	`ERR_INTEGRITY`, paso 17
Una ruta «..» y el fichero cortado justo después del chunk completo que la contiene	`ERR_INTEGRITY`, paso 17
Una ruta «..» y un byte de relleno distinto de 0x00	`ERR_HEAD_INVALID`, paso 17
Una ruta «..» y un fichero con otro SHA-256	`ERR_HEAD_INVALID`, paso 17
Rutas «b/..» y «a», en ese orden	`ERR_NON_CANONICAL_CBOR`, paso 17
Head de versión 2 con una ruta «..»	`ERR_UNSUPPORTED_VERSION`, paso 17
`AREA_LEN` 513 y un head de versión 2	`ERR_INTEGRITY`, paso 17
`security` ilegible y una ruta «..»	`ERR_HEAD_INVALID`, paso 17
`security` ilegible y todo lo demás válido	se abre, con el veredicto X

70. Compatibilidad

Una implementación V1:

MUST aceptar DKC1 con VERSION 1, 2 o 3, y DKK1 con VERSION 1;
MUST rechazar cualquier otra versión de trama (§23, §40) y toda versión de schema que el objeto no admita (§69.1), salvo la de SECURITY_CBOR, que solo da el veredicto X (§29.3);
MUST abrir todo objeto válido de formato 1 con la semántica de la v0.8.2: uno o más stanzas en INNER_ACCESS_AGE y el plaintext completo de PAYLOAD_AGE, sin relleno;
MUST abrir todo objeto válido de formato 2 con la semántica de la v0.9: 16 stanzas en INNER_ACCESS_AGE y, como contenido, los L primeros bytes del plaintext de PAYLOAD_AGE, sin nombre ni metadatos;
MUST abrir todo objeto válido de formato 3 (§29.2 a §29.7, §56). Una interfaz que solo sabe entregar un flujo de bytes y recibe una cápsula de formato 3 MUST terminar tras el paso 2, sin red, con un error del llamador sin código de §69, y MUST NOT informarlo como ERR_UNSUPPORTED_VERSION: la cápsula es válida;
si escribe cápsulas, MUST escribir el formato 3 y MUST NOT escribir los formatos 1 ni 2 (§62.1); solo un generador de vectores de prueba MAY escribirlos;
SHOULD indicar al llamador el formato de una cápsula abierta o inspeccionada: el formato 1 no oculta el número de credenciales ni la longitud exacta del contenido (§55.2);
MUST rechazar critical extensions desconocidas;
MAY ignorar noncritical extensions desconocidas;
MUST mantener inmutable la interpretación de perfiles publicados.

Un lector que solo conoce el formato 1, como los de la v0.8.2, rechaza una cápsula de formato 2 en el paso 2, con ERR_UNSUPPORTED_VERSION y sin ninguna petición de red. Si alguien cambia su VERSION a 1 sin volver a sellar el control, falla en el paso 14, también con ERR_UNSUPPORTED_VERSION, porque su CONTROL_CBOR tiene la versión 2; en time_and_key con una .dkk que lleva capsule_digest, antes, en el paso 9.a, con ERR_ACCESS_INVALID, si se comprueba (§43). Una cápsula de formato 2 cuyo control no se ha vuelto a sellar nunca entrega el contenido con su relleno ni lo corta.

Del mismo modo, un lector de la v0.9 rechaza una cápsula de formato 3 en el paso 2, sin red. Cambiar la VERSION de una cápsula entre 2 y 3 sin volver a sellar su control falla en el paso 14, con ERR_UNSUPPORTED_VERSION, o antes, en el paso 9.a, con una .dkk que lleva capsule_digest. Una cápsula de formato 3 cuyo control no se ha vuelto a sellar nunca entrega su BODY como si fuera un contenido de formato 2.

Las versiones que definan la firma de autor y el sello de tiempo no cambiarán la trama del contenido, el head ni el mapa exterior de security: añadirán valores de alg y de seal_type con sus veredictos, y quizá un área mayor, que todo lector de esta versión acepta (§29.2, §29.3). Un lector de esta versión muestra lo nuevo como no soportado y abre la cápsula.

VERSION no está autenticado hasta los pasos 14 y 15: lo que impide el downgrade es la versión de CONTROL_CBOR, que autentican los MAC de age frente a quien no conoce la file key, y header_binding. Quien conoce I_PAYLOAD y puede sellar un control —cualquiera tras la fecha en time_only (§36.1), quien tiene una credencial en time_and_key— puede construir una cápsula de formato 1 con el mismo PAYLOAD_AGE, que todo lector abre como el contenido seguido de ceros, o, con el de una cápsula de formato 3, una de formato 2 que entrega BODY entero como contenido. Es una reescritura (§55.1), no un downgrade: esa misma persona ya puede cifrar cualquier otro plaintext para R_PAYLOAD.

71. Registro de perfiles

DateKeys SHOULD publicar un registro de Provider Profiles.

Cada entrada debería incluir:

exact canonical CBOR;
SHA-256;
firma offline;
fecha de publicación;
estado.

72. Registro de extensiones

DateKeys MAY publicar un registro de extension_id.

Registrar una extensión no cambia el núcleo del protocolo.

Cada extensión registrada, identificada por (extension_id, extension_version), MUST declarar:

la codificación de su data, o que no lleva data;
su forma canónica;
su longitud máxima, que no puede superar la trama del objeto que la contiene (§57);
los objetos (PUBLIC_HEADER, CONTROL_CBOR, .dkk o el head de formato 3) y el array (crítico, no crítico o ambos) en que puede aparecer; en otro objeto o array se trata como desconocida (§54);
sus vectores de prueba.

Una extensión registrada en CONTROL_CBOR vale en todas sus versiones de schema (§31).

Un encoder MUST NOT escribir una extensión registrada en un objeto o array para el que no está registrada: allí un lector la trata como desconocida (§54).

Si la codificación de data es CBOR:

MUST usar el perfil de §58 de forma recursiva, con enteros sin signo de como mucho 2⁵³ − 1, arrays y mapas no vacíos y sin null;
los lectores que implementan la extensión MUST rechazar una codificación interna no canónica o fuera de ese perfil como data inválida (§54);
su encoder MUST decodificar su propia salida, con las reglas de esos lectores, antes de sellar o escribir el objeto.

Una extensión de firma que cubra la data de otras extensiones MUST firmar los bytes exactos del contenido de esos bstr, nunca una reserialización de su contenido decodificado.

Ubicación según el modelo de confianza (§55.1):

una extensión que lleva afirmaciones relevantes para la seguridad —aquellas de las que depende una decisión de seguridad de quien abre la cápsula: autorización, identidad, integridad o fecha— MUST registrarse en CONTROL_CBOR o estar firmada por una extensión de firma; ni siquiera en CONTROL_CBOR prueba autoría (§36.1);
sin una extensión de firma que la cubra, la data de las extensiones de una .dkk es solo informativa para quien la posee: una implementación MUST NOT basar en ella una decisión de seguridad sobre la cápsula.

Nota: la data de PUBLIC_HEADER es pública. El protocolo base no la vincula al control hasta que se verifica header_binding (§63, paso 15), y esa verificación aporta coherencia interna, no autoría: solo una extensión de firma puede aportar autenticidad del creador (§36.1, §55.1). La de .dkk viaja en claro y header_binding no la cubre, así que el protocolo base no la autentica en ningún paso.

73. Decisiones canónicas v0.10

DateKeys
= plataforma / protocolo

DateKey
= condición temporal pública

DateKeyCap
= .dkc

DateKeys Access Key
= .dkk

Quicknet
= provider V1

dk1_
= JSON canónico heredado del prototipo

Provider Profile
= Deterministic CBOR + genesis_seed

capsule_id
= 16 bytes aleatorios y opacos

DKC framing
= sin PAYLOAD_LEN; VERSION es el formato de la cápsula: 1 (v0.8.2),
  2 (v0.9) o 3 (v0.10); se escribe solo el 3

PUBLIC_HEADER
= Deterministic CBOR exacto

profile_id duplicado en header
= eliminado; la DateKey es la fuente única

header binding
= SHA-256(PRELUDE || exact PUBLIC_HEADER bytes)

payload
= fichero age v1 estándar completo; en los formatos 2 y 3, su plaintext
  es el contenido seguido de ceros hasta P = regla(L); en formato 3, el
  contenido es BODY

payload access
= X25519 identity I_PAYLOAD dentro de CONTROL_CBOR, nueva de un CSPRNG
  para cada cápsula

time_only
= age(tlock → CONTROL_CBOR)

time_and_key
= age(tlock → age(X25519 recipient(s) → CONTROL_CBOR)); en los formatos 2
  y 3, exactamente 16 recipients: de 1 a 16 credenciales y señuelos, en
  orden uniformemente aleatorio

portable .dkk
= X25519 identity de 32 bytes crudos

extensions
= único mecanismo genérico de extensibilidad en PUBLIC_HEADER, CONTROL_CBOR,
  .dkk y el head de formato 3

extension arrays
= 1 a 64 extensiones en orden estrictamente ascendente de los bytes
  UTF-8 de extension_id; extension_id único en cada objeto

extension data
= bstr no vacío y opaco; el protocolo base nunca lo decodifica

CBOR profile
= RFC 8949 §4.2.1 con tipos mayores 0, 2, 3, 4 y 5 y claves enteras sin signo

parser limits
= MUST para encoders y decoders; ninguna trama vacía

error precedence
= primera capa que falla en cada objeto (trama, tipo y versión,
  schema, campos); entre objetos, el orden de pasos de §63; los
  errores de una .dkk, solo en el paso 9.a; en formato 3, dentro del
  paso 17, prevalece un fallo de age y después decide el primer
  subpaso

trust model
= §55.1; autoría solo mediante una extensión de firma

BLS12-381 points
= una sola codificación válida, la comprimida canónica de drand
  (§12.2); clave pública, firma y U distintos del infinito

tlock stanza body
= U || V || W, 128 bytes en Quicknet (§63 paso 11)

GT en H2
= orden de kilic/kyber: Fp12 c1 || c0, Fp6 c2 || c1 || c0,
  Fp2 c1 || c0, cada Fp en 48 bytes big-endian (§63 paso 11)

release sources
= una fuente de red verifica cada respuesta; sin release, por
  cualquier causa, ERR_RELEASE_UNAVAILABLE en el paso 9 y ningún
  otro código; los códigos del paso 10, para un release
  suministrado directamente

extension placement
= un encoder no escribe una extensión fuera de los objetos y
  arrays de su registro, y un lector la trata allí como
  desconocida (§54, §72)

payload padding
= códigos 1 (bloque256) y 2 (reforzado, con Padmé), sin opción sin
  relleno; L y el código en las claves 6 y 7 de CONTROL_CBOR versiones 2 y 3,
  L en 8 bytes y como mucho 2^53 − 2^46; comprobado en el paso 17
  (ERR_INTEGRITY); el SDK usa el 2 por defecto

capsule formats
= VERSION 1, 2 o 3; la versión de schema de CONTROL_CBOR es la del
  formato; PUBLIC_HEADER y .dkk, versión 1 en los tres; un lector v0.10
  abre los formatos 1 y 2 con la semántica de sus versiones; un lector
  v0.9 rechaza el formato 3 en el paso 2, sin red

privacy
= §55.2: visibles la fecha, access_policy, capsule_id y P; ocultos L,
  el número de credenciales, los recipients y, en formato 3, las rutas,
  los tamaños, los hashes y las fechas de los ficheros

writer rules
= §62.1: MUST para formato, credenciales, señuelos, aleatoriedad, L,
  SEALED_CONTROL_LEN y errores, y en formato 3, para el área, el head,
  las rutas, el texto, la mtime, la autodecodificación y los ficheros;
  SHOULD para autocomprobación y borrado

content format 3
= BODY: AREA_LEN, SECURITY_LEN y HEAD_LEN en 12 bytes; security en un
  área de tamaño fijo por versión del spec, 512 bytes en la v0.10; el
  head; los ficheros concatenados

head
= versión 1 siempre en formato 3; sal de 32 bytes; comentario y autor
  declarado opcionales; por fichero, ruta, size, start, end, SHA-256 y
  mtime opcional; hasta 65 535 ficheros y 16 MiB; ERR_HEAD_INVALID

paths
= R1 a R10 y R4b, con tablas propias de Unicode 18.0.0 y WindowsBestFit;
  orden por bytes UTF-8; ningún invisible en el texto del creador salvo
  ZWJ, ZWNJ, VS15 y VS16 donde su uso es conforme

security
= mapa de versión 1 con la firma y el sello codificados aparte; nunca
  decide la apertura; en la v0.10, vacío al escribir y sin ningún alg
  ni seal_type; veredictos X, F0, F1, S0, S1 y S2

recovery
= puede obtener release directamente del provider

historical release availability
= dependencia explícita del horizonte de recuperación

74. Aspectos todavía provisionales

Antes de v1.0 quedan por cerrar:

schema CBOR final byte-a-byte de PUBLIC_HEADER;
schema CBOR final byte-a-byte de CONTROL_CBOR;
schema CBOR final byte-a-byte de .dkk;
límites definitivos de campos;
vectores definitivos de Provider Profile;
suite exacta de tests interoperables.

El framing base, la ausencia de PAYLOAD_LEN, el uso de age files estándar, la identity X25519 cruda de .dkk y el formato de extensiones (§54) dejan de considerarse provisionales en este borrador. Tampoco lo son los formatos 1, 2 y 3 (§22), los 16 huecos de INNER_ACCESS_AGE (§39), las reglas de relleno 1 y 2 (§29.1), ni la trama del contenido, el head y las reglas de rutas y de texto del formato 3 (§29.2 a §29.6). El schema byte a byte de CONTROL_CBOR, claves 6 y 7 incluidas, sigue abierto como el de los demás objetos; su versión final conservará una codificación de L de longitud fija (§31, §55.2).

Mientras los límites definitivos de campos sigan abiertos, la implementación de referencia aplica los siguientes límites de implementación. No son normativos; se enumeran para que otra implementación pueda reproducir los vectores oficiales, que los aplican. Los cinco primeros son las reglas que datekeys.cddl marca como límites de implementación, y quien los aplica usa la correspondencia de errores de §57 y los comprueba en la capa de §69.1 que corresponde a ese código:

Límite de la implementación de referencia	Regla normativa	Código
`profile_id` de como mucho 128 bytes, también como `network` de `dk1_` (§19)	el alfabeto de §12.1, sin longitud máxima	`ERR_UNKNOWN_PROFILE` en el Provider Profile; `ERR_DATEKEY_INVALID` en `dk1_`
`provider`, `network` y `scheme` de como mucho 64 bytes	el alfabeto de §12.1, sin longitud máxima	`ERR_UNKNOWN_PROFILE`
`public_key` del Provider Profile de 1 a 1024 bytes	48 o 96 bytes según el scheme (§12.1)	`ERR_UNKNOWN_PROFILE`
`period` del Provider Profile de 1 a 86400 segundos (un día)	de 1 a 2⁵³ − 1 en la codificación (§11), y como mucho 2³² − 1 para pinnear el perfil (§12.1)	`ERR_NON_CANONICAL_CBOR`
`extension_id` de como mucho 256 bytes	cadena de texto UTF-8 de al menos 1 byte (§31)	`ERR_NON_CANONICAL_CBOR`
cadena `dk1_` de como mucho 256 bytes	sin límite	`ERR_DATEKEY_INVALID`
cabecera `age` de como mucho 1024 stanzas, 128 argumentos tras el tipo de cada stanza y 2 MiB desde la línea de versión hasta la del MAC (los del parser de `filippo.io/age`)	sin límite (§28.1)	`ERR_INTEGRITY` en `OUTER_TIME_AGE` y `PAYLOAD_AGE`; `ERR_POLICY_STRUCTURE_MISMATCH` en el paso 12 en `INNER_ACCESS_AGE` (§28.1)

Una entrada que solo supera uno de estos límites no falla por esa causa en una implementación que no lo aplica; en los vectores de schema, los que dependen de un límite lo dicen en su nombre (testdata/README.md). Los alfabetos de los nombres, la longitud de la clave pública de cada scheme, la cota de period para pinnear y el mínimo de 1 byte de extension_id son normativos (§12.1, §31): no dependen de estos límites.

El máximo de 16 credenciales (§39), L_MAX (§29.1) y los límites del formato 3 (§29.2 a §29.6) no son límites de implementación: son normativos y no figuran en esta tabla.

Trabajo futuro

Quedan fuera de la v0.10, como trabajo futuro que esta versión no especifica:

el formato de un objeto de release y de su fuente de archivo;
una nueva redacción del modelo de amenazas del proveedor (§7.6);
una extensión de firma, y la firma de autor y el sello de tiempo del área security (§29.3), que definirán las versiones siguientes, con el documento «Servicio de sellado DateKeys v1»;
el uso del reloj local en el paso 9.c de §63;
un tipo de acceso post-cuántico.

75. Requisitos bloqueantes antes de v1.0

Schemas CBOR congelados.
profile_hash vector oficial.
Quicknet vectors oficiales.
dk1_ vectors canónicos.
fixtures oficiales .dkc de descifrado/validación, de formato 3 y de compatibilidad de los formatos 1 y 2.
fixtures oficiales .dkk de parseo/uso.
mutation tests completos, en los tres formatos.
strict tlock tests.
parser fuzzing.
revisión criptográfica externa.
vectores de las reglas de relleno (§29.1).
tablas de Unicode 18.0.0 y WindowsBestFit fijadas por su SHA-256 (§29.5.1), con sus vectores de rutas.

76. Política de cambios del borrador v0.8.1

La v0.8.1 congela el diseño normativo del borrador para la fase de implementación e interoperabilidad.

A partir de esta versión, un cambio normativo posterior SHOULD responder a un caso reproducible descubierto mediante al menos una de estas fuentes:

implementación de referencia;
schema datekeys.cddl;
fixture oficial;
mutation test;
prueba de interoperabilidad;
fuzzing;
segunda implementación independiente;
revisión criptográfica o técnica externa.

Nuevas ideas, preferencias editoriales o posibilidades futuras que no estén respaldadas por uno de esos casos SHOULD documentarse fuera del núcleo normativo hasta que exista evidencia suficiente para modificarlo.

Esta política no impide correcciones editoriales que no alteren la semántica normativa.

Cambios normativos de la v0.8.2

La v0.8.2 cierra el formato de las extensiones (§74) con este cambio normativo:

data (clave 2) pasa de any a bstr no vacío y opaco, sin más límite de longitud que la trama de su contenedor; el protocolo base nunca decodifica ni valida su contenido (§31, §54, §57, §58.1);
cada array admite como máximo 64 extensiones (§31, §54);
extension_version queda acotado a 2³² − 1, y period y genesis_time a 2⁵³ − 1 (§11, §54, §58);
se elimina la excepción de multiplicidad: un extension_id aparece una sola vez por objeto (§31, §54);
nuevo error ERR_EXTENSION_DATA_INVALID para una extensión crítica conocida con data inválida (§54, §63, §69);
los límites de §57 pasan de recomendación a MUST para encoders y decoders, con su correspondencia de errores;
§58 nombra el perfil CBOR del protocolo;
§72 fija las reglas de registro de extensiones;
nuevas mutaciones (§64) y un vector .dkk con extensión (§68).

Antes de publicarse lo completan los refinamientos, la enmienda y las correcciones de los bloques siguientes.

Casos reproducibles que lo justifican, obtenidos con la implementación de referencia, sus fixtures y datekeys.cddl de la v0.8.1:

El CDDL se contradecía: sus líneas 12 a 14 establecen que null y los valores vacíos nunca representan ausencia, y su línea 82 declaraba ? 2 => any.
extension.New(id, v, nil) emitía f6 (null) como data.
La misma cápsula de 810 bytes, con data de cabecera {NaN:0, NaN:1} (a2f97e0000f97e0001), se aceptaba de forma no determinista: Inspect la aceptó 437 veces de 500 y Open 82 de 100.
El fixture oficial time_only_extensions usaba claves de texto y true en data.
Encrypt sellaba una data de CONTROL_CBOR con 14 arrays anidados que Open rechazaba en el paso 14, ya desbloqueada (exceeded max nested level 16): la cápsula quedaba irrecuperable.
Sin máximo de extensiones, una PUBLIC_HEADER de 880 KB con 40 000 + 40 000 extensiones hacía que DecodeHeader tardara 8,3 s, por una comprobación de disjunción cuadrática.

Las versiones de framing y de schema (clave 1) no cambian. Un objeto v0.8.1 deja de ser válido si la data de una extensión no es un bstr no vacío, si un array supera 64 extensiones, si repite un extension_id al amparo de la antigua excepción de multiplicidad o si un extension_version supera 2³² − 1; también un Provider Profile con period o genesis_time por encima de 2⁵³ − 1. El fixture time_only_extensions se regenera.

Refinamientos de la v0.8.2

La v0.8.2 no se ha publicado todavía, así que estos refinamientos la modifican sin cambiar de versión. Ninguno cambia la codificación de un objeto válido ni el veredicto de un vector o fixture oficial existente: pasan a texto normativo reglas que solo estaban en la implementación de referencia o en testdata/README.md, y fijan el código cuando fallan varias reglas a la vez. dk1.json gana cuatro vectores, que fijan reglas de lectura de §19. Proceden de la implementación de referencia, de los vectores oficiales y de la revisión de una segunda implementación independiente, que encontró en testdata/README.md reglas que la especificación no fijaba.

Precedencia de errores por capas (§57, §63, §69.1). Casos: los vectores de cbor.json «type tag of PUBLIC_HEADER and schema version 2: the type tag is checked first» (ERR_NON_CANONICAL_CBOR) y «schema version 2 and an unknown key 11: the version is read first» (ERR_UNSUPPORTED_VERSION); una PUBLIC_HEADER con access_policy 2 y la DateKey dk1_x, que la implementación de referencia informaba como ERR_DATEKEY_INVALID con su antigua librería CBOR y como ERR_NON_CANONICAL_CBOR con su codec propio, sin que la especificación decidiera entre ambos; y una .dkk de otra cápsula con una extensión crítica desconocida, que el paso 9 de la referencia informaba como ERR_ACCESS_INVALID porque comprobaba capsule_id antes que la .dkk como objeto, y que ahora es ERR_EXTENSION_CRITICAL_UNKNOWN. Las reglas con código propio de §57 no pertenecen a la capa 3: un dk1_ con padding en PUBLIC_HEADER es ERR_DATEKEY_NON_CANONICAL, no ERR_NON_CANONICAL_CBOR, aunque rompa la expresión regular de compact-datekey. Las comprobaciones opcionales —la inspección de los pasos 5, 6 y 8, y la de capsule_digest— pueden cambiar el código: la referencia comprueba el digest solo con un .dkc que puede releer, y la mutación «capsule_digest of the .dkk does not match» supone que se comprueba. No eran lo único que podía cambiarlo: el código de un release inválido obtenido por red dependía también de si su fuente lo verificaba, hasta que lo fijaron las correcciones de la revisión formal (abajo). Los errores de una .dkk se informan en el paso 9.a aunque se decodifique antes: la CLI de referencia la decodificaba antes del paso 1, así que datekeys decrypt -in time_only.dkc -dkk con una .dkk de access_type mlkem768 fallaba con ERR_ACCESS_INVALID, mientras capsule.Open abría la misma cápsula con la misma credencial.
Modelo de confianza (§55.1, §72). Caso: con los bytes públicos de time_only.dkc cualquiera construye otra cápsula con el mismo PRELUDE, la misma PUBLIC_HEADER y otro plaintext, que supera los 18 pasos; y otra data en la extensión de time_and_key_portable_extension.dkk abre la cápsula igual. La especificación solo lo decía de time_only (§36.1) y de la data de las extensiones (§72), sin una regla sobre dónde registrar afirmaciones de seguridad.
Orden de extension_id (§31, §54). Caso: el vector de cbor.json con U+FF61 y U+10000 en el orden de UTF-16 (ERR_NON_CANONICAL_CBOR); §31 solo pedía al encoder «ordenar por bytes UTF-8», sin definir la comparación ni lo que hace el decoder. Además, extension_id tiene al menos 1 byte: el vector «empty extension_id» de cbor.json (ERR_NON_CANONICAL_CBOR) dependía de ese mínimo, que §31 no decía: el CDDL lo incluía en su bloque de límites de la implementación de referencia (extension-id = tstr .size (1..256)), y la tabla de límites de testdata/README.md lo daba como rango normativo («1 byte or more») sin citar ninguna sección.
Huecos que la especificación dejaba a la implementación, con el comportamiento que ya tenía la referencia salvo donde se indica:
1. cabeceras age mal formadas, incluida una sin stanzas, que la gramática de C2SP excluye (1*stanza) (§28.1, §36): 10 casos de inspect_differential.json fallan por una cabecera sin stanzas con ERR_INTEGRITY, 5 en el paso 5 y 5 en el paso 6;
2. cota de round_time en 9999-12-31T23:59:59Z y rechazo de los instantes anteriores a genesis_time (§15): los vectores «after the last representable round» y «genesis - 1s: before the profile» de quicknet_rounds.json, «last Quicknet round» de dk1.json y 6 casos del paso 7 de inspect_differential.json;
3. reglas de lectura de dk1_ (§19): de ellas dependen «padded Base64URL», «non-zero trailing bits», «fraction notation», «duplicate key» y «byte order mark» en dk1.json; esta última dependía de que el parser JSON de la referencia rechaza el BOM, que RFC 8259 permite ignorar. La referencia aceptaba CR y LF dentro del Base64, porque los decodificadores de Go los omiten, e informaba ERR_DATEKEY_NON_CANONICAL; ahora falla el paso 1 con ERR_DATEKEY_INVALID, como en una implementación que sigue el texto, en la que la revisión diferencial de la segunda implementación encontró 799 discrepancias de esta clase en 20 000 casos. Un número JSON se lee por su valor decimal exacto: con un double, 1.0000000000000001 sería 1. Vectores nuevos de dk1.json: «line feed inside the Base64», «carriage return and line feed after the Base64», «version 1.0000000000000001: its exact value, not a double» e «invalid UTF-8 in a member a repeated name overwrites». Este último lo encontró el diferencial de la segunda implementación: encoding/json sustituía el UTF-8 inválido por U+FFFD, así que un miembro que un nombre repetido sobrescribe superaba los pasos 2 y 3, y la referencia informaba ERR_DATEKEY_NON_CANONICAL en el paso 6; §19 lo hace fallar en el paso 2, con ERR_DATEKEY_INVALID;
4. cotas inferiores de las longitudes (§22, §23, §40, §57): un caso de inspect_differential.json con PUBLIC_HEADER_LEN 0 da ERR_INTEGRITY en el paso 2, y otros tres con FLAGS distinto de 0 dan ERR_INVALID_FLAGS; BODY_LEN 0 en una .dkk, que la referencia informaba como ERR_NON_CANONICAL_CBOR al decodificar un cuerpo vacío, pasa a ERR_INTEGRITY, como en §22;
5. comparación de los argumentos del stanza tlock (§35, §63 paso 8): la mutación «tlock round edited by a third party» y los 69 casos del paso 8 de inspect_differential.json; 01000, +1000 o un chain hash en mayúsculas no coinciden;
6. validación del Provider Profile y fórmula de chain_hash (§12.1): el bloque provider_profile de cbor.json, con «network default, left out of the chain hash» y «genesis_time 253402300799, 9999-12-31T23:59:59Z». Los alfabetos de los nombres son normativos, porque el JSON canónico de dk1_ no define escapes (§18): de ellos dependen «invalid profile_id» en cbor.json, «uppercase network» en dk1.json y las mutaciones 46, 746, 1138 y 1754 de inspect_differential.json (ERR_DATEKEY_INVALID en el paso 4); sus longitudes siguen siendo límites de implementación. period es como mucho 2³² − 1 para pinnear el perfil: drand escribe uint32(period) en el hash de la información de cadena, y para un valor mayor el hash no está definido; ningún vector lo alcanza, porque el límite de 86400 segundos de la referencia falla antes. Al pinnear un perfil, la referencia aplicaba las reglas de campo antes que el schema: un period de 86401 segundos era ERR_UNKNOWN_PROFILE en profile.NewRegistry y ERR_NON_CANONICAL_CBOR en profile.Decode; ahora los dos dan el segundo. Un punto de G1 que está en la curva pero fuera del subgrupo de orden primo es ERR_UNKNOWN_PROFILE;
7. límites de implementación (§74): el vector «period of one day and one second, above the implementation limit» de cbor.json; en INNER_ACCESS_AGE, una cabecera que supera los del parser es ERR_POLICY_STRUCTURE_MISMATCH en el paso 12, como toda cabecera mal formada ahí (§28.1);
8. credenciales y reloj en el paso 9 (§63): las mutaciones «time_and_key without credentials» (ERR_ACCESS_REQUIRED, paso 9, sin red), «round not reached yet» (ERR_RELEASE_UNAVAILABLE, paso 9, sin red) y «access_policy=time_only with time_and_key structure», que ofrece una .dkk que no interviene y falla en el paso 12 por la regla de §36 para time_only, que tampoco estaba escrita: un resultado que empieza por la línea de versión de age es ERR_POLICY_STRUCTURE_MISMATCH en el paso 12, y cualquier otro se decodifica como CONTROL_CBOR en el paso 14. Sin credenciales, ERR_ACCESS_REQUIRED va antes que el reloj; la referencia contaba una identity nula como credencial y, con el reloj antes de round_time, informaba ERR_RELEASE_UNAVAILABLE;
9. verificación del release en el paso 10 (§17, §51, §63): las mutaciones de §64 «DateKey A + release of round B» (ERR_ROUND_MISMATCH, con una firma válida de la ronda 1001) y «release of another round» (ERR_RELEASE_INVALID, con la firma de la ronda 1001 presentada como de la ronda 1000) dependen de comparar la ronda antes que la firma, algo que solo decía testdata/README.md;
10. códigos de las identities en los pasos 11, 13 y 17 (§28.1, §36, §63): §27 y esos pasos exigían que la identity rechazara el fichero sin asignar código, y los códigos solo estaban en los vectores de mutations.json y, para una identity que no es recipient (ERR_ACCESS_INVALID, paso 13), en testdata/README.md. Casos: las mutaciones «identity that is not a recipient» (ERR_ACCESS_INVALID, paso 13), «two INNER_ACCESS_AGE stanzas for one recipient» (ERR_POLICY_STRUCTURE_MISMATCH, paso 13) y «SEALED_CONTROL_A + PAYLOAD_AGE_B» (ERR_INTEGRITY, paso 17); y el share efímero repetido en INNER_ACCESS_AGE, que la referencia rechazaba en el paso 12 sin regla en §36. La referencia probaba las identities en orden y aceptaba el fichero con la primera que desenvolvía un stanza, aunque otra desenvolviera dos; ahora es ERR_POLICY_STRUCTURE_MISMATCH en cualquier orden.

Estos refinamientos cambian el código de la implementación de referencia en entradas que ningún vector oficial existente recoge: una .dkk con fallos a la vez en el objeto y en su vínculo con la cápsula, y una .dkk que la CLI no puede decodificar, ahora en el paso 9.a (punto 1); CR o LF en un dk1_, y UTF-8 inválido en un miembro que un nombre repetido sobrescribe (punto 4.3); una .dkk con BODY_LEN 0 (punto 4.4); los códigos de profile.NewRegistry (punto 4.6); una identity nula (punto 4.8); y dos identities de las que una desenvuelve dos stanzas (punto 4.10). Reproducen cada caso los tests capsule.TestPrecedenceWithinPublicHeader, TestPrecedenceAcrossSteps, TestAccessKeyCheckOrder, TestAccessKeyFileAtStep9, TestControlCriticalBeforeHeaderBinding, TestFrameLengthLowerBounds, TestMalformedAgeHeaders, TestTlockStanzaArgumentComparison y TestTrustModel; accesskey.TestDecodePrecedence; agewrap.TestAccessIdentityStrictness y TestMalformedX25519Stanzas; datekey.TestReadingRules; profile.TestDecodePrecedence, TestChainHashFormula y TestPinPathMatchesDecode; provider.TestVerifyRejects; extension.TestOrderIsUnsignedBytewise; y cmd/datekeys.TestDecryptAccessKeyOrder.

Enmienda de la v0.8.2: canonicidad de puntos

La v0.8.2 sigue sin publicarse, así que esta enmienda también la modifica sin cambiar de versión. Fija la codificación de los puntos de BLS12-381 y el contenido del stanza tlock, que la especificación dejaba a las librerías:

nuevo §12.2: la codificación canónica de un punto, la comprimida de drand, única para cada punto; un decodificador rechaza cualquier otra cadena, como x + p, una identidad con carga o con signo, la forma sin comprimir o una longitud distinta;
§12.1, punto 2: public_key es una codificación canónica distinta del punto en el infinito, con el mismo código, ERR_UNKNOWN_PROFILE;
§63, paso 10: la firma es la codificación canónica de un punto del grupo de firmas del scheme distinto del infinito y verifica como firma de la ronda, o ERR_RELEASE_INVALID; ERR_ROUND_MISMATCH conserva su precedencia;
§63, paso 11: el cuerpo del stanza tlock es U || V || W, con |U| el tamaño de punto del grupo de claves del scheme y |V| = |W| = 16; U es una codificación canónica distinta del infinito, y el descifrado IBE-CCA comprueba r·G == U; cualquier fallo, incluida una longitud distinta de 128 bytes en Quicknet, es ERR_INTEGRITY;
§64: diez mutaciones nuevas, con su código y su paso; §69.1 gana su ejemplo de precedencia, §73 resume las dos decisiones y §77 cita el formato de serialización.

Caso reproducible que la justifica, de una segunda implementación independiente: su investigación de la fase 2 encontró que tlock-js 0.9.0 sobre @noble/curves 1.9.7 acepta un U recodificado como c0 + p y una firma recodificada como x + p, y devuelve la misma file key que con las codificaciones canónicas, mientras la implementación de referencia rechaza las dos, con ERR_INTEGRITY en el paso 11 y ERR_RELEASE_INVALID en el paso 10: una cápsula así se abriría en una implementación sobre esa librería y fallaría en la referencia. noble 1.9.7 discrepaba del decodificador de la referencia en 5 615 de 41 686 codificaciones de punto: 5 612 coordenadas no canónicas (x + p, c0 o c1 + k·p) que reducía al punto correcto y 3 identidades con flags o carga no nula. La especificación callaba: §12.1 pedía «la codificación comprimida de BLS12-381 que usa drand» sin exigir x < p, y el paso 11 no definía el cuerpo del stanza.

La implementación de referencia ya rechazaba todas esas entradas con el código y el paso que fija el texto: ningún código cambia. Solo cambia dónde rechaza un U en el infinito, antes de descifrar en lugar de en la comprobación r·G == U, con el mismo ERR_INTEGRITY. Ningún fixture ni vector existente cambia de bytes ni de veredicto: mutations.json gana los diez casos de §64, en los que la cabecera age de los U y cuerpos editados conserva un MAC válido. La firma con x + p usa la ronda 1004 de Quicknet, la primera después de la 1000 cuya firma lo permite: ninguna de las rondas de los fixtures (1000, 1001 y 2000) tiene una x menor que 2³⁸¹ − p. Reproducen cada caso los tests capsule.TestExportedMutationCorpus y TestPointMutationsChangeOnlyTheEncoding; profile.TestDrandPointDecodersAreCanonical y TestPublicKeyEncodingIsCanonical; provider.TestVerifyRejects; y agewrap.TestTimeIdentityStrictness y TestTimeIdentityRelease.

Correcciones de la revisión formal

La v0.8.2 sigue sin publicarse, así que estas correcciones también la modifican sin cambiar de versión. Proceden de la revisión formal e independiente de esta especificación, una de las fuentes que admite esta política («revisión criptográfica o técnica externa»). Tres de sus observaciones cambian reglas normativas:

Release inválido obtenido por red (§63 pasos 9 y 10, §69.1). Una fuente que obtiene releases por red MUST verificar cada respuesta con las reglas del paso 10 y descartar la que no las cumple; si ninguna entrega un release que las cumpla, el código es ERR_RELEASE_UNAVAILABLE, en el paso 9. Los códigos del paso 10 son los de un release que el llamador suministra directamente, como en los vectores oficiales. Caso: el texto no decía dónde verifica una fuente de red, así que un release de otra ronda firmado para esa ronda, única respuesta de un relay, daba ERR_RELEASE_UNAVAILABLE en el paso 9 con la referencia, cuyo cliente drand descarta toda respuesta que no verifica, y ERR_ROUND_MISMATCH en el paso 10 con una fuente que lo devolviera sin verificar, aunque §69.1 afirmaba que, fuera de las comprobaciones opcionales, ninguna elección de la implementación podía cambiar el código.
Objetos y arrays de cada extensión (§31, §54, §69.1, §72). Cada extensión registrada MUST declarar los objetos y el array en que puede aparecer, y una extensión conocida que aparece en un objeto o array para el que no está registrada se trata allí como desconocida. Caso: §72 exige registrar en CONTROL_CBOR una extensión con afirmaciones relevantes para la seguridad, pero un lector que la conocía la aceptaba en cualquier objeto: copiada en las extensiones críticas de PUBLIC_HEADER, que cualquiera puede escribir (§55.1), o de una .dkk, superaba el paso 4 o el 9.
Serialización de GT en H2 (§63 paso 11, §77). H2, H3 y H4 son las de encrypt/ibe de drand/kyber, y H2 resume el elemento de GT en el orden de kilic/bls12-381, c1 antes que c0 en cada nivel de la torre, con el vector H2(e(G1, G2)) = cb87319f24560b5231579a09ad79f12e, nuevo en testdata/vectors/tlock_ibe.json. Caso: el paso 11 citaba H2 sin fijar la serialización, y en el orden de Fp12.toBytes de noble, c0 antes que c1, H2(e(G1, G2)) es 0118eea9d5971745f71e3c94926f1717: una implementación sobre esa librería que siguiera el texto derivaría otra FK_TIME y no abriría ninguna cápsula.

Las demás observaciones no cambian ninguna regla ni ningún código: §27 remite la autenticidad de PUBLIC_HEADER al modelo de confianza (§55.1) y precisa que el MAC de age solo protege frente a quien no conoce la file key; el paso 5 separa la lectura de SEALED_CONTROL, obligatoria como ya fijaban §23 y §69.1, de la inspección de su cabecera; el paso 15 nombra su código, ERR_HEADER_BINDING; §21 hace MUST los 16 bytes de capsule_id que ya exigían §24, datekeys.cddl y §57; §77 gana RFC 8259, RFC 8610 y RFC 4648; y hay correcciones de redacción en §5, §36, §55.1, el paso 13, la capa 1 de §69.1 y §72. En este registro, los refinamientos cuentan cuatro vectores nuevos de dk1.json, no tres, con el de UTF-8 inválido (punto 4.3); el punto 4.8 recoge la regla de §36 para time_only; el punto 1 ya no dice que solo las comprobaciones opcionales pueden cambiar el código; y los casos 3 y 4.10 citan los textos que existían, en lugar de otros que ninguna versión anterior contenía.

La implementación de referencia ya seguía las correcciones 1 y 3: ningún código cambia. Para la 2 gana la interfaz opcional extension.Placement, que consultan las comprobaciones de extensiones de los pasos 4, 9.a y 14; un registro que no la implementa conoce sus extensiones en todos los objetos y arrays, como antes. Ningún fixture ni vector existente cambia. Reproducen cada caso los tests capsule.TestReleaseFromANetworkSource y TestExtensionPlacement; extension.TestPlacement; y agewrap.TestTlockH2Vector.

Una segunda ronda de la misma revisión confirmó estas correcciones y pidió otras tres, que también modifican la v0.8.2 sin cambiar de versión:

Extensiones fuera de su registro, al escribir (§54, §72). Un encoder MUST NOT escribir una extensión registrada en un objeto o array para el que no está registrada, y un lector que ignora por esa causa una extensión no crítica MUST NOT interpretar su data. Caso: la corrección 2 solo obligaba al lector, así que un escritor podía sellar en las extensiones críticas de CONTROL_CBOR una extensión registrada allí solo como no crítica, y un lector que conoce su registro la rechaza en el paso 14, con la cápsula ya desbloqueada (ERR_EXTENSION_CRITICAL_UNKNOWN): nadie que siga el registro puede abrirla.
Códigos del paso 10 en §17 y §51. §17 asignaba ERR_ROUND_MISMATCH, y §51 los dos códigos del paso 10, a todo release; ahora dicen, como el paso 10, que son los de un release que el llamador suministra directamente, y que el que llega de una fuente de red sin cumplir esas reglas lo descarta su fuente en el paso 9. Caso: tras la corrección 1, §17 contradecía el ejemplo de §69.1 «El mismo release, única respuesta de un relay», que da ERR_RELEASE_UNAVAILABLE en el paso 9, y no ERR_ROUND_MISMATCH.
Un solo código en el paso 9 (§63 paso 9, §69.1). Si ninguna fuente entrega un release, por cualquier causa, el código es ERR_RELEASE_UNAVAILABLE, aunque el fallo de la fuente lleve el código de otra regla. Caso: la referencia informaba en el paso 9 el código que trajera el error de la fuente, así que una fuente del llamador que fallaba con ERR_RELEASE_INVALID daba ERR_RELEASE_INVALID en el paso 9; y el error de su cliente drand envolvía, además de ERR_RELEASE_UNAVAILABLE, el código del fallo de cada relay: con un único relay que devuelve la ronda 1001, el código era ERR_RELEASE_UNAVAILABLE, pero el error también era ERR_ROUND_MISMATCH para errors.Is, contra la regla de la referencia de que cada error envuelve exactamente un código.

Las demás observaciones de la segunda ronda son de redacción: §28.1 dice que los pasos 5 y 6 analizan solo la cabecera age, porque el paso 5 lee SEALED_CONTROL entero; el paso 9 une sus dos flechas hacia ERR_RELEASE_UNAVAILABLE; y la introducción de este apartado termina en su lista y nombra después los bloques que la completan, y la de las correcciones dice que tres de ellas cambian reglas normativas, no el texto normativo, que también cambian las demás. Fuera de la especificación, testdata/README.md dice dónde están registradas las extensiones del corpus de mutaciones: en los dos arrays de todos los objetos, así que sus casos de data inválida no dependen de la ubicación.

La corrección 6 cambia el código de la implementación de referencia en entradas que ningún vector oficial recoge: el error de una fuente que lleva otro código normativo se informa en el paso 9 con ERR_RELEASE_UNAVAILABLE como único código y conserva solo su texto, y provider/drand.Client guarda el fallo de cada relay solo como texto. Para la 4, capsule.Encrypt y accesskey.Encode no reciben un registro de extensiones: escriben las que se les dan, y la aplicación, que conoce el registro, aplica la regla. Ningún fixture ni vector existente cambia. Reproducen cada caso los tests capsule.TestExtensionPlacement, que ahora cubre también el array no crítico de una .dkk, y TestReleaseSourceErrorsAtStep9; provider/drand.TestFetchErrorHasOneCode y TestUnavailabilityAndCancellation; y datekeys.TestCode.

Cambios normativos de la v0.9

La v0.9 añade el formato 2 de .dkc, que oculta hasta la fecha la longitud exacta del contenido y el número de credenciales, y pasa a texto normativo las reglas del escritor. Los casos se obtuvieron con la implementación de referencia v0.8.2, sus fixtures y las librerías age de Go (filippo.io/age 1.3.2) y TypeScript (age-encryption 0.3.1). Los tests son los de la implementación de referencia: los marcados «ampliado» existían en la v0.8.2, y los demás se añadieron al implementar la v0.9.

Formato de la cápsula (§22, §23, §24, §26, §31, §40, §63 pasos 2, 4 y 14, §69.1, §70).
- Cambio: VERSION del PRELUDE es el formato, 1 (el de la v0.8.2) o 2. CONTROL_CBOR tiene la versión de schema que §22 asigna a su formato, 1 o 2; otra es ERR_UNSUPPORTED_VERSION en el paso 14, capa 2. PUBLIC_HEADER y la .dkk conservan la versión 1. Un escritor MUST escribir el formato 2; un lector MUST abrir los dos, el 1 con la semántica de la v0.8.2. Un código de relleno nuevo exige un formato nuevo.
- Motivo: un lector v0.8.2 debe rechazar una cápsula v0.9 antes de pedir el release. Sin un cambio visible de versión, la abriría hasta el paso 14 y fallaría allí, tras la petición de red, por la versión 2 de su control o, si el control conservara la versión 1, por las claves 6 y 7, desconocidas en su mapa cerrado (§58).
- Caso: la mutación «version changed» de mutations.json ([4,1,"02"] sobre time_only.dkc) da ERR_UNSUPPORTED_VERSION en el paso 2, sin red, con la implementación de referencia v0.8.2. Se cambia VERSION y no la versión de PUBLIC_HEADER porque es la primera comprobación, porque el cambio es de toda la cápsula y la cabecera no cambia, y porque así siguen valiendo los vectores «schema version 2» de PUBLIC_HEADER en cbor.json, la mutación «header schema version changed» y el ejemplo de §69.1 «Versión 2, una clave desconocida y una DateKey inválida». Un magic DKC2 daría en un lector v0.8.2 ERR_INVALID_MAGIC, que dice «no es una cápsula». Una cápsula de formato 2 con VERSION 1 falla en el paso 14 en los dos lectores, por la versión 2 de su control, salvo que antes falle el capsule_digest de una .dkk en el paso 9.a.
- Tests: capsule.TestFormatDispatch, TestFormatRelabel y TestFormat1Compatibility; capsule.TestExportedMutationCorpus y TestDecodeControlRejects, ampliados.
16 huecos en INNER_ACCESS_AGE (§33, §36, §36.1, §38, §39, §57, §63 pasos 12 y 13).
- Cambio: en formato 2, time_and_key lleva exactamente 16 stanzas X25519: de 1 a 16 credenciales y, en los huecos libres, señuelos cuya clave privada se descarta en el acto. Otro número es ERR_POLICY_STRUCTURE_MISMATCH en el paso 12.
- Motivo: el número de credenciales era visible para cualquiera.
- Caso: SEALED_CONTROL_LEN (bytes 12 a 15 del PRELUDE) vale 646 en time_and_key_portable.dkc, con una credencial, y 842 = 646 + 2·98 en time_and_key_recipients.dkc, con tres: cualquiera cuenta las credenciales antes de la fecha, y tras el release en la cabecera de INNER_ACCESS_AGE. En formato 2, con la ronda 1000 y sin extensiones de control, vale siempre 2128 en time_and_key y 458 en time_only. Un señuelo envuelve la misma FK_ACCESS: una cápsula sellada conservando la clave privada de un señuelo se abre con ella.
- Tests: capsule.TestInnerHasSixteenStanzas y TestDummyRecipients; agewrap.TestAccessSlots.
Orden aleatorio de los stanzas (§39, §62 paso 6, §62.1 regla 4).
- Cambio: el orden de los 16 stanzas en la cabecera es una permutación uniformemente aleatoria, sin sesgo; la permutación y qué huecos son señuelos no se almacenan ni se entregan.
- Motivo: sin esta regla, los señuelos no ocultan el número de credenciales a quien tiene una.
- Caso: filippo.io/age y age-encryption escriben los stanzas en el orden de sus recipients, y capsule.Encrypt añade R_ACCESS al final. Con los señuelos detrás de las credenciales, quien abre el stanza k sabría que hay al menos k credenciales, y quien tiene la clave portable, la última, sabría su número exacto.
- Tests: capsule.TestStanzaOrderIsUniform.
Relleno del payload (§29, §29.1, §30, §30.1, §55.1, §56, §63 pasos 16 a 18).
- Cambio: en formato 2 el plaintext de PAYLOAD_AGE es el contenido seguido de ceros hasta P = regla(L), con los códigos 1 (bloque256) y 2 (reforzado, con Padmé), sin regla sin relleno. Un plaintext de otra longitud o con un byte de relleno distinto de 0x00 es ERR_INTEGRITY en el paso 17. El lector entrega solo los L primeros bytes y no los presenta como válidos antes de que el paso 17 termine; si los escribe en streaming, no escribe el relleno y señala el error para que se descarte lo escrito. La aritmética es entera y de más de 32 bits.
- Motivo: la longitud exacta del contenido era visible para cualquiera. Se elige ERR_INTEGRITY porque el fallo es del binding control ↔ payload de §30.1, cuyos fallos ya son ERR_INTEGRITY en el paso 17, como «SEALED_CONTROL_A + PAYLOAD_AGE_B»; ERR_POLICY_STRUCTURE_MISMATCH es de stanzas, ERR_HEADER_BINDING solo cubre la cabecera, y un código nuevo cambiaría §69.
- Caso: time_only.dkc mide 78 799 bytes y su PAYLOAD_AGE, 78 216 = 184 + 78 000 + 2·16: cualquiera lee L = 78 000. El PAYLOAD_AGE de empty_payload.dkc, de 200 bytes, da L = 0. En formato 2 con el código 2, un PAYLOAD_AGE de 80 088 bytes corresponde a cualquier L entre 77 825 y 79 872. Aritmética: un Padme con los operadores de 32 bits de JavaScript da una P incorrecta por primera vez en L = 2 113 929 217 con los operadores con signo (2 113 929 472 en lugar de 2 147 483 648), y en L = 4 227 858 433 con >>> 0 (4 227 858 688 en lugar de 4 294 967 296). Sin las filas de §29.1 para esos dos L pasaría todas las demás hasta 2³² − 1, y también la de L_MAX, estas dos por coincidencia, porque en ellas Padme no supera a bloque256; solo fallaría por encima de 2³², como en L = 2³² + 1 (4 294 967 552 en lugar de 4 362 076 160); Math.log2(2^49 − 1) da 49 en Node, y el valor correcto de E es 48.
- Tests: capsule.TestPaddingRules, TestPaddingChecksAtStep17 y TestPaddingAcrossChunks; capsule.TestTrustModel, ampliado.
L de longitud fija y L_MAX (§31, §57, §58, §58.1, §69.1 capa 3).
- Cambio: L y el código van sellados en las claves 6 y 7 de CONTROL_CBOR versión 2, obligatorias en ella y prohibidas en la versión 1. L es una cadena de 8 bytes big-endian de como mucho L_MAX = 2⁵³ − 2⁴⁶. Toda violación es ERR_NON_CANONICAL_CBOR en el paso 14, capa 3.
- Motivo: la longitud de CONTROL_CBOR es visible en SEALED_CONTROL_LEN, y no debe depender de L. L_MAX es el mayor L para el que las dos reglas dan una P de como mucho 2⁵³ − 1 (§58): reforzado(L_MAX + 1) = 2^53.
- Caso: con L como entero CBOR en su forma más corta (§58), su valor ocuparía 1, 2, 3, 5 o 9 bytes, y SEALED_CONTROL_LEN lo revelaría: en el hueco P = 256, el de los mensajes cortos, distinguiría L < 24, 24 ≤ L ≤ 255 y L = 256; en P = 65 536, L = 65 536 del resto. Con 8 bytes fijos, un CONTROL_CBOR de versión 2 sin extensiones mide siempre 103 bytes.
- Tests: capsule.TestControlLengthIsConstant; capsule.TestDecodeControlRejects, ampliado.
Lectura de L y P (§31, §57, §63 pasos 16 y 17, §69.1).
- Cambio: un lector MUST NOT reservar memoria ni disco según L o P antes de recibir el plaintext; MAY comprobar en el paso 17 la longitud de PAYLOAD_AGE, con el mismo código.
- Motivo: L es un dato del control, no una longitud de trama, y cualquiera puede sellar un control time_only (§36.1).
- Caso: un control time_only que declara L = L_MAX junto a un PAYLOAD_AGE de 456 bytes; un lector que reservara según L pediría más de 8·10¹⁵ bytes.
- Tests: capsule.TestDeclaredLengthIsNotAllocated.
Consideraciones de privacidad (§4, §5, §55.2, §70).
- Cambio: nueva §55.2, con lo que revela una cápsula antes y después de la fecha, a quién, y lo que el formato 2 impide comprobar. access_policy sigue visible. Una implementación SHOULD indicar al llamador el formato de una cápsula.
- Motivo: el texto no decía qué metadatos protege el protocolo.
- Caso: los de los cambios 2 y 4. access_policy sigue visible porque de ella depende la mutación «time_and_key without credentials» (ERR_ACCESS_REQUIRED, paso 9, sin red).
- Tests: los de los cambios 2, 4 y 5.
Orden de escritura (§61, §62, §62.1 regla 7).
- Cambio: SEALED_CONTROL_LEN es la longitud exacta de SEALED_CONTROL, conocida antes de calcular header_binding, medida con un sellado provisional o calculada, y comprobada después.
- Motivo: el orden de la v0.8.2 no se podía seguir.
- Caso: §61 y §62 construían el PRELUDE (paso 6) antes que SEALED_CONTROL (pasos 9 y 10 de §61, 9 a 11 de §62), cuya longitud lleva el PRELUDE, y header_binding, que cubre el PRELUDE, va dentro del control sellado: el orden era circular. capsule.Encrypt lo resuelve sellando antes un control provisional de la misma longitud, algo que el texto no decía.
- Tests: capsule.TestSealedControlLength.
I_PAYLOAD nueva (§29, §30.1, §62.1 regla 5).
- Cambio: I_PAYLOAD sale de un CSPRNG para cada cápsula y no se reutiliza ni se deriva de otro valor.
- Motivo: confidencialidad. §29 solo decía «aleatoria».
- Caso: si dos cápsulas time_only comparten I_PAYLOAD, abrir la primera en su fecha, lo que puede hacer cualquiera, abre el payload de la segunda antes de la suya; y «SEALED_CONTROL_A + PAYLOAD_AGE_B» (§64) se abriría en lugar de fallar en el paso 17. Derivada del contenido, cualquiera comprueba un contenido que adivina antes de la fecha.
- Tests: capsule.TestPayloadIdentityReuse.
Recipients no canónicos y de orden bajo (§37, §62.1 regla 3).
- Cambio: el escritor MUST rechazar un recipient con el bit 255 a 1, con u ≥ p o de orden bajo, y MAY rechazar uno de la torsión cuadrática.
- Motivo: su stanza no lo abre nadie, o lo abriría cualquiera, y las reglas del lector (§63) no lo detectan.
- Caso: filippo.io/age 1.3.2 y age-encryption 0.3.1 cifran para un recipient con el bit 255 a 1 un stanza que su identity no abre («incorrect identity for recipient block» y «no identity matched any of the file's recipients»): el salt de HKDF lleva los 32 bytes recibidos, y la identity usa su clave pública canónica. Con la u cero, de orden bajo, las dos librerías fallan al cifrar.
- Tests: agewrap.TestNonCanonicalRecipients.
Credenciales y reloj del escritor (§15, §39, §62.1 reglas 2 y 3).
- Cambio: el instante pedido es posterior al reloj del escritor; time_only no admite credenciales; time_and_key admite de 1 a 16, sin repetir.
- Motivo: la referencia ya aplicaba estas reglas sin texto normativo que las exigiera, y el máximo de 16 procede del cambio 2.
- Caso: capsule.TestEncryptRejectsInvalidOptions rechaza un instante que no es posterior al reloj, time_only con credenciales, time_and_key sin ellas y un recipient repetido. Un recipient repetido daría a su identity dos stanzas, y la cápsula fallaría para ella en el paso 13 (mutación «two INNER_ACCESS_AGE stanzas for one recipient»).
- Tests: capsule.TestEncryptRejectsInvalidOptions, ampliado, y TestCredentialBounds.
L conocida antes de sellar y errores del escritor (§61, §62.1 reglas 6 y 9).
- Cambio: el escritor conoce L antes de sellar el control, MAY volcar la fuente a un fichero temporal y MUST NOT suponer L; ante un error lo informa, y quien recibe la salida la descarta.
- Motivo: en formato 2, L se sella antes que el payload.
- Caso: capsule.Encrypt escribe el PRELUDE, la cabecera y el control en dst y después cifra en streaming una fuente de longitud desconocida; su documentación ya dice que, ante un error, dst puede tener una cápsula parcial que hay que descartar. Si la fuente entregara otra longitud que la sellada, la cápsula fallaría en el paso 17, cuando ya no puede repararse.
- Tests: capsule.TestEncryptSourceLength.
Autocomprobación y borrado (§62.1 reglas 11 y 12, SHOULD).
- Cambio: el escritor comprueba su propia salida, también la longitud del plaintext entregado a age y la de PAYLOAD_AGE, y borra los secretos después.
- Motivo: un error del escritor solo se descubre tras la fecha.
- Caso: el caso 5 de la v0.8.2: Encrypt selló un CONTROL_CBOR que el lector rechazaba en el paso 14, con la cápsula ya desbloqueada. Un relleno omitido superaría la comprobación de que I_PAYLOAD abre la cabecera de PAYLOAD_AGE, revelaría L exacta y fallaría en el paso 17.
- Tests: capsule.TestEncryptSelfCheck.

Ningún código de error es nuevo (§69).

Ningún objeto de formato 1 cambia de veredicto ni de código: solo cambian las entradas con VERSION 2, que la v0.8.2 rechazaba en el paso 2. Los cinco fixtures y las mutaciones construidas por el creador, todos de formato 1, quedan como casos de compatibilidad (§70), y ninguno de los 1 825 casos de inspect_differential.json produce VERSION 2: sus ediciones del byte 4 dan a7, 05, e8 y 20. Cambian estos datos de prueba:

la mutación «version changed» pasa a VERSION 3 ([4,1,"03"]): con VERSION 2, ese time_only.dkc de formato 1 llega al paso 14 (ERR_UNSUPPORTED_VERSION), un caso que pasa a la lista nueva de §64;
las mutaciones de time_and_key de esa lista ofrecen la identity, sin .dkk, y cada una tiene un caso compañero con la .dkk, fuera de §64, que falla en el paso 9.a con ERR_ACCESS_INVALID;
los vectores control_cbor de cbor.json dependen del formato y ganan el campo format, 1 por omisión: «schema version 2» es ERR_UNSUPPORTED_VERSION en formato 1 y ERR_NON_CANONICAL_CBOR en formato 2, donde le faltan las claves 6 y 7. Entre los nuevos de formato 2, payload_length = 48 0000000100000001 se acepta como 4 294 967 297 (§58), y uno de 7 o de 9 bytes, o codificado como entero CBOR, es ERR_NON_CANONICAL_CBOR. «unknown key 6» conserva su veredicto en formato 1, y pasa a llamarse «key 6, defined only in schema version 2», porque la clave 6 ya existe;
«código de relleno 3 y una extensión crítica desconocida» no puede ser un vector de cbor.json, cuyos vectores de schema no comprueban extensiones críticas: es un caso de capsule.TestPrecedenceAcrossSteps, ampliado, como los demás ejemplos nuevos de §69.1;
testdata/README.md cita la mutación «version changed», la «framing version» y el número de mutaciones de §64;
las 33 mutaciones de las dos primeras listas de §64 se aplican también a fixtures de formato 2, con el prefijo «format 2: », y inspect_differential.json conserva sus 1 825 casos y añade un bloque por cada fixture de formato 2;
capsule.Open no registraba el éxito del paso 17, así que las etapas de los fixtures pasaban del 16 al 18; con las comprobaciones nuevas de ese paso, que §67 necesita, lo registra, y los registros de los fixtures de formato 1 ganan esa etapa y el campo format.

Cambios normativos de la v0.10

La v0.10 añade el formato 3 de .dkc, que guarda varios ficheros con sus rutas, tamaños, hashes y fechas, cifrados, y reserva el área security para una firma de autor y un sello de tiempo que definirán versiones posteriores sin cambiar el formato. Es la primera de tres entregas del formato 3; la segunda definirá la firma, y la tercera, el sello. El diseño pasó una revisión de seguridad externa y dos revisiones adversariales. Los casos se obtuvieron con la implementación de referencia v0.9, con datekeys-ts 0.2.0-dev, con las librerías age de Go (filippo.io/age 1.3.2) y TypeScript (age-encryption 0.3.1), y en la máquina de desarrollo. Las pruebas son las previstas: se nombrarán al implementar la v0.10.

Formato 3 (§1, §6, §22, §23, §24, §27, §31, §33, §36, §38, §39, §63 pasos 2, 12 a 14 y 16 a 18, §69.1, §70).
- Cambio: VERSION 3. CONTROL_CBOR de versión 3, con las claves de la 2; en formato 3, L es la longitud de BODY. Un escritor MUST escribir el formato 3; un lector MUST abrir los tres, el 1 y el 2 con la semántica de sus versiones.
- Motivo: hasta la v0.9 una cápsula guarda un solo fichero, y su nombre y sus fechas quedan fuera del protocolo (§6, §55.2). Guardar varios ficheros con sus metadatos cambia la semántica del plaintext, y un lector v0.9 solo lo notaría después de pedir el release: §22 exige un formato nuevo.
- Caso: la página /inspect de datekeys-ts 0.2.0-dev descarga el contenido de una cápsula con un nombre que deduce de su tipo, porque la cápsula no guarda el suyo. Un lector v0.9 que abriera un BODY lo entregaría entero, trama y head incluidos, como si fuera el contenido. Con VERSION 3, la implementación de referencia v0.9 rechaza la cápsula en el paso 2 (framing.go:56), sin red.
- Pruebas previstas: las mutaciones de VERSION de §64 y los fixtures format3_* de §67.
Trama del contenido y área (§29.2, §55.2, §57, §62.1 regla 13).
- Cambio: BODY empieza por AREA_LEN, SECURITY_LEN y HEAD_LEN. El área tiene un tamaño fijo por versión del spec, 512 bytes en esta, y va siempre. El lector acepta cualquier área válida.
- Motivo: el tamaño de lo que lleve security no debe cambiar L, porque P revelaría si una cápsula lleva firma o sello.
- Caso: con un fichero nota.txt de 1100 bytes, con mtime, y un área que midiera lo que SECURITY_CBOR, L sería 1251 sin firma y 1359 con una firma Ed25519, que ocupa 108 bytes, y P valdría 1280 y 1536: P delataría la firma. Con el área fija, L = 1741 en los dos casos.
- Pruebas previstas: format3_area_1024 y las mutaciones de la trama de §64.
security (§29.3, §29.7, §69.1).
- Cambio: mapa de versión 1 cuyas claves 2 y 3 son cadenas de bytes con la firma y el sello codificados aparte. Nunca decide la apertura. En esta versión se escribe vacío, y ningún alg ni seal_type está definido.
- Motivo: el formato se congela en esta versión, y la firma y el sello llegarán después (§70). Con la firma y el sello como mapas dentro del mapa exterior, uno mal formado dejaría a los dos sin comprobar, y un límite de tamaño de la clave y la firma en ese schema, como los 8192 bytes de un borrador anterior del diseño, dejaría fuera algoritmos futuros en todos los lectores anteriores.
- Caso: un author-signature con alg 0 incumpliría el schema del mapa exterior, y un sello válido a su lado dejaría de evaluarse. SLH-DSA (FIPS 205) tiene firmas de 7856 bytes en SLH-DSA-SHA2-128s y SLH-DSA-SHAKE-128s, y de 16 224 a 49 856 en sus otras diez variantes: con un límite de 8192 bytes, solo esas dos cabrían.
- Pruebas previstas: format3_security_v2, format3_signature_unsupported, format3_seal_unsupported y security.json.
Head (§29.4, §58.1, §62.1 reglas 14 y 17).
- Cambio: el head de versión 1, siempre en formato 3, con una sal, un comentario y un autor declarado opcionales y, por fichero, la ruta, size, start, end, el SHA-256 y la mtime opcional. Sus límites quedan fijados con el formato.
- Motivo: los datos que el formato 2 deja fuera. La versión propia del head solo es una defensa: por §22, una versión nueva exige un formato nuevo.
- Caso: el del cambio 1. Con una versión nueva del head dentro del formato 3, un lector de esta versión pediría el release y fallaría en el paso 17, que es lo que §22 prohíbe.
- Pruebas previstas: format3_single, format3_tree, format3_comment_only y head_schema.json.
Rutas (§7.3, §29.5, §29.5.1).
- Cambio: las reglas R1 a R10, con tablas propias de WindowsBestFit y de Unicode 18.0.0, la versión vigente al congelar el formato, publicada el 16-09-2026.
- Motivo: cualquiera puede fabricar una cápsula (§36.1). Sus rutas no deben escapar de la carpeta del lector, ni confundirse, ni colisionar al extraerlas.
- Caso: comprobado en la máquina de desarrollo, en NTFS, «ABCDEF~1» resuelve a «ABCDEFGHIJ» (R6b). HFS+ ignora ZWNJ y ZWJ al comparar nombres, como recoge la lista de core.protectHFS de git (R3, R4 y R7). En Node 24.9, "～" < "\u{1F600}" es falso, y en UTF-8 U+FF5E va antes (R8). Go 1.26.8 trae Unicode 15.0.0 y Node 24.9 el 16.0, así que sus funciones de Unicode no coinciden (§29.5.1). 127 veces «ΐ» (U+0390) miden 254 bytes y 381 unidades UTF-16 tras NFD (R3). En WindowsBestFit, bestfit1250 lleva U+00BF («¿») a 0x3F, y bestfit874 lleva U+2665 («♥») a 0x03 y U+00A7 («§») a 0x15: si R6c rechazara cualquier carácter ASCII de R4 en una proyección, esas rutas no se podrían guardar.
- Pruebas previstas: paths.json, path_fold.json y las mutaciones de rutas de §64.
Texto (§29.6).
- Cambio: los caracteres prohibidos en el comentario y en el autor declarado.
- Motivo: los dos se muestran junto a los veredictos.
- Caso: un comentario con U+202E invierte el orden visual de lo que le sigue, y uno con ESC puede mover el cursor de un terminal.
- Pruebas previstas: head_schema.json y las mutaciones de texto de §64.
Veredictos y presentación (§29.7).
- Cambio: los veredictos X, F0, F1, S0, S1 y S2, con su texto. Primero se muestran los veredictos y después el autor y el comentario, marcados. En un terminal, cada línea visual del creador lleva un prefijo, y los veredictos se repiten al final.
- Motivo: un creador no debe poder hacer pasar su texto por un veredicto.
- Caso: una línea de comentario más ancha que el terminal, partida por él, mostraría su resto sin prefijo. U+2502 ocupa 2 columnas en un terminal CJK.
- Pruebas previstas: las de presentación de la CLI de la referencia.
Paso 17 del formato 3 (§63 pasos 17 y 18, §69, §69.1).
- Cambio: los subpasos 17.1 a 17.8. Un fallo de age prevalece; después decide el primer subpaso que falla. Un lector solo para antes de EOF con ERR_INTEGRITY, y solo cuando ese es ya el código final. Código nuevo, ERR_HEAD_INVALID.
- Motivo: si decidiera el momento de la detección, dos lectores correctos darían códigos distintos.
- Caso: con el fichero cortado justo después de un chunk completo, filippo.io/age 1.3.2 lo entrega como no final y después devuelve ErrUnexpectedEOF (stream.go:117-156), y age-encryption 0.3.1 lo retiene y, en flush, lo prueba como final y falla sin entregarlo. Con una ruta «..» en ese chunk, el lector en Go vería antes el head, y el de TypeScript, el fallo de STREAM. Además, filippo.io/age detecta unos datos tras el chunk final al leerlo, pero devuelve el error en la lectura siguiente: un lector que leyera exactamente P bytes no lo vería.
- Pruebas previstas: los ejemplos de §69.1 y las mutaciones de precedencia de §64, con una ruta «..» y el corte exacto tras el chunk completo que la contiene.
Entrega de varios ficheros (§56).
- Cambio: nada se presenta antes del paso 18. Un lector que escribe los ficheros lo hace en un lugar temporal, dentro de un directorio nuevo, sin seguir enlaces ni sobrescribir. Un ZIP lleva las rutas del head en UTF-8.
- Motivo: extraer una cápsula no debe escribir fuera de su carpeta ni dejar los ficheros de una cápsula inválida.
- Caso: en POSIX, os.Rename de un directorio temporal sobre un destino vacío que ya existe lo sustituye, así que el lector reclama primero su directorio con os.Mkdir, que falla si existe.
- Pruebas previstas: la CLI de la referencia nunca escribe fuera de su directorio, con las rutas de paths.json.
Privacidad (§4, §55.1, §55.2).
- Cambio: antes de la fecha, el formato 3 oculta las rutas, los tamaños, los hashes, las fechas, el comentario y el autor, y el número de ficheros salvo la cota que da P.
- Motivo: son los metadatos nuevos del formato 3.
- Caso: con el área de 512 bytes y P = 768 caben como mucho 4 ficheros, de nombre de un byte y vacíos: n ≤ (P − 579)/45.
- Pruebas previstas: las de los cambios 2 y 4.
Reglas del escritor (§61, §62, §62.1 reglas 1, 6 y 13 a 18).
- Cambio: escribir el formato 3; el área y security siempre; el head con una sal nueva; las rutas y el texto válidos; la mtime omitida si no está en su rango; la autodecodificación de los tres CBOR como MUST; y los ficheros iguales en las dos pasadas.
- Motivo: un head que el lector rechaza solo se descubre tras la fecha, y un fichero que cambia mientras se cifra daría un SHA-256 que no le corresponde.
- Caso: el lastModified de un File del navegador y ModTime().Unix() en Go pueden ser negativos, para una fecha anterior a 1970, y el schema del head solo admite enteros sin signo.
- Pruebas previstas: las del escritor de la referencia y de datekeys-ts.
Invisibles (§29.5 R4b, §29.5.1, §29.6).
- Cambio: ningún texto del creador, sean rutas, comentario o autor declarado, lleva puntos de Default_Ignorable_Code_Point salvo ZWJ, ZWNJ, VS15 y VS16, y estos solo donde su uso es conforme: VS15 y VS16 tras un carácter que los admite según emoji-variation-sequences.txt, y ZWJ y ZWNJ nunca al principio ni al final, ni dos seguidos.
- Motivo: Unicode 18.0.0 aclara qué usos de los selectores de variante son conformes y advierte de que sus secuencias invisibles sirven para atacar aplicaciones de IA. Un comentario o un nombre con texto oculto se vería normal en pantalla, y lo leería un modelo al que se pasara la cápsula abierta.
- Caso: cada etiqueta de U+E0020 a U+E007E es un carácter ASCII invisible: «Hola» seguida de U+E0049, U+E0047, U+E004E, U+E004F, U+E0052 y U+E0041 se muestra como «Hola» y lleva escrito IGNORA. Cada selector de VS1 a VS256 detrás de un emoji codifica un byte que tampoco se ve. El borrador anterior admitía los dos en el comentario, y en las rutas admitía secuencias de ZWJ, ZWNJ, VS15 y VS16 de cualquier longitud.
- Pruebas previstas: las mutaciones de invisibles de §64 y los vectores de paths.json y head_schema.json.

ERR_HEAD_INVALID es el único código nuevo (§69).

Ningún objeto de formato 1 ni de formato 2 cambia de veredicto ni de código, salvo que VERSION 3 deja de dar ERR_UNSUPPORTED_VERSION en el paso 2. Producen VERSION 3 solo dos de los 125 casos de mutations.json, «version changed» y «format 2: version changed», y ninguno de los 4 380 de inspect_differential.json. Cambian estos datos de prueba:

las mutaciones «version changed» y «format 2: version changed» pasan a VERSION 4 ([4,1,"04"]). La segunda es también la entrada «VERSION 3» de la lista del formato 2 de §64, que pasa a «VERSION 4», y se añade time_only de formato 2 con VERSION 3, que falla en el paso 14;
las 33 mutaciones de las dos primeras listas de §64 se aplican también a fixtures de formato 3, y se añade la lista del formato 3;
en cbor.json, los vectores de formato 1 «key 6, defined only in schema version 2» y «keys 6 and 7 of schema version 2» conservan su veredicto, pero su nombre deja de ser exacto: las claves 6 y 7 existen también en la versión 3;
el campo spec de los ficheros de testdata y de los registros de los fixtures pasa a «0.10»;
testdata/README.md, que dice que format vale 1 o 2, que un escritor solo produce el formato 2, que cbor.json cubre CONTROL_CBOR en los dos formatos y que §64 tiene 88 mutaciones, y que pone como ejemplo [[4, 1, "03"]] y «VERSION 1 or 2» en su tabla de pasos;
los fixtures de formato 2 pasan a ser casos de compatibilidad (§67, §70);
en las implementaciones, las pruebas que esperan VERSION 3 rechazada en el paso 2 (framing.test.ts, inspect.test.ts y prefix.test.ts), las que tratan el formato 3 como un error del llamador en EncodeControl y DecodeControl (framing_test.go), el texto del paso 2 de /inspect, que dice que VERSION vale 1 o 2 (format.ts), y las del escritor que esperan el formato 2 (encrypt.test.ts, encrypt_test.go y format2_test.go).

77. Referencias

drand Protocol Specification
https://docs.drand.love/docs/specification/
drand/tlock
https://github.com/drand/tlock
drand/kyber — paquete encrypt/ibe, que tlock importa: H2, H3 y H4 del IBE-CCA; el pairing y la serialización de GT son los de drand/kyber-bls12381, sobre kilic/bls12-381
https://github.com/drand/kyber
age specification — C2SP
https://github.com/C2SP/C2SP/blob/main/age.md
BLS12-381 serialization — zkcrypto bls12_381, formato de ZCash
https://docs.rs/bls12_381/latest/bls12_381/notes/serialization/index.html
K. Nikitin, L. Barman, W. Lueks, M. Underwood, J.-P. Hubaux, B. Ford — «Reducing Metadata Leakage from Encrypted Files and Communication with PURBs», Proceedings on Privacy Enhancing Technologies 2019(4), pp. 6–33: función de relleno Padmé (§29.1)
https://doi.org/10.2478/popets-2019-0056
The Unicode Standard, Version 18.0.0 — Unicode Character Database: UnicodeData.txt, DerivedCoreProperties.txt, CaseFolding.txt y emoji/emoji-variation-sequences.txt (§29.5.1)
https://www.unicode.org/Public/18.0.0/ucd/
UAX #15 — Unicode Normalization Forms: NFD (§29.5.1)
https://www.unicode.org/reports/tr15/
WindowsBestFit — tablas best-fit de Windows, en unicode.org (§29.5.1)
https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/
Microsoft — «Naming Files, Paths, and Namespaces»: nombres reservados y alias 8.3 (§29.5)
https://learn.microsoft.com/windows/win32/fileio/naming-a-file
PKWARE — APPNOTE.TXT, .ZIP File Format Specification: bit 11, ZIP64 y campos extra (§56)
https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT
NIST FIPS 205 — Stateless Hash-Based Digital Signature Standard (SLH-DSA): tamaños de firma (§76)
RFC 7748 — X25519: codificación de u, recorte de escalares y puntos de orden bajo (§37)
RFC 8949 — CBOR
RFC 8610 — CDDL
RFC 8259 — JSON
RFC 4648 — Base64 y Base64URL
RFC 2119 / RFC 8174 — normative terminology

78. Principio final

DateKey define cuándo.

DateKeyCap protege qué.

.dkk transporta la capacidad adicional de acceso cuando la política la exige.

DateKeys facilita, registra y acelera; el cliente verifica.

228 KiB Raw Blame History Unescape Escape

DateKeys Protocol Specification

DateKey, DateKeyCap (.dkc) y DateKeys Access Key (.dkk)

Borrador normativo v0.10

1. Alcance

2. Terminología normativa

3. Principio rector

4. Objetivos de seguridad

5. No objetivos

6. Fuera de alcance

7. Modelo de amenazas

7.1 Servidor DateKeys

7.2 Relay / MITM / DNS

7.3 Poseedor de .dkc

7.4 Poseedor de .dkk

7.5 Cadena de suministro

7.6 Provider comprometido

7.7 Adversario cuántico futuro

7.8 Dispositivo del creador

8. Objetos del protocolo

9. Provider abstraction

10. Provider Profile

11. Codificación canónica del Provider Profile

12. Quicknet Provider Profile V1

12.1 Validación de un Provider Profile

12.2 Codificación canónica de un punto

13. Root of trust

14. DateKey

15. Resolución Quicknet fecha → ronda

16. Vector normativo de ronda

17. Ataque de ronda pasada

18. Representación dk1_

19. Canonicalidad dk1_

20. Extensiones de archivo

21. capsule_id

22. Framing .dkc V1

23. PRELUDE

24. PUBLIC_HEADER

25. Política de acceso declarada

26. Header binding

27. Validación pre-unlock

28. Tres ficheros age

28.1 Formato de los ficheros age

29. PAYLOAD_AGE

29.1 Relleno del payload

29.2 Contenido del formato 3

29.3 security

29.4 Head

29.5 Rutas

29.5.1 Tablas

29.6 Texto

29.7 Veredictos y presentación

30. Por qué PAYLOAD_AGE es un fichero age completo

30.1 Binding CONTROL_CBOR ↔ PAYLOAD_AGE

31. CONTROL_CBOR

32. Política time_only

33. Política time_and_key

34. SEALED_CONTROL

35. tlock strict mode

36. Comprobación política ↔ estructura

Si access_policy = time_only

Si access_policy = time_and_key

36.1 Semántica de autenticidad

37. X25519 recipient V1

38. Portable Access Key

39. Recipients de INNER_ACCESS_AGE

40. Framing .dkk V1

41. .dkk BODY_CBOR

42. credential_id

43. verification_metadata

44. Extensiones de aplicación en .dkk

45. Release API

46. Release Queue

47. Release Cache

48. Multi-relay

49. Recuperación directa contra el proveedor

50. Dependencia del histórico de releases

51. Verificación de release Quicknet

52. DNS / MITM

53. Harvest now, decrypt later

228 KiB

Raw Blame History Unescape Escape

DateKey, DateKeyCap (`.dkc`) y DateKeys Access Key (`.dkk`)

7.3 Poseedor de `.dkc`

7.4 Poseedor de `.dkk`

18. Representación `dk1_`

19. Canonicalidad `dk1_`

21. `capsule_id`

22. Framing `.dkc` V1

28. Tres ficheros `age`

28.1 Formato de los ficheros `age`

29.3 `security`

30.1 Binding `CONTROL_CBOR` ↔ `PAYLOAD_AGE`

32. Política `time_only`

33. Política `time_and_key`

34. `SEALED_CONTROL`

Si `access_policy = time_only`

Si `access_policy = time_and_key`

39. Recipients de `INNER_ACCESS_AGE`

40. Framing `.dkk` V1

41. `.dkk` BODY_CBOR

42. `credential_id`

43. `verification_metadata`

44. Extensiones de aplicación en `.dkk`

Visible para quien tenga el `.dkc`, antes y después de la fecha

Fuera del `.dkc`

61. Flujo de cifrado `time_only`

62. Flujo de cifrado `time_and_key`

66. Test vectors `dk1_`

67. Test vectors `.dkc`

68. Test vectors `.dkk`