Resumen

  • RFC 9597 registra una sola caja de afirmaciones CWT, la etiqueta 15, dentro de los encabezados COSE para usos con cifrado, firma separada o cargas que no son CWT.
  • Un emisor visible puede orientar una búsqueda de clave, pero no debe fijar identidad, autorización ni estado permanente antes de la comprobación criptográfica.
  • Si una afirmación aparece en el encabezado y en la carga, las copias deben coincidir salvo una regla explícita; incluso entonces, igualdad, verdad, privacidad y permiso siguen siendo preguntas diferentes.

El sistema de claves recibe una petición para un objeto que todavía no puede leer. En el encabezado aparece un emisor. La plataforma abre el índice correcto, encuentra candidatos y reserva un proceso para ese supuesto cliente. Después falla la firma.

¿Qué queda? Si el proceso desaparece, el cache no conserva el emisor y ninguna métrica lo cuenta como identidad confirmada, la decisión fue realmente provisional. Si el nombre ya abrió un espacio de cliente o contaminó un registro duradero, la verificación llegó demasiado tarde.

RFC 9597 no prohíbe usar datos tempranos. Define cómo transportar afirmaciones CWT en cualquier estructura COSE y exige que el uso anterior a la seguridad criptográfica sea confirmado después. La norma resuelve el formato; la arquitectura debe resolver la reversibilidad.

La etiqueta 15 evita mezclar dos registros

COSE y CWT asignan números compactos en espacios distintos. Copiar directamente cada clave CWT al encabezado produciría colisiones. Por eso RFC 9597 crea el parámetro “CWT Claims” con etiqueta 15: una sola entrada COSE cuyo valor es un mapa de afirmaciones.

El registro COSE de IANA identifica el contenedor; el registro CWT identifica sus claves. RFC 8392 define emisor, sujeto, audiencia, expiración, no-antes, emisión e identificador. RFC 8610 permite describir la forma en CDDL.

Nada de eso decide qué afirmaciones necesita un servicio. Tampoco prueba que la carga sea CWT, porque la caja puede acompañar una imagen, firmware u otro objeto firmado. El contrato local debe decir qué significa cada afirmación para ese endpoint y qué consecuencias están permitidas.

“Protegido” no significa “autorizado”

RFC 9052 separa encabezados protegidos y no protegidos. RFC 9597 recomienda usar la parte protegida y prohíbe duplicar el parámetro entre ambas. Un receptor serio no puede convertir esa recomendación en una suposición; debe decidir si rechaza el mapa no protegido o lo trata únicamente como pista no confiable.

La protección demuestra que ciertos bytes participaron en una operación criptográfica válida con una clave. Falta comprobar si la clave tenía competencia para declarar ese emisor, si la audiencia acepta al receptor, si la fecha sigue vigente y si la política permite la operación.

También hay que proteger la interpretación. RFC 9597 propone typ, definido en RFC 9596, cuando el contexto no basta. Así se separan las dos piezas: el tipo selecciona el contrato; el contrato procesa las afirmaciones. Un mapa firmado bajo un selector ambiguo puede seguir llevando al validador equivocado.

Una pista útil debe tener un techo operativo

La búsqueda de clave explica por qué el emisor aparece antes. Sin él, quizá no sea posible elegir con qué verificar. El error sería dejar que esa circularidad entregue privilegios.

Una afirmación sin verificar puede limitar una consulta a un catálogo, elegir una cola aislada o reservar un presupuesto pequeño. No debería crear definitivamente un tenant, abrir un parser ilimitado, elegir la cuenta de facturación, poblar un cache permanente ni ejecutar una acción externa.

El recibo temprano debe contener los bytes originales, la ubicación protegida o no, la afirmación exacta, la rama elegida, la consulta y sus candidatos. El recibo final añade resultado criptográfico, tipo y perfil, comparación con la carga, audiencia, vigencia, política, decisión y efecto. Si la validación falla, la plataforma debe demostrar que retiró la rama temprana.

La disciplina de código en ejecución aparece aquí: no basta con que un diagrama muestre una flecha de “revalidar”. Pruebas negativas y telemetría deben mostrar que un fallo tardío revoca caches, identidades y recursos provisionales.

Dos afirmaciones iguales cierran una confusión, no todas

RFC 7519 ya permitía replicar algunas afirmaciones JWT en encabezados JOSE. RFC 9597 exige que una afirmación CWT presente en encabezado y carga tenga el mismo valor, salvo una regla aplicativa específica.

La comparación evita que un proxy descubra claves para el emisor A mientras la aplicación consume el emisor B. Pero dos copias iguales pueden compartir el mismo error: estar caducadas, dirigidas a otra audiencia o firmadas por una clave no autorizada. RFC 8725 ayuda a recordar que la validación depende de reglas explícitas y mutuamente claras, no de una etiqueta familiar.

Una excepción a la igualdad necesita versión, alcance y dueño. Debe indicar qué copia usa cada componente y por qué la divergencia no divide la autoridad. Sin esa precisión, “regla especial” significa que nadie puede reconstruir la decisión.

Lo que se ve antes ya no está cifrado

Mover una afirmación al encabezado expone información que quizá estaba protegida en la carga. Un emisor puede identificar una empresa; un sujeto, un dispositivo; una audiencia, el servicio objetivo; un identificador, una secuencia correlacionable. La observabilidad puede deshacer la confidencialidad sin romper ningún algoritmo.

La pregunta correcta es mínima: ¿qué único dato necesita la tarea temprana? Hay que enumerar observadores de red, proxies, colas, registros, trazas, caches y respuestas de error. La retención y la finalidad forman parte del control. Una firma válida no autoriza a copiar datos sensibles a todos esos lugares.

La carga separada necesita su propio vínculo

COSE permite contenido separado, pero RFC 9052 responsabiliza a la aplicación de transportarlo sin cambios. Un encabezado correcto no prueba que el verificador haya recuperado el archivo correcto ni que esa carga pertenezca a la transacción.

Conservar localizador, contexto de recuperación, bytes o hash y resultado de vínculo evita que una pista de emisor válida se una a otro contenido. La cadena final debe poder decir: esta afirmación fue visible; estos bytes y esta interpretación quedaron protegidos; la copia de carga cumplió la regla; la política local autorizó; la acción ocurrió.

Ese orden coincide con las tres ideas de Lu Heng: el código ejecutado prueba la adopción real; la especificación mínima y la decisión local mantienen la semántica fuera del registro común; y las capas de realidad impiden que visibilidad, integridad, aceptación y resultado se fusionen.

Fuentes