Resumen

  • El IESG abrió el 24 de agosto la última llamada de draft-ietf-rats-endorsements-09, con comentarios hasta el 7 de septiembre sobre su publicación como RFC Informational. No hay una decisión final.
  • Anton Sokolov planteó, en una intervención pública que debe atribuírsele, que el contenido invariable de una afirmación y la vigencia de la posición del Endorser son propiedades separadas; también preguntó si esa posición se evalúa en T1 o T2.
  • Los autores indicaron que CoRIM ya mantiene ventanas independientes para el contenido y para la firma. El comentarista dio su cuestión por resuelta y los editores decidieron reflejar la distinción en el borrador.
  • La pull request 76 se fusionó el 28 de agosto. La copia latest ahora explica rim-validity, signature-validity, revocación y trust anchors, pero esos párrafos no están en la revisión numerada 09.
  • Un recibo de disposición debe unir comentario, respuesta, diff revisado, merge, siguiente revisión, elección de política, salida de evaluación y acción del IESG. Así se prueba el cambio sin convertir un merge editorial en aprobación institucional.

La revisión oficial se refiere todavía a la versión 09

El anuncio del IESG del 24 de agosto solicitó comentarios sobre RATS Endorsements. El grupo Remote ATtestation ProcedureS pide publicarlo como RFC Informational y el plazo termina el 7 de septiembre. El anuncio no dice que el texto esté aprobado.

En el corte de esta investigación, la ficha del Datatracker seguía mostrando «In Last Call», revision 09 y ninguna fecha de telechat. La ausencia de resolución no invalida el trabajo editorial posterior; simplemente lo ubica en otro nivel. Una fuente en main, un Internet-Draft numerado y una decisión del IESG no son sustitutos.

RATS reparte también la autoridad técnica. El Attester genera Evidence sobre un estado. El Verifier lo evalúa con Reference Values, Endorsements y Appraisal Policy for Evidence. El Verifier Owner manda sobre esa política; el Relying Party Owner decide cómo aplicar el Attestation Result. El Endorser ofrece afirmaciones adicionales, pero su firma no le entrega el control de la decisión final.

La sección 5 de la revisión 09 asigna a cada especificación de protocolo la forma de demostrar la vigencia del Endorsement, por ejemplo mediante la duración de un certificado. Después afirma que las claims estáticas, al describir propiedades invariantes del Environment, no requieren pasos extra de actualidad para su contenido.

La dificultad no está en que una frase niegue la otra. Está en que la segunda puede leerse como si agotara la primera.

Que la afirmación no cambie no inmoviliza al firmante

Anton Sokolov explicó la diferencia en su comentario público. Un dato físico sobre un componente puede mantenerse; al mismo tiempo, el certificado del fabricante puede vencer, su clave puede ser revocada o el Verifier puede retirar el trust anchor. La persistencia de la frase y la aceptación actual de quien la emitió corren por relojes distintos.

La pregunta T1/T2 vuelve operacional esa separación. Si el Evidence representa el estado en T1 y el Verifier lo procesa en T2, ¿en cuál de los dos momentos debe estar vigente el Endorser? El comentario apoyaba la publicación. No denunciaba un ataque, un fallo de producto ni un dispositivo comprometido.

La observación pertenece a Sokolov y así debe aparecer. La aportación editorial de este artículo es otra: diseñar el rastro que permite saber qué hizo el proceso con esa observación y en qué momento una respuesta técnica se convirtió en fuente, en revisión numerada y, acaso después, en una decisión.

Thomas Fossati respondió primero con una formulación de la frontera: la situación del Endorser se comprueba con independencia de la temporalidad del contenido, y el punto de referencia T1/T2 corresponde al protocolo o a la política de evaluación. Sokolov aceptó la frase y sugirió que la salida mostrara qué opción se empleó.

La siguiente respuesta encontró el mecanismo existente. Fossati describió un procesador CoRIM con dos ventanas: una para el contenido y otra para la firma. En ese caso, la validez criptográfica, la revocación y el estado del trust anchor se comprueban al evaluar, en T2. La identificación del Verifier en el Attestation Result puede hacer visible esa elección. Sokolov cerró la cuestión porque la maquinaria existente ofrecía una respuesta suficiente.

El intercambio ya había resuelto la duda entre participantes. Los editores añadieron una segunda clase de memoria: el texto.

El cambio integrado distingue contenido, juicio y autoridad

La pull request 76 se abrió el 25 de agosto, recibió correcciones y las aprobaciones de Dave Thaler y Henk Birkholz, y se fusionó el día 28 con bb53db0c7c6203f82cfad9cd3c4b5eaf8b6fd624.

La copia actual de los editores añade un ejemplo importante. La misma medición H de un firmware puede recibir primero un veredicto de confianza y, tras descubrirse una vulnerabilidad, otro de desconfianza. Ambos Endorsements pueden proceder de un Endorser que permanece en buena situación. rim-validity acota el contenido para decidir cuál se aplica.

La posición del Endorser forma otra dimensión. Su clave, certificado o trust anchor pueden dejar de ser aceptables. signature-validity acota la firma; el procesador CoRIM citado comprueba esa ventana junto con revocación y trust anchor al evaluar. El texto no convierte T2 en regla universal: cada protocolo o política debe documentar el punto que elija.

En realidad hay tres trayectorias: el valor del Environment, la valoración que hace el Endorser y la situación del propio Endorser. Una interfaz que las resume en «válido» puede ocultar por qué dos Verifiers correctos llegan a resultados distintos.

El merge tiene evidencia, pero no tiene el mandato del IESG

El diff, los revisores y el commit de fusión son comprobables. La página resultante se identifica, sin embargo, como draft-ietf-rats-endorsements-latest. No es revision 10 ni RFC. El documento numerado 09 que figura en la última llamada no contiene los párrafos.

Ese desfase es normal: los Internet-Drafts son documentos de trabajo y el editor necesita integrar comentarios antes de subir una revisión. El error aparece cuando se pierden los calificadores. «Los editores fusionaron la solución», «el Working Group remitió la versión 09» y «el IESG autorizó la publicación» pertenecen a autoridades distintas. Hoy hay prueba de las dos primeras, referidas a instantáneas diferentes; no la hay de la tercera.

La prueba de blanqueo de mandato de Heng Lu sirve aquí sin metáfora adicional. GitHub puede acreditar los bytes aceptados por los editores, no fabricar la resolución del IESG. Del mismo modo, el rango oficial de la revisión 09 no borra el hecho de que la fuente ya mejoró. La gobernanza rigurosa conserva ambas verdades y el enlace que falta entre ellas.

Un recibo para cada salto de estado

Mail Archive, GitHub, la copia editorial y Datatracker contienen las piezas. Un recibo breve puede convertirlas en una cadena sin añadir un nuevo órgano de aprobación.

Debe empezar por la URL estable del comentario, fecha, autor, sección y revisión afectadas, y una disposición explícita: aceptado, aceptado en parte, respondido por mecanismo existente, aplazado o rechazado. A continuación enlaza la respuesta del editor, issue o pull request, commits de cabeza y merge, revisores, hora de fusión y una descripción limitada de lo que cambió y lo que no.

La parte formal identifica la primera revisión numerada que contiene la corrección, el estado posterior del IESG y el RFC, si llega a existir. Para la cuestión de los relojes añade la ventana de contenido, la de standing, T1, T2, el propietario de la política que escoge y la identidad del Verifier o de la versión de política necesaria para interpretar la salida.

El recibo debe terminar con una no conclusión. Un comentario atendido no es consenso de toda la IETF. Un merge no es permiso de publicación. Una firma válida no prueba por sí sola la verdad de la claim, la competencia institucional del Endorser ni la confiabilidad del dispositivo.

No hace falta publicar deliberaciones privadas. Enlaces, hashes, roles, tiempos y estados públicos bastan. El recibo no suplanta la lista, a los editores, al grupo ni al IESG. Impide que una capa se vista con la autoridad de la siguiente.

Fuentes