Resumen

  • RFC 10013 define un componente medido con nombre y valor bruto o resumido obligatorios, y con versión, autoridades firmantes del componente y banderas de perfil opcionales. El objeto puede viajar dentro de una reivindicación de mediciones EAT en JSON o CBOR.
  • La igualdad del resumen criptográfico sólo vale para los bytes seleccionados. La autoridad del componente no es por ello quien firma el EAT, la conformidad con un valor de referencia no es el resultado total del Verifier y ese resultado tampoco concede derechos.
  • La decisión auditable conserva cada relevo: perímetro y momento de medición, Attester y frescura, perfil, autoridades, Reference Value, política de evaluación, Attestation Result y política de autorización del Relying Party.

Un equipo correcto ante la puerta equivocada

Supongamos que un sensor industrial vuelve de reparación y solicita acceso a una red de mantenimiento.

Entrega un EAT firmado por la clave esperada. El nonce es reciente. El componente medido identifica el cargador de arranque, incorpora una versión conocida y comunica un resumen SHA-256 que coincide con la referencia de producción. Las autoridades enumeradas corresponden a firmantes admitidos del firmware. El Verifier emite un resultado conforme.

La consola podría abrir la red con una sola regla: “si está atestiguado, permitir”.

Sería una decisión injustificada.

Puede que la medición no incluya la configuración mutable que selecciona el siguiente módulo. Puede que el valor de referencia todavía acepte una versión con una vulnerabilidad recién divulgada. El equipo puede ser genuino y estar sano, pero pertenecer a un proveedor externo. Puede tener permiso para enviar estado y no para escribir parámetros. Incluso las autoridades pueden haberse interpretado con un perfil distinto del que gobernó al emisor.

La medición no mintió. La automatización le pidió que respondiera preguntas ajenas.

RFC 10013, publicado en julio de 2026 como Proposed Standard del IETF, crea una representación común para un componente muestreado. No define qué derecho nace de ella. Esa separación es el centro operativo del estándar.

El perímetro precede al hash

El componente puede ser firmware en memoria flash, software cargado al inicio, una comprobación de integridad en ejecución, un objeto del sistema de archivos, una configuración o un registro de CPU. La lista evita reducir la atestación a un inventario de paquetes.

RFC 9393 describe CoSWID, una forma concisa de identificar software y seguir su ciclo de instalación. EAT ya podía transportar CoSWID de evidence. Pero no toda medida temprana de arranque o de hardware tiene una identidad de archivo o paquete. RFC 10013 ofrece una estructura más directa para esos casos.

No dice qué región medir.

Alguien define dónde empieza y termina el componente. Otro mecanismo toma la muestra. Un entorno protegido puede impedir que software ordinario falsifique la lectura, pero seguirá leyendo lo que su diseño haya delimitado. La criptografía no descubre por sí sola el estado omitido.

Por eso el registro operativo debe incluir Target Environment, límites, colector, hora o época de arranque y dependencias fuera de la muestra. “Arranque seguro correcto” es una etiqueta; la evidencia es el conjunto concreto que permite reconstruir qué se comprobó.

La idea de Running-Code Primacy corrige la jerarquía. La especificación común organiza el intercambio. La autoridad práctica viene de observar el código cargado, el comportamiento y el efecto de la decisión.

Un nombre estable ayuda y también expone

El nombre del componente es obligatorio y legible. Su convención depende del tipo de objeto. RFC 10013 pide consistencia entre versiones para que el sistema siga el mismo componente durante las actualizaciones. No crea un espacio global de nombres.

Dos fabricantes pueden emplear nombres parecidos. Una ruta como /boot/loader.bin puede conservarse mientras cambia el significado de su contenido. La correlación requiere conocer quién asignó el nombre y bajo qué esquema.

La versión es opcional y puede reutilizar esquemas de RFC 9393. El modelo recomienda Semantic Versioning, pero no obliga a expresar un registro de CPU o un blob de configuración como si fuera una biblioteca de software.

La estabilidad tiene un coste. Nombre y versión pueden revelar producto, parche y configuración, y el propio RFC advierte que facilitan el seguimiento. La identidad útil para operaciones también puede convertirse en un inventario útil para un atacante.

Valor bruto, resumen fuerte y pregunta incompleta

La medición puede ser bruta o resumida. El valor bruto conserva el contenido, pero su tamaño puede variar enormemente. El decodificador puede limitar la memoria reservada; de lo contrario, una prueba se transforma en un vector de agotamiento y en un repositorio de configuración sensible.

La forma resumida incluye algoritmo y bytes. Los identificadores se leen conforme al registro de algoritmos Named Information de IANA. RFC 10013 exige una función criptográfica fuerte.

Un algoritmo fuerte responde: “estos bytes producen este valor”. No responde:

  • si eran todos los bytes relevantes;
  • si se recogieron después del último cambio;
  • si la referencia sigue siendo segura;
  • si la implementación del Attester está suficientemente protegida;
  • si este equipo tiene relación jurídica u operativa con la organización;
  • si el recurso solicitado acepta este tipo de resultado.

Un panel que convierte la coincidencia en confianza no añade información. Oculta decisiones.

La palabra autoridad contiene otra firma

El campo authorities identifica entidades capaces de reconocer el componente instalado mediante su firma digital. El identificador puede derivar de un certificado X.509, una clave pública, una huella u otra asociación única. La firma puede comprobarse durante la instalación, como contempla la arquitectura de actualización de RFC 9019, o durante el arranque y la ejecución.

No es la firma del Attester sobre el EAT.

La firma del componente dice quién aprobó o identificó el artefacto. La firma del EAT dice quién produjo y protegió este conjunto de claims. Pueden existir ambas y fallar por separado. Un firmware legítimo puede estar en un dispositivo que fabrica evidence sin protección suficiente. Un EAT auténtico puede informar de un componente firmado por una autoridad que la política local ya no acepta.

También puede haber varias autoridades: distribuidor de actualizaciones, propietario de flota, auditor. Su posición en el array puede importar. El perfil EAT aplicable debe definir uso, significado y codificación.

Las flags también dependen del perfil. Son ocho bytes exactos y ningún bit tiene significado universal en RFC 10013. Si el consumidor no reconoce el perfil y aparecen authorities o flags, debe rechazar el EAT. Interpretarlas por semejanza con otro despliegue sería crear una autorización fuera del protocolo.

Los números 295 y 296 no son sellos de confianza

La especificación coordina las formas JSON y CBOR y permite representaciones homogéneas o encapsuladas. IANA registra application/measured-component+cbor y application/measured-component+json. El registro CoRE Content-Formats asigna 295 y 296.

Con ello, un receptor sabe qué decodificar. No sabe todavía si debe confiar.

Es una aplicación precisa del principio de especificación inicial mínima y decisión futura localizada. Los campos y codificaciones pertenecen al mínimo común. Los perfiles, referencias, políticas y permisos pertenecen a actores concretos.

La consulta oficial de erratas de RFC 10013 no mostraba coincidencias el 30 de agosto de 2026. Es una observación temporal, no una certificación de implementaciones.

EAT normaliza claims, no la fortaleza del Attester

RFC 9711 afirma que EAT define semántica sin exigir un nivel concreto de seguridad a cada claim o al propio Attester. El receptor determina la credibilidad comprendiendo la implementación del proveedor y los controles del Verifier.

Un EAT producido en hardware aislado y otro producido por una aplicación pueden compartir sintaxis y ofrecer garantías distintas. La portabilidad del formato no elimina esa diferencia.

Todo uso de EAT debe aportar frescura. Un nonce o mecanismo equivalente evita el replay de un mensaje antiguo. Aun así, una medición tomada al arrancar puede incorporarse a un token posterior. La auditoría debe distinguir instante de muestreo, emisión y boot epoch.

EAT define además measres para comunicar el resultado de comparar mediciones con valores esperados: éxito, fallo, no ejecutado o ausente. No es el resultado global del Verifier. Mostrarlo como “dispositivo confiable” confunde comparación y juicio.

RFC 9783, modelo PSA que precede a parte de RFC 10013, ilustra políticas diferentes: igualdad con una medida concreta, pertenencia a una secuencia admitida o aceptación por firmante. Cada una cambia la superficie de riesgo.

La arquitectura conserva dos decisiones finales

RFC 9334 asigna papeles: el Attester genera Evidence; el Reference Value Provider aporta valores esperados; el Verifier aplica Appraisal Policy for Evidence y emite Attestation Results; el Relying Party usa esos resultados para decidir cuánto confiar y qué operación permitir.

Que una plataforma ejecute varios papeles no convierte sus preguntas en una sola.

La Reference Value tiene proveedor, versión, vigencia y retirada. Cuando aparece una vulnerabilidad, el mismo resumen puede dejar de ser aceptable sin cambiar el equipo. Quien gobierna referencias y políticas controla, por tanto, una decisión remota sobre toda la flota.

El Verifier traduce pruebas específicas de cada fabricante a resultados consumibles. Esa función concentra confianza y debe dejar rastro de su identidad, software, política, entradas y tiempo.

El Relying Party conserva la autorización. RFC 9334 señala que una empresa puede considerar saludables muchos portátiles de un fabricante y admitir únicamente los que posee. Salud, identidad y derecho no son sinónimos.

El incidente se investiga flecha por flecha

La cadena mínima es:

objeto elegido → colector y momento → valor → nombre y versión → significado de autoridades → firma y frescura EAT → perfil → Reference Value → política del Verifier → Attestation Result → política del Relying Party → permiso → efecto observado.

Si todo termina en un booleano, no puede saberse dónde se autorizó lo incorrecto.

Tras un incidente, el equipo debe distinguir si faltó estado en la muestra, si la referencia era obsoleta, si la política se ejecutó mal o si el Relying Party concedió más de lo que el resultado justificaba. El semáforo verde no asigna responsabilidad.

El análisis de Heng Lu sobre capas de realidad y poder simbólico ayuda a no invertir la relación: nombre, resumen, firma y resultado son representaciones de una realidad seleccionada. La claridad consiste en preservar la distancia.

La custodia de los claims también es seguridad

Los nombres estables, versiones y valores brutos pueden revelar una radiografía del parque. Si un consumidor descifra el EAT y distribuye claims a otros servicios, RFC 9711 pide protección equivalente al perderse la envoltura y reducción de exposición.

La diferencia entre soberanía formal y realidad práctica de los datos obliga a seguir cada copia: Verifier, log, traza, analítica, soporte y servicio de remediación. Poseer el sensor no equivale a controlar su mapa técnico.

Cada receptor debería obtener sólo lo necesario. Un servicio de acceso puede consumir un Attestation Result actual. El equipo de parcheo quizá necesite versión y referencia. Ninguno necesita siempre el blob bruto.

El estándar acaba donde empieza la responsabilidad

RFC 10013 consigue algo concreto: un objeto común, formas JSON/CBOR, semántica de perfil obligatoria, resúmenes fuertes, rechazo de extensiones incomprendidas y advertencias de privacidad.

No declara bueno al equipo.

El colector responde por el perímetro. El Attester por la Evidence. El firmante del componente por la procedencia. El proveedor de referencias por el estado esperado. El Verifier por la evaluación. El Relying Party por el permiso y su consecuencia.

El componente puede pasar la prueba. La organización todavía debe decidir la puerta.