Resumen

  • En un dispositivo con varios proveedores, confiar en una colección de Endorsers no indica cuál de ellos puede añadir afirmaciones sobre cada Target Environment.
  • Una firma válida del proveedor del sistema operativo puede ser auténtica y, aun así, carecer de mandato para describir el hardware o el firmware.
  • La revisión 11 permite guardar esa relación de alcance en la política, en la Evidence o en ambas; un dictamen auditable debe conservar la opción concreta utilizada.

La atestación remota suele representarse como un problema de mediciones y firmas. La pregunta más incómoda aparece antes del resultado: ¿quién tenía derecho a describir esa pieza del dispositivo?

Un equipo puede combinar aplicación, sistema operativo, firmware y hardware de cuatro organizaciones. Todas pueden estar en la lista de fuentes confiables y todas pueden firmar correctamente. Eso no convierte a cada una en portavoz de las otras tres. Si el motor usa «firmante confiable» como permiso global, la validación criptográfica oculta un fallo de autoridad.

La revisión 11 de RATS Endorsements lo explica mediante varios Target Environments. Cada proveedor puede aportar un conjunto adicional de afirmaciones sobre su propia capa. Pero el Verifier debe distinguir qué Endorser está autorizado a hablar sobre cuál entorno. El borrador incluso fija el contraste: el Endorser del OS puede ser confiable para el OS sin serlo para el hardware.

No hace falta que el proveedor mienta. Tampoco que una clave sea robada. Basta con que el sistema confunda identidad con competencia. La cadena de certificados responde quién firmó; la política de alcance responde qué afirmaciones podía introducir ese actor.

El texto deja varias arquitecturas abiertas. La relación Endorser–Target Environment puede residir en Appraisal Policy for Evidence. La propia Evidence puede nombrar al Endorser admisible. También pueden combinarse ambas. El formato de Endorsement debe explicar cómo resuelve esta cuestión, pero el borrador no impone un recibo universal.

Por eso dos Verifiers podrían aceptar la misma firma y discrepar sobre su admisibilidad. Quizá usan mapas de componentes distintos, versiones de política diferentes o Evidence con otra delegación. El mensaje firmado no basta para reproducir la decisión.

La separación ya está preparada por RFC 9334: el Endorser aporta afirmaciones, el Verifier Owner controla la política que evalúa Evidence y el Relying Party Owner decide qué hacer con el Attestation Result. La fuente, el juicio y el efecto pertenecen a autoridades diferentes.

Hay otra frontera. Una Endorsement condicional puede incluir una regla que decide cuándo una afirmación es aplicable. Esa regla no decide por sí sola si el dispositivo es confiable. Y tampoco sustituye la autorización del Endorser para esa capa. Un motor puede ejecutar el emparejamiento exacto y aun aceptar una afirmación procedente del actor equivocado.

El identificador tampoco resuelve todo. Un UEID conforme a RFC 9711 puede ayudar a buscar la clave del Attester. La revisión 11 deja fuera la granularidad con que esa clave aplica: instancia, clase u otro conjunto de afirmaciones. Encontrar la clave correcta no confiere automáticamente alcance sobre todo el equipo.

La cadena mínima de prueba debe conservar Evidence y frescura; identidad, cadena y vigencia del Endorser; mapa de Target Environments; regla que autoriza al actor para una capa y clase de afirmación; versión de Endorsement elegida; identidad del Verifier y de su política; y la decisión posterior del Relying Party con su efecto observado.

El historial del documento sitúa la revisión 11 en IESG Evaluation y en la agenda del 8 de octubre de 2026. La comparación con la revisión 09 muestra qué cambió. El texto plano sigue siendo trabajo en curso, no un RFC.

CoRIM 11 ofrece un modelo concreto relacionado con Endorsements y Reference Values. Adoptarlo no prueba que el despliegue haya aplicado el alcance correcto ni elimina la autoridad de la política local.

Fuentes