Resumen

  • RFC 9999 da una envoltura común y autodescriptiva a Evidence, Endorsements, Reference Values, Attestation Results y Appraisal Policies.
  • Record, Tag y Collection CMW aportan estructura y tipo, no autenticidad, integridad, confidencialidad, identidad compuesta ni autorización final.
  • Si una Collection representa un solo dispositivo compuesto, sus evidencias deben quedar unidas criptográficamente; después, el Verifier las evalúa y la Relying Party decide qué acción permiten.

Un servidor va a incorporarse a una zona de computación confidencial. El procesador declara su cadena de arranque, la SmartNIC informa del firmware y la GPU produce evidencia desde su propio entorno de atestación. Un colector coloca los tres objetos bajo etiquetas distintas dentro de una Collection CMW.

Un atacante sustituye la evidencia de la SmartNIC por otra, perfectamente válida, copiada de una máquina sana. Cada firma puede verificarse. Cada tipo puede reconocerse. La colección puede superar todas las comprobaciones sintácticas. Aun así, ya no describe un equipo real. Tres hechos auténticos se han ensamblado para producir una identidad compuesta falsa.

Ese ataque delimita la aportación del RFC 9999, publicado en julio de 2026 como estándar del IETF. El RATS Conceptual Message Wrapper permite que los mensajes conceptuales de RATS viajen por formatos y protocolos distintos sin que el núcleo tenga que entender cada tecnología de atestación. La envoltura facilita el tránsito; no certifica la historia que transporta.

El indicador decide el manejador, no el veredicto

El RFC 9334 separa roles y artefactos. El Attester produce Evidence. El Verifier usa Evidence, Endorsements, Reference Values y una Appraisal Policy for Evidence para producir un Attestation Result. La Relying Party aplica su propia Appraisal Policy for Attestation Results antes de ejecutar una acción de aplicación.

RFC 9999 asigna posiciones de bits a cinco mensajes: Reference Values, Endorsements, Evidence, Attestation Results y Appraisal Policy. Un Record CMW contiene un tipo de medio o CoAP Content-Format, el valor serializado y, si hace falta disipar ambigüedad, el mapa ind.

El receptor aprende qué clase de objeto tiene delante. No aprende si debe confiar en él. Una Reference Value puede estar obsoleta, un Endorsement puede venir de una clave no aceptada, una Evidence auténtica puede haber caducado y un Attestation Result puede corresponder a una política o a un propósito diferentes.

El diseño permite que el procesador central seleccione un complemento y le entregue el contenido opaco. Es una propiedad de extensibilidad y también una frontera de autoridad. Quien elige el decodificador decide la ruta de los bytes. No decide si el servidor obtiene acceso.

Collection no significa «un dispositivo»

CMW tiene forma de árbol. Record y Tag son hojas; Collection reúne elementos etiquetados y puede anidar otras colecciones. Esa estructura admite que CPU, SmartNIC y GPU usen formatos heterogéneos sin obligar al protocolo exterior a conocerlos.

La misma flexibilidad impide inferir unidad. Una Collection puede mezclar tipos conceptuales e incluso contener mensajes sobre varios dispositivos. El valor opcional __cmwc_t, una URI o un OID, da tipo al conjunto y define el espacio de nombres de sus etiquetas. Puede describir un montaje permitido, pero, sin protección, sigue siendo una afirmación sobre la forma.

La recursión añade otro contrato local. Las implementaciones pueden limitar la profundidad. Si una pasarela inspecciona un nivel y el Verifier acepta cuatro, el mismo objeto atraviesa dos modelos semánticos. El protocolo anfitrión debe acordar profundidad, tamaño, número de miembros, tipos desconocidos y conducta de fallo.

La firma necesita un sujeto y un alcance

RFC 9999 aclara que CMW no es un formato de seguridad. Es posible firmar el CBOR con COSE_Sign1, el JSON con JWS e incluir la envoltura en claims cmw de CWT o JWT. Son mecanismos disponibles, no garantías predeterminadas.

Cuando la Collection representa evidencia de un dispositivo compuesto o por capas, todos los objetos Evidence deben estar vinculados criptográficamente. Puede firmarse la colección completa. También pueden emplearse identificadores comunes, nonces relacionados, firmas cruzadas o cadenas de hash. El Attester que crea la Collection es responsable de protegerla.

No todas las uniones prueban lo mismo. La firma exterior de un daemon demuestra que el daemon firmó esos bytes, no que su clave pertenezca a la raíz de confianza del servidor. Repetir un número de serie sirve poco si cualquier componente puede copiarlo. Un nonce compartido enlaza la sesión solo cuando llega de forma autenticada a cada entorno y cada respuesta lo cubre.

Por eso el registro de auditoría no puede reducirse a signature_valid=true. Debe conservar el hash de la Collection original, la forma exterior, el tipo del conjunto, las etiquetas, tipos internos e indicadores, la clave, el material de frescura, el método de vinculación, la profundidad y la transcripción de validación. Sin esos datos, nadie podrá reconstruir si la protección cubría cada hoja, el ensamblaje o únicamente el token de transporte.

Cambiar de portador cambia el modelo de confianza

RFC 9999 registra application/cmw+cbor, application/cmw+json, application/cmw+cose y application/cmw+jws; añade claims JWT/CWT y una extensión X.509. Una misma clase de mensaje puede entrar en una API web, un protocolo restringido, un certificado o un archivo.

Cada contenedor protege una superficie. Un JWS puede cubrir la Collection, pero no la Evidence extraída después. Un JWT puede autenticar al emisor exterior sin probar el origen de los miembros. TLS protege el tramo entre dos pares, no al creador de un objeto reenviado. Recodificar CBOR como JSON puede preservar significado y destruir la firma sobre bytes exactos.

El protocolo anfitrión debe especificar los mensajes y combinaciones permitidos, la protección necesaria, la interfaz y el efecto de la interacción entre ambos modelos de seguridad. Decir solamente «el payload es CMW» define sintaxis, no autoridad.

La extensión X.509 muestra la consecuencia. Normalmente no debería ser crítica. Puede marcarse crítica cuando el mensaje sea indispensable para conceder acceso y una Relying Party antigua pudiera ignorarlo. La marca determina si un consumidor que no comprende la atestación se detiene o continúa sin el control.

También cambia la privacidad. Evidence puede contener datos personales, el modelo de un HSM o el nivel de parche. Entregar esos datos a una autoridad de certificación no equivale a publicarlos en un certificado de larga duración. RFC 9999 exige que la práctica de certificación describa con claridad cuándo puede producirse esa difusión.

Un Attestation Result no es una orden de acceso

El último atajo consiste en convertir un resultado positivo del Verifier en permiso automático. RATS mantiene dos propietarios de política: el Verifier Owner controla cómo se evalúa la Evidence; el Relying Party Owner controla cómo afecta el resultado a la aplicación.

El mismo resultado puede bastar para telemetría de bajo riesgo, exigir cuarentena para administración y ser insuficiente para una operación de firma. El recurso solicitado, la zona, el tiempo y la excepción comercial pertenecen al contexto de la Relying Party.

Una decisión reproducible enlaza sin confundir: conjunto y vinculación; versiones de Endorsements y Reference Values; política del Verifier y resultado; política de la Relying Party y acción solicitada; decisión final. Un booleano elimina la causa. Un token aislado elimina al actor que ejerció la autoridad.

La primacía del código en ejecución de Lu Heng aporta la disciplina: la conformidad del envoltorio es procedencia formal, pero no puede borrar lo que hicieron realmente los manejadores, la evaluación y el control. Minimum Initial Specification justifica un contrato común y delgado; la combinación, la vinculación y las consecuencias siguen siendo decisiones locales. Reality Layers impide tratar el tipo, la firma, la evaluación y la acción como una sola verdad.