Resumen

  • La llamada de adopción de RATS para draft-poirier-rats-eat-da-10 termina el 11 de septiembre de 2026. Pregunta si el grupo debe asumir un borrador individual; no es una adopción consumada, un RFC ni una orden de despliegue.
  • Un Device Assignment Token puede transportar evidencia de un dispositivo. No elige restricciones adicionales, no valora la evidencia, no fija la política de la parte que confía ni autoriza el uso del dispositivo.

La consulta es sobre una tarea, no sobre un dispositivo confiable

El objeto público tiene nombre y versión: An EAT Profile for Trustworthy Device Assignment, revisión 10. El Datatracker aún lo muestra como Internet-Draft activo y candidato para RATS, sin respaldo IETF ni rango formal en el proceso de estándares. Hasta el 11 de septiembre la pregunta concreta es si el grupo debe trabajar sobre él. Una respuesta posterior puede cambiar el estado de un trabajo; no certifica un adaptador, una GPU o una función virtual para una carga determinada.

La materia sí es importante. La asignación de dispositivos permite que una máquina virtual de confianza controle un adaptador de red, una GPU u otra función PCIe mientras el hipervisor u otras máquinas pueden quedar fuera de su límite de confianza. El borrador pide evidencia de identidad, firmware y configuración, y define el DAT como perfil EAT para expresarla.

Expresar esa evidencia de modo común es valioso. Permite que afirmaciones, submódulos, firmas y envoltorios se entiendan entre implementaciones. Pero no vuelve una observación completa, reciente o suficiente para una carga concreta. Un formato compartido reduce ambigüedad en el registro; no elimina el juicio que debe seguir al registro.

Las restricciones no vienen dentro del token

El borrador establece que se basa en la información de SPDM y no impone restricciones de seguridad adicionales. Corresponde a otras entidades describirlas, seleccionarlas y aplicarlas conforme a requisitos operativos. No es una laguna que pueda llenarse diciendo que el formato ya resolvió la seguridad. Es el límite que conserva la autoridad local.

El propietario todavía debe elegir anclas de confianza, estados aceptables de firmware y configuración, antigüedad máxima de la evidencia, información de revocación, verificador, reglas de reenvío y condiciones de reversión. Un inquilino de nube, un operador de plataforma y una organización que protege una clave sensible pueden emplear la misma sintaxis y llegar razonablemente a decisiones distintas. Sus pérdidas y deberes no son iguales.

La cobertura actual también es limitada: se concentra en dispositivos PCIe compatibles con SPDM, deja los dispositivos SPDM en chip para consideración futura y no cubre la migración en vivo de una máquina virtual de confianza. No procede presentar un formato con esos límites como una conclusión universal.

El resultado del verificador no es la autorización

RFC 9334 separa la valoración de Evidencia, que realiza un Verificador usando valores de referencia, avales y una política propia, de la valoración de Resultados de atestación por la Parte que confía. Esta aplica su propia política para tomar una decisión específica de la aplicación, incluida una autorización. Las dos políticas pueden pertenecer a responsables distintos.

RFC 9711 añade que EAT puede describir una entidad para una decisión de confianza, pero no establece reglas normativas de procesamiento para verificadores. Un verificador puede reenviar, cambiar o complementar afirmaciones según su política; la parte que confía debe comprender ese procesamiento antes de interpretar el resultado. Una firma válida y un perfil bien formado describen un artefacto: no son una instrucción portátil para permitir un dispositivo.

La carta de RATS mantiene la misma frontera. Incluye formatos y procedimientos para evidencia y resultados, pero deja fuera los formatos y protocolos de políticas de valoración. Esa división permite interoperabilidad sin fingir que un grupo de trabajo decide el apetito de riesgo de todas las organizaciones.

Dos recibos para dos decisiones

El recibo público debe guardar la llamada, la fecha, la revisión exacta, cobertura, límite sobre restricciones y cualquier disposición posterior. No debe convertirse en «RATS aprobó este dispositivo». Junto a él hace falta un recibo local: identidad y contexto del dispositivo, origen de evidencia, ancla aceptada, identidad y reglas del verificador, valores de referencia, frescura, versión de política, alcance de autorización, propietario y reversión.

Conviene vigilar la disposición registrada de la llamada, una primera versión del grupo y los cambios explícitos de alcance. Para afirmar un despliegue, la evidencia decisiva sigue en la política de la parte que confía, la base de valoración del verificador, la autorización y el resultado observado. Mantenerlas separadas protege el formato en lugar de atribuirle autoridad ajena.

Fuentes

  1. Llamada RATS a la adopción
  2. Registro Datatracker
  3. draft-poirier-rats-eat-da-10
  4. Carta del grupo RATS
  5. RFC 9334
  6. RFC 9711