Resumen

  • Un procesador puede tener que firmar la evidencia antes de entregar el control a código que no regresa; suit-report-reason-invoke-pending conserva la incertidumbre en vez de inventar un éxito.
  • Los registros SUIT son coordenadas dentro de un manifiesto: sin los bytes exactos validados por suit-report-manifest-digest, no deben reconstruirse.
  • La decisión operativa necesita comprobantes distintos para autenticidad, frescura, entorno de medición, entrega de control, ejecución sostenida y efecto del servicio.

El segundo anterior a la ejecución

Un dispositivo prepara un informe de estado para una verificación remota. Ha recorrido el manifiesto, evaluado condiciones y llegado a SUIT_Command_Invoke. La próxima acción cede el control al programa actualizado. Ese programa puede no volver jamás al procesador del manifiesto.

La infraestructura de atestación, sin embargo, necesita que el informe se firme antes del salto. Si el dispositivo marca “éxito” por adelantado, la criptografía protegerá una afirmación prematura. Si espera una devolución que no forma parte del diseño, puede no producir ningún informe.

draft-ietf-suit-report-22 resuelve la tensión con una categoría temporal, no con una ficción: suit-report-reason-invoke-pending. La invocación está a punto de intentarse y su desenlace es desconocido. El propio borrador advierte que firmar éxito incondicional sería engañoso si la invocación falla después.

El resultado no dice que el código falló. Tampoco promete que arrancará. Certifica hasta dónde llegó el sistema de reporte antes de perder la capacidad de observar el siguiente paso.

La firma custodia una frase, no su porvenir

Validar el contenedor responde a preguntas importantes: quién protegió el mensaje, qué bytes quedaron cubiertos y si fueron modificados. Una nonce o el reto del protocolo de atestación puede responder otra: si la evidencia es fresca y no una repetición.

Ninguna de esas respuestas convierte una acción futura en un hecho. Un invoke-pending auténtico y fresco sigue siendo pending. Un éxito antiguo puede ser auténtico y pertenecer al arranque anterior. Un firmante reconocido puede haber usado un entorno de reporte que la política actual no acepta.

Separar las preguntas evita que un icono de candado se convierta en un veredicto universal. Autenticidad, frescura, autoridad, interpretación y efecto tienen comprobantes diferentes.

El manifiesto es la clave de lectura

El formato comprime el diario usando el manifiesto como diccionario. Un SUIT_Record señala la ruta dentro del árbol de dependencias, la secuencia activa, el desplazamiento en bytes, el índice de componente y propiedades medidas. No repite la instrucción completa.

Por eso el receptor no puede suponer que entiende el registro solo porque entiende CBOR. Debe conseguir el manifiesto exacto y validarlo con suit-report-manifest-digest; si existe una URI de referencia, la del informe debe coincidir exactamente. La revisión 22 prohíbe reconstruir los SUIT_Record sin ese manifiesto.

El digest se usa deliberadamente en lugar del número de secuencia. Con varios firmantes de confianza, dos manifiestos pueden compartir número. La secuencia ordena dentro de un dominio; la huella resistente a colisiones identifica el diccionario concreto.

Las system-property-claims sí incluyen un identificador de componente y pueden tratarse sin obtener primero el manifiesto. Es una excepción precisa. No autoriza a interpretar offsets descontextualizados.

Una política de retención que conserva informes y elimina manifiestos acumula evidencia criptográficamente intacta pero operacionalmente ilegible. El vínculo entre ambos es parte del expediente.

Atestar también al que atesta

Para que un SUIT Report sirva como Attestation Evidence, la revisión 22 exige medir el ambiente que lo generó. Esto abarca normalmente el Manifest Processor, el Report Generator y los bootloaders o sistemas operativos que los sostienen.

El motivo es sencillo. Una clave legítima puede estar al alcance de un generador alterado. Un contenedor puede validar aunque el software que reunió las mediciones ya no sea el esperado. La firma protege la salida; las mediciones permiten evaluar al productor.

La RFC 9334 divide después el trabajo. El Attester produce Evidence. El Verifier la valora según una política y genera Attestation Results. La Relying Party decide si confía y qué acceso concede. El informe SUIT, además, necesita que el Verifier recupere el manifiesto y traduzca sus waypoints a afirmaciones útiles.

No hay una única operación llamada “verificar”. Hay validación criptográfica, reconstrucción, evaluación del entorno y decisión de confianza. Una interfaz que las comprime en una marca verde oculta quién asumió cada riesgo.

Un canal seguro mantiene el límite, no lo borra

La transmisión remota debe ser autenticada y confidencial, o viajar dentro de una protección equivalente. El borrador contempla EAT, transportes seguros y contenedores COSE. Si la política requiere autenticación, el dispositivo no puede enviar un informe sin autenticar; un informe parcial debe cumplir la misma integridad.

Esas garantías impiden suplantación, alteración y exposición. No prueban que el nuevo binario tomó control. Un mensaje protegido que dice “voy a invocar” no se convierte durante el trayecto en “invoqué y funcionó”.

El siguiente hecho debe venir de otro testigo: una medición de arranque, una señal de vida, un estado de aplicación o una observación externa. Conviene separar incluso la primera instrucción de la salud sostenida. Arrancar una vez no prueba prestar el servicio durante la ventana requerida.

La cadena que permite investigar

El expediente conserva los bytes del informe, el método de autenticación, la identidad del firmante y el control de frescura. Luego fija el digest raíz, recupera el manifiesto correspondiente y reconstruye la ruta, secuencia, offset y componente. Después evalúa las mediciones del procesador, generador y soporte de arranque.

El resultado se guarda sin embellecer: éxito, error explícito, entrega implícita de control o invoke-pending. A partir de ahí comienzan recibos nuevos para entrada en ejecución, permanencia y resultado del servicio.

La secuencia es:

informe auténtico → frescura → manifiesto exacto → reconstrucción → entorno evaluado → entrega de control → ejecución → efecto

En la fecha de investigación, la revisión 22 era un Internet-Draft activo con intención de Proposed Standard. Estaba en la cola del RFC Editor y bloqueada por una referencia de segunda generación. No era un RFC ni un informe de despliegue.

Fuentes