Resumen

  • RFC 9999 crea una estructura común para que Evidence, Attestation Results, Endorsements, Reference Values y Appraisal Policies de RATS circulen en CBOR, JSON, JWT, CWT, X.509, HTTP, MIME y CoAP.
  • Record, Tag y Collection CMW ayudan a identificar y despachar contenidos, pero no proporcionan por sí mismos autenticidad, integridad, confidencialidad, frescura ni una decisión de confianza.
  • Si una colección describe un dispositivo compuesto, todas sus pruebas deben quedar vinculadas criptográficamente; firmas válidas sobre miembros aislados no demuestran que pertenezcan al mismo equipo ni a la misma ejecución.

Antes de autorizar la firma de una versión crítica, el sistema de construcción pide una atestación del servidor. Llega una colección con tres miembros: CPU, SmartNIC y GPU. Los tres tipos se reconocen. Los tres mensajes internos se decodifican. Las tres firmas son válidas. La regla automática concluye que el servidor completo está sano.

La conclusión solo es válida si existe una relación probada entre esos miembros. La Evidence de la GPU podría proceder de otro host limpio. La SmartNIC podría haber respondido a un reto anterior. El informe de CPU podría ser el único que pertenece al servidor que solicita la clave. No hace falta falsificar una firma para fabricar un conjunto engañoso; basta con recombinar verdades que nunca debieron evaluarse juntas.

RFC 9999, publicado por el IETF en julio de 2026 como Proposed Standard, define el Remote ATtestation procedureS Conceptual Message Wrapper (CMW). Su objetivo es que protocolos y aplicaciones puedan transportar distintos mensajes de atestación sin rediseñarse cada vez que aparece una nueva tecnología o serialización. Es una capa de interoperabilidad, no una sentencia sobre el estado de una máquina.

La arquitectura conserva tres decisiones

RFC 9334 no trata la atestación como una firma con efecto automático. El Attester genera Evidence. El Verifier la compara con Endorsements, Reference Values y una Appraisal Policy, y produce Attestation Results. El Relying Party aplica después su política propia para decidir si concede acceso, libera datos o ejecuta una orden.

Esa secuencia contiene tres preguntas distintas: ¿qué afirmó el dispositivo?, ¿qué significa esa afirmación frente a una política técnica?, ¿qué acción permite el servicio en este contexto? CMW facilita el traslado de los objetos entre esas preguntas sin responderlas por adelantado.

Un Record CMW incluye type, value y, si hace falta, un indicador ind. El indicador puede señalar Reference Values, Endorsements, Evidence, Attestation Results o Appraisal Policy. Un Tag CMW usa una etiqueta CBOR derivada de un CoAP Content-Format mediante RFC 9277. Una Collection CMW agrupa elementos etiquetados y admite colecciones anidadas.

El registro RATS de IANA coordina los indicadores. RFC 9711 define el Entity Attestation Token y RFC 9782 sus tipos de medio. Esta coordinación permite elegir el procesador correcto y evolucionar formatos sin romper el núcleo del protocolo.

Pero un tipo solo describe cómo interpretar bytes. El bit que dice “Evidence” no certifica que quien lo puso sea un Attester fiable. Un tipo de medio registrado no confirma que el perfil sea compatible, que la política esté actualizada o que la declaración sea cierta. La sintaxis elimina ambigüedad de despacho; no elimina la obligación de verificar.

La firma debe tener un perímetro legible

RFC 9999 declara que CMW es encapsulación, no un formato de seguridad. Sus Records, Tags y Collections no aportan, por sí solos, autenticidad, integridad ni confidencialidad.

La protección puede estar dentro del mensaje conceptual o alrededor del envoltorio. RFC 9052 permite estructuras COSE para CBOR; RFC 7515 proporciona JWS para JSON. Un canal seguro protege el tránsito. Un protocolo de reto y respuesta puede controlar el replay.

No son equivalentes. Una conexión autenticada no conserva necesariamente el origen cuando el objeto se almacena y se reenvía. Una firma por miembro no demuestra la composición. Una firma sobre toda la Collection sí protege la lista, pero solo tiene valor si la clave está autorizada a afirmar qué dispositivo forman esos elementos y el perfil firmado define la relación.

El caso de RFC 9781 es una prueba útil. UCCS significa conjunto de claims CWT no protegido. CMW puede identificarlo y transportarlo, pero no lo vuelve auténtico. Añadir una firma exterior es una decisión separada. La operación debe registrar exactamente qué bytes cubre cada firma, qué propósito tiene la clave y qué transformaciones conserva o rompe esa cobertura.

Una colección admite composiciones verdaderas y falsas

RFC 9334 contempla equipos compuestos. Un router puede tener chasis y tarjetas con entornos de atestación distintos. Un servidor puede medir CPU, SmartNIC y GPU por separado. En un sistema por capas, un entorno mide al siguiente antes de entregarle control.

Collection CMW reúne esas pruebas heterogéneas. Para afirmar un único dispositivo compuesto o por capas, RFC 9999 exige que todos los mensajes Evidence queden vinculados criptográficamente. Sin una protección global o enlaces verificables entre miembros, un atacante puede sustituir la prueba de una pieza comprometida por la de una pieza sana.

La especificación permite varias soluciones: firmar la colección completa, compartir identificadores o nonces, cruzar firmas o hashes entre elementos, o definir otra construcción en el protocolo que aloja CMW. Por ello, “hay una firma” es una auditoría insuficiente. Hay que demostrar que el alcance validado une cada miembro con el sujeto, la época y la transacción declarados.

Tampoco toda Collection representa una sola máquina. Puede agrupar Endorsements, Reference Values, resultados o mensajes relativos a varios equipos. Sus etiquetas son únicas únicamente dentro de la colección y el orden no es significativo. Un perfil o tipo de colección opcional proporciona el espacio de nombres que convierte gpu, slot-2 o firmware en posiciones interpretables.

Sin ese perfil, el nombre es una ayuda humana, no una identidad operativa. El inventario real, la generación de topología y la asignación componente-dispositivo deben formar parte de la prueba.

El límite de profundidad es una política de seguridad

Las colecciones pueden anidarse. La recursividad expresa bien una plataforma compleja, pero también multiplica el coste de análisis, decodificación, firmas y consultas externas. RFC 9999 permite limitar la profundidad; deja fuera de alcance el mecanismo exacto para descubrir o negociar ese máximo.

El entorno de producción necesita límites antes de recibir el objeto: bytes totales, número de miembros, profundidad, operaciones criptográficas, tiempo por handler, expansión Base64 y consultas a proveedores de Endorsements o Reference Values. El primer byte puede elegir un decodificador; no autoriza recursos ilimitados.

Los estados de error también deben conservar significado. Un miembro desconocido no es lo mismo que uno inválido. Un miembro ausente no es lo mismo que uno que el perfil declara opcional. Un archivo puede custodiar un objeto opaco; un sistema de autorización no puede omitirlo y proclamar que evaluó el dispositivo completo.

Por cada tipo admitido debe existir un handler versionado, un perfil permitido, una política de algoritmos, límites de recursos y un comportamiento ante fallo. La extensibilidad deja así de ser una puerta lateral hacia la autorización.

Una prueba válida puede llegar tarde

La atestación se refiere a un estado en un momento relevante. Después de actualizar firmware, sustituir una tarjeta o modificar la política, un mensaje antiguo puede seguir verificando su firma y haber perdido toda utilidad.

RFC 9334 separa la frescura y contempla tiempo sincronizado, nonces e identificadores de época. CMW transporta mensajes que usan esos mecanismos, pero no prueba que todos los miembros hayan respondido al mismo reto. Una colección con CPU ligada al nonce A, SmartNIC al nonce B y GPU ligada solo a una marca temporal necesita una regla explícita para decidir si describe una ejecución coherente.

El registro operativo debe guardar el reto, emisor, ventana, supuestos de reloj, época y miembros cubiertos. La frescura no cabe en el icono “firma válida”.

Después, el Verifier evalúa Evidence bajo referencias y política. El Relying Party mantiene la decisión de negocio. Un host que cumple la política de mantenimiento no obtiene por ello permiso para firmar una versión o acceder a datos de un cliente. El Attestation Result debe llegar al destinatario previsto, con su contexto y vigencia.

El cierre completo demuestra la cadena: miembros esperados, análisis, protección, vínculo, frescura, evaluación, resultado, autorización y efecto real.

Un canal duradero puede ampliar la exposición

CMW puede incluirse en certificados X.509, solicitudes y CRL. La reutilización de PKIX simplifica la distribución, pero puede hacer públicos datos que el solicitante solo pretendía revelar a la Certification Authority.

Evidence puede incluir modelo de hardware, nivel de parche u otros rasgos persistentes. RFC 5280 define el tratamiento general de certificados y extensiones; no concede permiso para divulgar esos datos. RFC 3647 ofrece el marco para políticas y prácticas de certificación. RFC 9999 pide que la práctica establezca cuándo una CA puede incluir Evidence de terceros.

La privacidad exige minimizar claims, definir audiencia y retención, revisar el perfil y autorizar la publicación antes de emitir. Revocar un certificado no borra las copias ya distribuidas.

De la etiqueta a la ejecución

El principio de running code de Heng Lu obliga a comprobar el recorrido real: decoder, handler, bytes firmados, confianza en la clave, vínculo, frescura, versión de política, decisión y efecto. Una Collection formalmente perfecta puede fallar en cualquiera de esas capas.

Su planteamiento sobre especificación mínima y decisión futura localizada sitúa bien el reparto: la comunidad coordina el envoltorio y los identificadores; cada operador conserva umbrales y permisos, junto con la responsabilidad por sus consecuencias.

La nota sobre capas de realidad evita fusionar cuatro hechos: sintaxis correcta, protección criptográfica, evaluación semántica y resultado operativo. El sistema es gobernable cuando registra los cuatro sin permitir que uno hable en nombre de los demás.