Cuestiones abiertas

Label 309 v1 está congelado. El formato de transmisión bajo la etiqueta de metadatos 309, la codificación en CBOR canónico, los registros de algoritmos, el sobre de la PoE sellada y la construcción de la firma están resueltos: un verificador v1 conforme lee todos los registros v1, y un productor v1 conforme emite registros que todo verificador v1 acepta. Esta página no trata de cambiar eso. Es el inventario de lo que está confirmado en el estándar hoy y de lo que sigue siendo proyectado a futuro: construcciones criptográficas candidatas reservadas para una posible futura revisión, y el procedimiento disciplinado para cambiar una constante criptográfica cuando alguna de ellas se concrete.

Nada de lo aquí descrito es una hoja de ruta de producto. Cada entrada es una decisión técnica a nivel de protocolo: un identificador de algoritmo, una derivación, una política del verificador o una regla de versionado. Quien implemente el estándar necesita la mitad resuelta para construir una implementación v1 hoy, y la mitad proyectada a futuro para construirla de modo que un futuro sucesor poscuántico o basado únicamente en RFC sea una entrada aditiva en un registro de algoritmos, nunca una reescritura.

Construcciones resueltas

Estas decisiones están tomadas. Se exponen aquí sin rodeos porque son las decisiones estructurales que quien implementa quiere confirmar con mayor frecuencia en un solo lugar; las páginas enlazadas desarrollan la construcción completa.

El KEM poscuántico se incluye en v1

El KEM híbrido X-Wing (ML-KEM-768 compuesto con X25519) está registrado bajo el identificador mlkem768x25519 en el registro enc.kem desde la primera publicación. No es un candidato futuro: reside en enc.scheme: 1 junto al KEM clásico x25519, y el campo enc.kem presente en la transmisión selecciona el KEM por ranura, la forma de la ranura y la derivación de la clave de cifrado de clave por registro.

X-Wing se consume como una caja negra: la construcción usa únicamente su interfaz pública (encapsular, desencapsular y el secreto compartido de 32 bytes) y no formula ninguna suposición sobre el hashing interno del combinador. Ambos KEM derivan la KEK por ranura bajo una única forma de sal de hash etiquetado, SHA-256(label || enc.nonce || <material KEM de la ranura> || pub_R), calculada sobre los propios bytes en la transmisión de la ranura: en la ruta híbrida, SHA-256("cardano-poe-xwing-kek-salt-v1" || enc.nonce || kem_ct || pub_R). Hashear a unos 32 bytes fijos vincula el nonce del sobre, el texto cifrado y la clave pública del destinatario dentro de la KEK, a la vez que disuelve la ambigüedad del analizador que un texto cifrado poscuántico de longitud variable crearía con una sal de mera concatenación. Solo se expone la variante híbrida: ML-KEM puro se excluye deliberadamente para que el tramo X25519 preserve la seguridad clásica si ML-KEM-768 llegara a quebrarse. Véase PoE sellada y Registros de algoritmos.

El compromiso de clave sellada vincula la cabecera y la afirmación de hash

Ambas rutas selladas comprometen la clave de cifrado del contenido con una transcripción cerrada, serializada con la misma función de CBOR canónico que usa el resto del sobre, que fija los campos de cabecera y la afirmación de hash del texto plano del ítem (hashes_hash). En la ruta dirigida al destinatario (enc.slots), el compromiso está en la cadena: slots_mac es un HMAC con clave de la CEK sobre una transcripción que transporta los identificadores de scheme, path, AEAD y KEM, el nonce, el conjunto barajado de ranuras y hashes_hash, de modo que un intermediario no puede empalmar un texto cifrado sobre un conjunto de ranuras diferente ni sobre una afirmación de hash diferente sin que falle la comprobación del MAC en la cadena, antes de recuperar ningún texto cifrado. La ruta de frase de contraseña (enc.passphrase) transporta un compromiso equivalente en una cabecera de 32 bytes dentro del blob de texto cifrado, sobre una transcripción que añade el salt y los parámetros de Argon2id, de modo que manipular las entradas del KDF hace que la comprobación del compromiso falle. El contenido en sí se sella entonces en un STREAM segmentado bajo una clave de contenido derivada de la CEK; el AAD por segmento es vacío, porque cada campo de cabecera ya está vinculado a esa clave de forma transitiva. La construcción completa se encuentra en PoE sellada.

La profundidad de confirmación es política del verificador

Un registro queda anclado en el momento en que se incluye su transacción, pero un verificador que decide cuánta liquidación exigir antes de emitir un veredicto aplica un umbral de profundidad de confirmación. Label 309 convierte esto en una política del verificador, no en un MUST (DEBE) normativo. El estándar define la superficie legible por máquina (una transacción por debajo del umbral se reporta como pending (el código tipado INSUFFICIENT_CONFIRMATIONS), nunca como failed, y puede resolverse a valid al reintentar), mientras que el umbral en sí (RECOMENDADO ≥ 15 bloques) es una entrada configurada en la implementación, no una constante integrada en el formato de transmisión. Un verificador que exige una liquidación más profunda para afirmaciones de alto valor es plenamente conforme. Véase Verificación.

La verificación de Ed25519 es estricta

Las firmas a nivel de registro DEBEN verificarse bajo las reglas estrictas de RFC 8032 §5.1.7, no bajo la tolerancia de verificación por lotes más permisiva de ZIP-215. La verificación estricta rechaza codificaciones no canónicas y puntos de orden pequeño que un verificador tolerante aceptaría, de modo que dos verificadores conformes siempre alcanzan el mismo veredicto sobre la misma firma. Los implementadores deben confirmar que su biblioteca Ed25519 se encuentra en modo estricto; algunas bibliotecas adoptan la variante tolerante por defecto. Véase Firmas.

El CBOR canónico es el contrato de determinismo

Cada registro se codifica como CBOR canónico conforme a RFC 8949 §4.2.1: formas enteras preferidas, arrays y mapas de longitud definida, claves de mapa ordenadas en orden lexicográfico byte a byte, sin claves duplicadas, sin etiquetas. El determinismo es lo que permite que una firma calculada sobre el cuerpo por una implementación se verifique bajo otra, y lo que permite que dos productores del mismo registro lógico emitan bytes idénticos. Esto es innegociable en toda implementación conforme y constituye el fundamento del contrato de paridad entre lenguajes.

Candidatos proyectados a futuro

Los elementos siguientes son candidatos, no construcciones publicadas. Ninguno es un defecto de v1; ninguno está comprometido. Se registran para que una implementación construida hoy deje espacio para ellos como entradas de registro aditivas, y para que un revisor futuro pueda ver qué evoluciones anticipa ya el diseño ágil en algoritmos.

Un perfil alternativo de AEAD de contenido reservado

La capa de contenido de la PoE sellada en v1 es chacha20-poly1305-stream64k (ChaCha20-Poly1305 de RFC 8439 en la disposición STREAM segmentada), que está respaldada por un RFC, así que no hay ninguna cuestión abierta sobre el estatus formal del cifrado de contenido actual. Lo que queda reservado es una vía hacia un AEAD de contenido distinto si algún contexto de despliegue llegara a requerir uno. El identificador aes-256-gcm (NIST SP 800-38D) queda reservado en el registro de AEAD para ese fin y no forma parte de enc.scheme: 1: un registro que lo nombre hoy sigue la regla del sobre desconocido.

Introducirlo sería una futura construcción enc.scheme: 2 que preserva los modelos existentes de slots[] + slots_mac y de compromiso por frase de contraseña, pero intercambia la capa de contenido, fijando el nuevo tamaño de segmento, la derivación de la clave de contenido, la construcción del nonce por segmento, el AAD por segmento y la autenticación del segmento final para ese cifrado. Se trata de un perfil de reserva, no de un reemplazo: los registros enc.scheme: 1 existentes siguen siendo válidos, y el perfil no debe implementarse antes de que exista una definición normativa de enc.scheme: 2 y sus vectores de prueba.

Algoritmos de firma poscuánticos reservados

El tramo KEM de la trayectoria poscuántica se incluye en v1 (véase arriba). El tramo de firma está reservado pero aún no implementado. Dos familias son candidatas para integrarse en el registro de firmas existente una vez que IETF COSE estabilice los identificadores de algoritmos poscuánticos:

Dado que el algoritmo de firma es un identificador con nombre en el encabezado protegido COSE, registrar un sucesor es puramente aditivo: los registros Ed25519 existentes continúan verificándose, y un verificador que no reconoce un nuevo algoritmo de firma emite una señal de algoritmo no compatible en lugar de rechazar la afirmación de contenido. Una firma no reconocida nunca invalida la Prueba de Existencia subyacente. Véase Firmas.

Una posible ruta de publicación v: 2

Las adiciones individuales (un nuevo KEM, un nuevo AEAD de contenido, un nuevo algoritmo de firma) son entradas de registro que no cambian el esquema del registro de nivel superior. Una adición de KEM en particular es una entrada de registro bajo enc.scheme: 1, no un incremento de esquema; un incremento de enc.scheme está reservado para un cambio de construcción entre KEM (un nuevo slots_mac o AEAD de contenido que se aplique a todos los KEM a la vez).

Si se acumulan suficientes candidatos que modifiquen el esquema del registro, el cambio acumulado puede justificar un registro v: 2 de nivel superior publicado junto a v1. Ambas versiones seguirían siendo esquemas de metadatos válidos bajo la etiqueta 309; un verificador selecciona por el discriminador v dentro del registro. Los pasos de estandarización se repiten para la nueva revisión. Esta es la evolución de mayor alcance y solo se activa por acumulación: aquí nada está planificado.

Resolución opcional de un único salto de sustitución

El campo opcional supersedes de un registro apunta a un registro anterior mediante el hash de transacción. Resolver ese puntero es opcional para un verificador. Un verificador que confirma que supersedes es estructuralmente un hash de 32 bytes pero no obtiene la transacción anterior es conforme, aunque pierde la oportunidad de mostrar la cadena de sustitución. Orientación: un verificador PUEDE resolver un único salto (volver a consultar el resolvedor de transacciones por el hash referenciado e informar de su existencia y del tiempo del bloque) sin descender más allá. Un salto es suficiente; el recorrido más profundo es responsabilidad de quien llama, y la sustitución nunca revoca el registro anterior, que la cadena mantiene verificable de forma autónoma para siempre.

Migración de una constante criptográfica

Toda construcción resuelta anteriormente depende de constantes con nombre: identificadores de algoritmos, cadenas de info de HKDF, sales de KDF, longitudes de nonce de AEAD, etiquetas de separación de dominio. Cambiar el significado de cualquiera de ellas es una ruptura del formato de transmisión, y el estándar prescribe exactamente un camino disciplinado para ello. La regla rectora: utilícese el cambio de menor alcance que resuelva el problema y nunca se cambie en silencio el significado de una constante existente bajo el mismo espacio de nombres.

El procedimiento es aditivo y compatible con versiones anteriores (los registros antiguos continúan verificándose bajo las constantes con las que fueron publicados) y avanza por alcance:

1. Versionar el espacio de nombres, no el valor. Una derivación modificada incrementa el sufijo -vN en cada cadena de separación de dominio que toca: cadenas de info de HKDF (…-v1 → …-v2), prefijos de mensaje HMAC, sales y etiquetas. Una nueva constante reside bajo el nuevo sufijo; la constante anterior permanece válida bajo el sufijo antiguo. Los verificadores más antiguos rechazan los registros más nuevos de forma limpia en el discriminador en lugar de interpretarlos incorrectamente.

2. Incrementar el discriminador que corresponde al radio de impacto. Un cambio confinado a una familia de ranuras se selecciona mediante enc.kem; un cambio entre KEM en la capa de contenido o el compromiso del conjunto de ranuras es un incremento de enc.scheme; un cambio al esquema del registro en sí es un incremento de v de nivel superior. Cada discriminador circunscribe la ruptura a la capa mínima que efectivamente cambió.

3. Mantener verificables las versiones anteriores. Las versiones de registro más antiguas permanecen legibles como esquemas congelados. Un verificador selecciona la construcción por los propios discriminadores de versión del registro, de modo que una única implementación puede verificar v1 y un futuro sucesor en paralelo. Ningún registro deja de verificarse porque se haya publicado un sucesor.

Páginas relacionadas

• Registros de algoritmos: los identificadores con nombre cuyos espacios de nombres se versionan en una migración.
• PoE sellada: el KEM híbrido X-Wing, la vinculación con la transcripción de compromiso de clave y los discriminadores enc.scheme / enc.kem.
• Firmas: la verificación estricta de Ed25519 y el registro de firmas al que se incorporarían los algoritmos poscuánticos reservados.