Resumen

  • El tag CBOR 601 identifica un conjunto de afirmaciones CWT sin protección propia; no aporta firma, MAC, cifrado ni identidad del emisor.
  • Para el uso RATS, el receptor debe autenticar al remitente y el canal debe proteger la integridad. La confidencialidad, la identidad del receptor y la repetición exigen controles explícitos.
  • Una vez extraído el UCCS, la protección del canal ya no acompaña al objeto. Si se reenvía, RFC 9781 lo trata como originado en el receptor.

El tercer consumidor nunca vio el primer canal

Pensemos en un dispositivo que envía afirmaciones a un verificador. El verificador acepta el mapa, lo publica en una cola y tres servicios lo consumen: uno calcula riesgo, otro conserva evidencia y un tercero decide si libera una clave. Todos ven los mismos bytes. Solo el primer proceso vio la sesión que les dio significado de procedencia.

UCCS fue diseñado para una economía legítima. Un CWT convencional se protege con COSE. Cuando dos roles ya comparten un canal apropiado, duplicar esa protección puede ser innecesario, especialmente en entornos con pocos recursos. RFC 9781 permite enviar el Claims Set sin envoltura COSE y marcarlo con #6.601.

La marca no es una credencial. Dice al decodificador qué estructura tiene delante. No identifica la conexión, no acredita al Attester y no convierte un campo iss en una firma. La entrada de IANA evita colisiones de significado; no certifica que una implementación haya establecido el canal exigido.

En la transmisión RATS, el receptor tiene que autenticar al remitente al crear el canal, y la comunicación debe conservar integridad. Si se necesita confidencialidad, también se autentica al receptor. Eso obliga a conservar algo más preciso que una bandera “seguro”: protocolo, versión, conjunto criptográfico, identidad validada, ancla de confianza, roles de las dos partes, intervalo de sesión y vínculo con los bytes recibidos.

La protección contra repetición tampoco aparece por nombrar el canal. El RFC señala el uso posible de un nonce. TLS 1.3 distingue entre datos 1-RTT y datos tempranos, con riesgos distintos. Por eso el recibo de frescura debe registrar el desafío, la ventana aceptada o el vínculo de sesión, además del resultado de autenticación.

Hay otro límite: las propias afirmaciones no pueden justificar las credenciales que autenticaron el canal que las transporta. Sería circular. La confianza en la identidad del extremo debe venir de una base independiente. Y aun con identidad correcta, el canal puede transportar una medición falsa si el entorno de atestación está comprometido.

Extraer significa asumir la procedencia

RFC 9781 dice que, cuando el UCCS emerge del canal y entra en el receptor, queda sometido a las propiedades de cualquier dato desprotegido en ese entorno. Si el receptor lo reenvía, se trata como si se hubiera originado allí.

Esta regla evita una ficción cómoda. El verificador que coloca el mapa en una cola ya no es solo mensajero. Decide qué copia conservar, si normaliza el CBOR, qué metadatos añade y qué destinatarios reciben el resultado. Es la nueva fuente operativa. El siguiente servicio debe evaluar su identidad y su protección, no una sesión anterior que nunca observó.

Una cadena robusta comienza con el hash exacto de los bytes en el límite de recepción. A continuación registra la sesión y la identidad que los entregó. La extracción añade el proceso y la versión del parser, el instante y cualquier transformación. El almacenamiento añade el escritor, la política de acceso, la clave de cifrado, la retención y la eliminación. El reenvío añade el nuevo emisor, el hash de entrada, la transformación, el canal o firma nuevos, la audiencia y el acuse.

Ningún recibo absorbe al siguiente. Cifrar la base de datos protege el repositorio, pero no firma retroactivamente el Claims Set. Conservar un hash detecta cambios, pero no demuestra quién vinculó ese hash a una sesión. Establecer un segundo canal autentica al servicio que reenvía, no al Attester original.

El ejemplo de atestación delegada muestra una salida válida. Un sub-Attester sin clave de firma transmite UCCS a un Attester principal por un enlace seguro. El principal calcula un hash y lo protege con su clave de Evidence, quizá mediante un digest de submódulo separado. La fuente cambia de forma explícita: el principal responde por la vinculación entre lo recibido y la Evidence que produce.

Un CWT completo no sigue esta lógica. Su envoltura COSE mantiene una evidencia propia de origen e integridad. El canal puede autenticar al par de transporte sin avalar al firmante del token. Confundir ambos casos elimina precisamente la razón de existir de UCCS.

Antes de decidir, separar las nueve pruebas

El inventario mínimo contiene formato y bytes, establecimiento del canal, identidad de extremos, frescura, extracción, custodia, reenvío, valoración y acción. El Verifier puede concluir que la Evidence es coherente con sus valores de referencia y su política. El Relying Party todavía decide si concede acceso, ejecuta una orden o libera un secreto.

La idea editorial de Heng Lu ayuda a mantener la proporción. El tag 601 y los requisitos del canal forman una capa común pequeña y verificable. La publicación del RFC es un hecho simbólico. La garantía solo aparece cuando sistemas en ejecución autentican, protegen, registran y conservan la transición de fuente. La decisión final debe seguir en manos de quien soporta su consecuencia.

Fuentes