## DateKey, DateKeyCap (`.dkc`) y DateKeys Access Key (`.dkk`)
### Borrador normativo v0.9
**Estado:** Draft / pre-estándar
**Fecha:** 29 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 y 2 de `.dkc` y su compatibilidad;
- huecos fijos de `INNER_ACCESS_AGE` y relleno del payload;
- 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:
1.**Confidencialidad temporal**
Bajo los supuestos del proveedor, una condición temporal no debe poder satisfacerse antes del momento elegido.
2.**Confidencialidad frente al operador**
DateKeys no debe necesitar conocer el plaintext ni la credencial final de acceso.
3.**Verificabilidad local**
El SDK debe detectar condiciones, perfiles y releases manipulados.
4.**Integridad**
Alteraciones del framing, cabecera, control o payload deben provocar fallo.
5.**Interoperabilidad**
Implementaciones independientes deben producir y consumir objetos compatibles.
6.**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.
7.**Extensibilidad**
Nuevos proveedores y extensiones no deben redefinir objetos antiguos.
8.**Privacidad de metadatos**
Antes de la fecha, una cápsula de formato 2 no debe revelar la longitud exacta de su contenido ni el número de credenciales que la abren (§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.
---
## 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.
### 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
```text
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:
```text
provider
profile
condition
```
Ejemplo Quicknet:
```json
{
"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:
```text
0 → "datekeys-provider-profile"
1 → 1
2 → "datekeys:quicknet:v1"
3 → "drand"
4 → "quicknet"
5 → <32-bytechainhash>
6 → <publickeybytes>
7 → 3
8 → 1692803367
9 → "bls-unchained-g1-rfc9380"
10 → <genesisseedbytes>
```
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:
```text
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.
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):
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`.
2.**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.
3.**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:
```text
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.
4.**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.
```text
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:
```text
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:
```text
round_time(r) =
genesis_time + (r - 1) * period
```
El SDK MUST elegir la primera ronda cuyo:
```text
round_time >= requested_unlock_at
```
Algoritmo:
```text
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:
```text
genesis_time = 1692803367
period = 3
requested_unlock_at = 2030-01-01T00:00:00Z
```
resultado:
```text
round = 66884212
round_time = 2030-01-01T00:00:00Z
```
La ronda:
```text
66432123
```
corresponde a:
```text
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:
```text
received_round == locally_resolved_round
```
y:
```text
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`.
`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:
```text
dk1_<base64url(JSON_CANONICO)>
```
sin padding.
---
## 19. Canonicalidad `dk1_`
Existe una única cadena válida para una DateKey V1.
El parser MUST:
1. Base64URL-decodificar.
2. Parsear JSON.
3. Validar campos.
4. Reemitir el JSON canónico exactamente.
5. Recrear `dk1_...`.
6. Comparar byte a byte con la entrada.
Si no coincide:
```text
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
```text
.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:
```text
16 random bytes
```
generados por un CSPRNG. §24 y `datekeys.cddl` fijan esa longitud (§57).
---
## 22. Framing `.dkc` V1
V1 fija el siguiente prelude:
```text
offset size field
0 4 MAGIC = "DKC1"
4 1 VERSION = 1 o 2 (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 dos 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) |
El formato 1 es el de la v0.8.2; el formato 2, el de esta versión. `PUBLIC_HEADER` y la `.dkk` tienen la versión de schema 1 en los dos formatos (§24, §41).
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), 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.
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:
```text
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):
1. menos de 4 bytes, o `MAGIC` distinto de `DKC1` → `ERR_INVALID_MAGIC` (paso 1);
2.`DKC1` seguido de menos de 12 bytes, un PRELUDE truncado → `ERR_INTEGRITY` (paso 1);
3.`VERSION` distinto de 1 y de 2 → `ERR_UNSUPPORTED_VERSION` (paso 2);
4.`FLAGS` o `RESERVED` distintos de 0 → `ERR_INVALID_FLAGS` (paso 2);
5.`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, antes de cualquier petición de red (§70).
---
## 24. PUBLIC_HEADER
V1 almacena la cabecera directamente como **Deterministic CBOR**.
Schema:
```text
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 dos formatos, con la versión de schema 1. No contiene nada del relleno ni del número de credenciales (§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:
```text
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:
```text
ERR_POLICY_STRUCTURE_MISMATCH
```
---
## 26. Header binding
`CONTROL_CBOR` MUST contener:
```text
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 o 2);
- 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:
```text
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:
```text
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:
```text
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 formato 2 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).
---
## 29. PAYLOAD_AGE
El contenido del usuario se cifra como un **fichero age v1 estándar completo**.
Durante la creación se genera:
```text
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.
`PAYLOAD_AGE` MUST contener exactamente un stanza, de tipo X25519, para `R_PAYLOAD`.
`age` genera internamente:
```text
FK_PAYLOAD = 16 random bytes
```
y la protege para `R_PAYLOAD`.
`I_PAYLOAD` se almacena dentro de `CONTROL_CBOR`; en formato 2, también L y el código de la regla de relleno (§31).
---
## 29.1 Relleno del payload
En formato 2 el plaintext de `PAYLOAD_AGE` es el contenido seguido de ceros:
```text
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:
```text
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).
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).
---
## 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:
```text
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 formato 2 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).
---
## 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:
```text
0 → "datekeys-control"
1 → versión de schema: 1 en formato 1, 2 en formato 2
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)
- 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 y 2 en formato 2. 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 dos versiones;
- las claves 6 y 7 MUST existir en la versión 2 y MUST NOT existir en la versión 1;
-`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 sin extensiones mide 103 bytes:
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:
```text
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:
```text
CONTROL_CBOR
↓
OUTER_TIME_AGE
```
donde:
```text
OUTER_TIME_AGE =
age file
recipient = tlock(DateKey)
plaintext = CONTROL_CBOR
```
`OUTER_TIME_AGE` MUST contener exactamente un stanza, de tipo tlock.
`age` genera:
```text
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:
```text
CONTROL_CBOR
↓
INNER_ACCESS_AGE
↓
OUTER_TIME_AGE
```
Primero:
```text
INNER_ACCESS_AGE =
age file
recipients = X25519: en formato 2, 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 formato 2 (§39).
`age` genera:
```text
FK_ACCESS = 16 random bytes
```
Después:
```text
OUTER_TIME_AGE =
age file
recipient = tlock(DateKey)
plaintext = exact bytes of INNER_ACCESS_AGE
```
`age` genera:
```text
FK_TIME = 16 random bytes
```
La política implementa:
```text
TIME AND KEY
```
No dos envolturas paralelas.
---
## 34. `SEALED_CONTROL`
En `.dkc`:
```text
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 formato 2 (§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 formato 2 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:
```text
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.
---
## 37. X25519 recipient V1
V1 adopta el recipient X25519 estándar de `age`.
Una identity X25519:
```text
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:
```text
I_ACCESS = 32 random bytes
R_ACCESS = corresponding X25519 recipient
```
`R_ACCESS` se usa como recipient de `INNER_ACCESS_AGE`. En formato 2 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 formato 2:
-`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 los dos formatos todos los stanzas envuelven la misma:
```text
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 el formato 2 oculta y lo que impide comprobar.
---
## 40. Framing `.dkk` V1
```text
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:
```text
FLAGS == 0
RESERVED == 0
1 <= BODY_LEN <= 16777216 (16 MiB)
```
La `.dkk` conserva `VERSION` 1 con los dos 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):
1. menos de 4 bytes, o `MAGIC` distinto de `DKK1` → `ERR_INVALID_MAGIC`;
2.`DKK1` seguido de menos de 8 bytes, un prelude truncado → `ERR_INTEGRITY`;
3.`VERSION` distinto de 1 → `ERR_UNSUPPORTED_VERSION`;
4.`FLAGS` o `RESERVED` distintos de 0 → `ERR_INVALID_FLAGS`;
5.`BODY_LEN` fuera de su rango; una longitud 0 queda fuera, como en §22 → `ERR_INTEGRITY`;
6. 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:
```text
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:
```text
access_type = "x25519"
access_material = 32 raw identity bytes
```
---
## 42. `credential_id`
Debe ser:
```text
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:
```text
0 → capsule_digest
```
donde:
```text
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:
```text
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:
```text
GET /v1/releases/{profile}/{condition}
```
Ejemplo Quicknet:
```text
GET /v1/releases/datekeys:quicknet:v1/66884212
```
No requiere `capsule_id`.
---
## 46. Release Queue
La unidad de trabajo es:
```text
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:
```text
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:
```text
.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:
```text
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:
```text
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` y `.dkk` pueden incluir extensiones mediante el mismo mecanismo.
Cada extensión declara:
```text
0 → extension_id
1 → extension_version
2 → data (opcional)
```
El par:
```text
(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:
```text
critical
```
o:
```text
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` y `.dkk` 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 formato 2, 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). |
| 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 el formato 2; 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 (§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;
- 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 `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. 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.
- En formato 1, quien esperaba n recipients podía contar los stanzas. En formato 2 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);
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.
Encoders y decoders MUST aplicar estos límites de trama:
```text
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 formato 2 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.
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 formato 2 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`, `BODY_LEN`) 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);
- 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.
- 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.
---
## 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:
```text
{}
[]
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 versión 2 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).
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
```go
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 2. Un escritor MAY seguir otro que produzca un objeto equivalente y cumpla §62.1.
```text
1. Validar las opciones (§62.1): ninguna credencial; instante pedido
posterior al reloj del escritor; L conocida y como mucho L_MAX;
código de relleno 1 o 2; extensiones conformes a §54 y §72.
2. Resolver DateKey localmente (§15).
3. Generar capsule_id (CSPRNG, §21).
4. Generar I_PAYLOAD X25519 nueva (CSPRNG, §29).
5. Construir PUBLIC_HEADER (versión de schema 1).
6. Medir SEALED_CONTROL_LEN (§62.1): la longitud del OUTER_TIME_AGE
del paso 10 con un CONTROL_CBOR de 103 bytes más sus extensiones.
Más de 64 MiB → error (§57).
7. Construir PRELUDE: VERSION = 2 y las longitudes de los pasos 5 y 6.
1.**Formato.** Escribir el formato 2: `VERSION` = 2 (§22) y `CONTROL_CBOR` de versión 2 (§31). MUST NOT escribir el formato 1; solo un generador de vectores de prueba MAY hacerlo (§70).
2.**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.
3.**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.
4.**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).
5.**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).
6.**Contenido.** Conocer L antes de sellar `CONTROL_CBOR`, con L ≤ L_MAX, y usar el código 1 o 2 (§29.1). 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.
7.**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 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.
8.**Límites.** Respetar los límites de §57 y las reglas de extensiones de §54 y §72.
9.**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:
10.**Código por defecto.** El SDK oficial SHOULD usar el código 2.
11.**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.
12.**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).
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 formato 2):
```text
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
```text
1. Parsear DKC1: MAGIC y PRELUDE completo (§23).
2. Validar PRELUDE: version, que es el formato (1 o 2), 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
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 formato 2 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 formato 2;
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
la versión 2 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 formato 2, 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 formato 2, 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
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.
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).
```
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 formato 2, 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).
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:
```text
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:
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 dos formatos: el corpus oficial las aplica a fixtures de formato 2 y conserva las de formato 1 como casos de compatibilidad (§70).
Antes de v1.0 deben fallar, como mínimo:
```text
PUBLIC_HEADER_A + SEALED_CONTROL_B
SEALED_CONTROL_A + PAYLOAD_AGE_B
DateKey A + release de round B
chain hash cambiado
version cambiada a 3
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):
```text
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³⁸¹.Lafirmanegadaesunacodificacióncanónicaquenoverifica;juntoaunUconc0+p,fijaqueelpaso10terminaantesdequeelpaso11leaU.
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:
```text
VERSION 3 ERR_UNSUPPORTED_VERSION, paso 2
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
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.
- timestamp con fracción de segundo inmediatamente posterior a una frontera de ronda;
- fecha 2030-01-01;
- fechas próximas al genesis.
Cada vector:
```text
requested timestamp
expected round
effective timestamp
```
---
## 66. Test vectors `dk1_`
Cada vector:
```text
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 o 2);
- en formato 2: 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`.
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 formato 2 cubren, como mínimo:
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 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. 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
```text
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
```
---
## 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`— se valida en cuatro capas, en este orden:
1.**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 o 2, 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`.
2.**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` y la `.dkk` 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.
3.**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 `CONTROL_CBOR` las reglas de las claves 6 y 7 —presentes en la versión 2 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.
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.
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 formato 2, 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). 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.
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 |
---
## 70. Compatibilidad
Una implementación V1:
- MUST aceptar `DKC1` con `VERSION` 1 o 2, 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);
- 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;
- si escribe cápsulas, MUST escribir el formato 2 y MUST NOT escribir el formato 1 (§62.1); solo un generador de vectores de prueba MAY escribir el formato 1;
- 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.
`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. 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`) 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 sus dos 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.9
```text
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)
o 2 (v0.9); se escribe solo el 2
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 formato 2, su plaintext es el
contenido seguido de ceros hasta P = regla(L)
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 formato 2,
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 y .dkk
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
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 versión 2,
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 o 2; la versión de schema de CONTROL_CBOR es la del
formato; PUBLIC_HEADER y .dkk, versión 1 en los dos; un lector v0.9
abre el formato 1 con la semántica de la v0.8.2; un lector v0.8.2
rechaza el formato 2 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 y los recipients
writer rules
= §62.1: MUST para formato, credenciales, señuelos, aleatoriedad, L,
SEALED_CONTROL_LEN y errores; SHOULD para autocomprobación y borrado
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 y 2 (§22), los 16 huecos de `INNER_ACCESS_AGE` (§39) ni las reglas de relleno 1 y 2 (§29.1). 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) y L_MAX (§29.1) no son límites de implementación: son normativos y no figuran en esta tabla.
### Trabajo futuro
Quedan fuera de la v0.9, 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;
- 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
1. Schemas CBOR congelados.
2.`profile_hash` vector oficial.
3. Quicknet vectors oficiales.
4.`dk1_` vectors canónicos.
5. fixtures oficiales `.dkc` de descifrado/validación, de formato 2 y de compatibilidad de formato 1.
6. fixtures oficiales `.dkk` de parseo/uso.
7. mutation tests completos, en los dos formatos.
8. strict tlock tests.
9. parser fuzzing.
10. revisión criptográfica externa.
11. vectores de las reglas de relleno (§29.1).
---
## 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:
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`.
2.`extension.New(id, v, nil)` emitía `f6` (`null`) como `data`.
3. 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.
4. El fixture oficial `time_only_extensions` usaba claves de texto y `true` en `data`.
5.`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.
6. 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.
1.**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.
2.**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.
3.**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.
4.**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,yelpaso11nodefiníaelcuerpodelstanza.
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:
1.**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.
2.**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.
3.**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:
4.**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.
5.**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`.
6.**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`.
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.
1.**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.
2.**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.
3.**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.
- 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.
5.**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≤255yL =256;enP =65536,L =65536delresto.Con8bytesfijos,un`CONTROL_CBOR`deversión2sinextensionesmidesiempre103bytes.
6.**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.
7.**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.
8.**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.
- 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.
- 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.
11.**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»).
12.**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.
13.**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.
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;
- 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`.
- 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
- 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
- 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.**
