Resumen

  • RFC 9783 perfila un Entity Attestation Token para PSA Initial Attestation con nonce, client ID, instance ID, implementation ID, ciclo de vida y componentes de software.
  • La evidencia protegida puede justificar la evaluación de un verificador, pero no resuelve por sí sola la política de inscripción, acceso, conservación o actuación de quien recibe el resultado.

La arquitectura RATS evita una confusión que los flujos automatizados suelen introducir. Según RFC 9334, el Attester produce Evidence; el Verifier la valora; la parte que confía en ella recibe un Attestation Result y decide para su propio fin. RFC 9783 no borra esas etapas. Ofrece un perfil interoperable de la primera clase de material, no un certificado de que toda decisión posterior ya está autorizada.

El nonce muestra por qué importa el alcance. El perfil exige exactamente uno y admite 32, 48 o 64 bytes. Su función es conectar el informe con un reto concreto y permitir comprobar frescura. Esa comprobación reduce el riesgo de reutilizar evidencia antigua. No demuestra que quien planteó el reto tenga derecho al servicio, que la persona operadora haya autorizado el uso ni que una prueba reciente merezca una concesión indefinida. La frescura pertenece al intercambio de evidencia; la autorización pertenece a otra regla y a otro responsable.

El client ID tampoco es un detalle decorativo. Representa el dominio de seguridad desde el que se invocó Initial Attestation, y RFC 9783 exige al verificador revisarlo para impedir que un extremo se presente como otro. Si el valor no cuadra, la evidencia debe perder valor para esa solicitud. Si sí cuadra, aún solo se ha establecido cuál es el dominio que llamó. No se ha identificado un titular comercial, aprobado un entorno de cliente ni fijado el alcance de una cuenta. Separar dominios no es lo mismo que repartir privilegios.

Los dos identificadores de PSA hacen visible una segunda separación. El instance ID identifica una clave y una instancia concretas. El implementation ID identifica un ensamblaje inmutable de hardware PSA Root of Trust, no una instancia; sirve al verificador para buscar información del Endorser, como datos de fabricante o estado de certificación. Uno responde a «¿qué instancia produjo el informe?»; el otro, a «¿qué implementación se afirma?». Ninguno responde a «¿qué debe hacer ahora este servicio?». Convertirlos en una identidad empresarial o un permiso es añadir una conclusión que el token no transporta.

El lifecycle y los software components también tienen semántica delimitada. El estado de ciclo de vida incluye valores mayor y menor, y el perfil identifica estados en los que no debe confiarse en un informe. Los componentes describen código, configuración u otros elementos cargados dentro del alcance medido por el PSA Root of Trust. Ambos pueden respaldar un rechazo, una evaluación más restrictiva o una solicitud de evidencia adicional. No prueban la finalidad actual de una carga, un compromiso con un cliente, una aprobación de operaciones ni el resultado de un comando ejecutado después.

La decisión correcta puede ser negativa incluso con un token impecable. Un verificador puede aceptar su protección, nonce, dominio, implementación y ciclo de vida conforme a una política publicada. La parte que confía en el resultado puede negar la inscripción por falta de aprobación de flota, limitar el acceso mientras se completa otro registro o exigir una autorización humana antes de una acción irreversible. Esa distancia no es burocracia superflua. Identifica quién responde por el error cuando una señal técnica se convierte en consecuencia real.

La propuesta de Heng Lu de una especificación inicial mínima ayuda a conservar la proporción: un mecanismo común debe hacer comprobables las afirmaciones compartidas sin apropiarse de decisiones locales futuras. El hecho de que el mecanismo haya funcionado, como recuerda la primacía del código en ejecución, demuestra una ejecución y una verificación; no traslada la responsabilidad de controlar un recurso, un servicio o una pérdida.