Resumen

  • RFC 9596 registra typ, etiqueta 16, para que una aplicación declare el tipo del objeto COSE completo sin confundirlo con el «content type» de la carga.
  • La biblioteca COSE no decide el significado de typ; lo entrega a la aplicación, que debe exigirlo, rechazar valores inesperados y asociar cada tipo con reglas de validación y autorización realmente distintas.

Un objeto firmado llega al borde de un servicio. La firma pasa. El encabezado protegido contiene el tipo exacto que la ruta esperaba. El despachador ya sabe qué manejador llamar, pero todavía no sabe si debería permitirle hacer algo.

Esa separación es el núcleo de RFC 9596. El estándar resuelve una carencia de COSE respecto de JOSE: incorpora una manera de nombrar la clase del objeto completo y reducir la confusión entre formatos. No convierte la etiqueta en una credencial. La implementación COSE la conserva y la pasa; la aplicación interpreta y decide.

El riesgo aparece cuando una organización transforma una señal de clasificación en una conclusión de confianza. El nombre del carril no prueba que el vehículo esté autorizado a circular por él.

El sobre y la carga no responden a la misma pregunta

RFC 9052 ya definía «content type». Ese campo indica el tipo de los datos situados en payload o ciphertext. RFC 9596 agrega typ para el objeto COSE entero. Son coordenadas distintas, aunque compartan la misma sintaxis de valores.

Una carga puede ser CBOR tanto dentro de un recibo como dentro de un resultado de atestación o una solicitud de control. El parser de la carga necesita una respuesta; el despachador del objeto necesita otra. Si un sistema archiva un solo “tipo”, pierde la posibilidad de saber cuál de las dos capas fue declarada y comprobada.

El valor de typ admite un entero del registro CoAP Content-Formats o una cadena de tipo de medio, con parámetros cuando correspondan. Una representación compacta puede mejorar el enlace, pero el receptor debe conservar la forma exacta. Un entero y una cadena que una política considera equivalentes pueden haber recorrido caminos distintos o activar código diferente.

La evidencia mínima contiene la ubicación, los bytes protegidos y el contexto esperado. Normalizar demasiado pronto produce un registro cómodo y una investigación imposible.

Un campo protegido también puede declarar algo falso

RFC 9596 prohíbe colocar typ en los encabezados no protegidos. Cuando la construcción COSE autentica el bloque protegido, un intermediario no puede cambiar esa declaración sin romper la comprobación criptográfica.

Eso fija la declaración al firmante; no fija la declaración a la verdad. El firmante puede elegir un tipo equivocado, una denominación antigua, parámetros no admitidos o el tipo correcto para otro punto de entrada. También puede envolver una carga que no cumple la especificación nombrada.

Por eso el RFC asigna el trabajo a la aplicación. Las bibliotecas COSE ignoran el parámetro salvo para entregarlo. Una aplicación que usa tipado explícito debería rechazar tanto el valor inesperado como la ausencia del campo cuando era obligatorio.

La diferencia entre observar y aplicar es decisiva. Registrar que el 98 % de los mensajes trae typ no dice si el receptor rechaza el otro 2 %. Tampoco dice si el receptor compara el valor antes de procesar la carga o simplemente lo muestra después de haber elegido un manejador por otra señal.

Tipos diferentes necesitan validadores que no se solapen

RFC 8725 explica el problema en JWT: un tipo de token puede confundirse con otro. El tipado explícito ayuda, pero la guía exige además reglas de validación mutuamente excluyentes.

En COSE, el principio evita una falsa sensación de seguridad. Si dos clases usan las mismas claves sin restricción de propósito, aceptan las mismas audiencias por defecto y comparten un conjunto amplio de claims opcionales, cambiar la etiqueta quizá no cambie la decisión. El atacante no necesita borrar typ; basta con encontrar una ruta que lo ignore o un validador que acepte ambas semánticas.

La rama debe unir tipo, estructura COSE permitida, encabezados obligatorios, tipo de carga, claims, emisor, audiencia, propósito de clave, caducidad, antirrepetición, punto de entrada y operación autorizada. El objeto incorrecto debe quedar fuera antes de que el código común lo vuelva indistinguible.

RFC 8725 recuerda que los usos antiguos pueden no consultar typ. Una migración segura debe medir la versión del validador en recepción y ejecutar pruebas negativas. La publicación de objetos etiquetados es sólo la mitad visible de la transición.

IANA asigna nombres; cada servicio conserva su decisión

El registro COSE de IANA contiene typ con la etiqueta 16. Sus valores provienen de los registros de tipos de medio o de formatos de contenido CoAP. Esa asignación evita colisiones y permite que implementaciones independientes intercambien una declaración común.

No es una lista de confianza. Un tipo registrado no está automáticamente habilitado en un endpoint. El registro no sabe qué firmantes están autorizados, qué parámetros acepta el perfil, qué carga recibió el servicio ni cuál es el estado local.

La arquitectura sana mantiene tres registros separados: el registro público de nombres; la política versionada de tipos aceptados por ruta; y la evidencia de lo que ocurrió con un objeto concreto. Mezclarlos convierte coordinación en mando.

La idea coincide con la especificación inicial mínima de docs/heng-lu-note.md: normalizar sólo lo necesario para interoperar, dejar la decisión futura en el participante que ejecuta el código y reconocer adopción cuando la validación se aplica, no cuando una autoridad publica un nombre.

Conservar el recorrido completo de la decisión

Para cada recepción, conviene guardar el hash de los bytes originales, la clase estructural COSE, los bytes protegidos, el valor y representación exactos de typ, el tipo de la carga, la ruta, la operación, el conjunto esperado, la versión de política, el resultado de firma/MAC/descifrado, la clave y su propósito, el resultado del parser, los claims exigidos, emisor, audiencia, frescura, repetición, decisión de autorización, manejador y efecto.

La firma responde quién vinculó una clave con unos bytes. El tipo responde qué clase declaró. El parser responde si la carga tiene forma. El perfil responde si la semántica es válida. La política de claves responde si el firmante tenía competencia. La autorización local responde si la operación estaba permitida. El resultado responde qué ocurrió.

Un tablero que resume todo como “objeto válido” borra al responsable de cada afirmación. Y cuando hay un incidente, obliga a confiar precisamente en el componente que está bajo examen.

La claridad no requiere desconfiar de los estándares. Requiere respetar sus límites. RFC 9596 ofrece un dato protegido de gran valor; su valor se conserva cuando nadie le atribuye la autoridad de los pasos siguientes.

Fuentes