Resumen

  • draft-nikolaichuk-scitt-continuity-receipts-01 propone registrar una declaración firmada sobre la recuperación de un activo con la arquitectura SCITT y obtener un Receipt COSE conforme a RFC 9942.
  • HTTP 202 y un identificador de entrada muestran que el servicio aceptó un proceso asíncrono, no que ya exista el Receipt. Si el activo se entrega antes, la recuperación sigue sin testigo hasta que la prueba se resuelva.
  • El Receipt acredita el registro de una afirmación atribuible y ordenada; no acredita que la recuperación ocurrió, que la atestación fue favorable ni que el resultado sea idéntico o equivalente.

Cuatro verbos detrás de una sola pantalla

Recuperar es producir de nuevo un activo desde material sellado. Atestiguar es reunir y evaluar evidencia sobre el entorno que ejecutó ese trabajo. Registrar es colocar una afirmación firmada en un servicio de transparencia. Liberar es permitir que un consumidor actúe con el resultado.

Ninguno de esos verbos contiene a los otros. Sin embargo, un sistema de continuidad puede mostrar «restaurado» cuando sólo terminó el primero; «verificado» cuando encontró un objeto de atestación; o «registrado» cuando recibió HTTP 202. La comodidad de la interfaz crea una autoridad que los hechos no conceden.

El Continuity Receipts, revisión 01 del 29 de septiembre de 2026, intenta preservar esas fronteras. Es un Internet-Draft individual con estado previsto Informational, no una adopción del grupo SCITT ni una RFC. Su formato sitúa una Recovery Statement firmada dentro de la arquitectura de RFC 9943 y usa Receipts de RFC 9942 para probar la inscripción en un registro append-only.

Su pregunta operativa es sencilla: si el activo ya existe pero la inscripción todavía no tiene Receipt, ¿quién decide abrir la puerta?

Del entorno al consumidor

El recorrido propuesto empieza con Evidence producida por el Attester del entorno de recuperación. Un Verifier la valora y emite Attestation Results. Otro mecanismo toma la decisión de liberar el material criptográfico sellado. Con él, el entorno descifra, recompone el activo y calcula recovered-digest sobre el texto claro realmente obtenido.

La Recovery Authority crea después los claims, identifica el activo como subject y firma la declaración. El Transparency Service decide si admite al emisor y al formato según su Registration Policy, agrega la declaración al registro y entrega un Receipt. El Relying Party verifica lo que necesite antes de consumir el activo.

La cadena no convierte a ningún actor en notario universal. Quien libera una clave no observa necesariamente el resultado. Quien firma puede estar muy cerca de la operación y seguir siendo parte interesada. El registro ve una declaración, no el trabajo físico. El consumidor conserva su propia obligación de aceptar o rechazar.

Esta distribución encaja con la idea de una especificación mínima de Lu Heng: el plano común puede fijar el sobre, la atribución y la prueba de inclusión. No debe absorber decisiones locales sobre fidelidad, riesgo o disponibilidad que pertenecen a quien sufrirá el efecto.

La prueba tiene un objeto exacto

Según el borrador, un Continuity Receipt prueba exactamente que una Recovery Statement concreta, firmada por un Issuer concreto, fue registrada en un Transparency Service concreto, en una posición concreta de su registro, y que el servicio firmó una prueba de ese hecho.

No prueba que el evento sucediera. No compara el resultado con el activo original. No demuestra que los Attestation Results fueran verificados ni favorables. No confirma que el entorno se encontrara en el estado descrito. Tampoco implica que la política de registro examinara esos elementos.

El matiz no reduce la utilidad del Receipt. Hace que la afirmación sea permanente, atribuible, ordenada y resistente a una retirada silenciosa. Eso permite descubrir contradicciones y asignar responsabilidad. El error aparece cuando la interfaz añade conclusiones que el servicio nunca midió.

Por eso el verificador debe mostrar por separado las afirmaciones del emisor, los hechos establecidos de manera independiente y los puntos que no pueden verificarse. Una sola bandera «válido» no es un resumen; es pérdida de información.

El hueco entre 202 y Receipt

SCRAPI admite el registro asíncrono. El servicio puede responder 202 con un identificador y publicar el Receipt más tarde mediante el recurso de entrada. El identificador habilita el seguimiento, pero no es una prueba de inclusión.

La revisión 01 obliga al emisor a escoger conscientemente. Puede bloquear la liberación hasta obtener el Receipt. O puede seguir adelante y registrar la recuperación como unwitnessed. Lo que no puede hacer es llamar Receipt al 202.

Este detalle altera la gobernanza de continuidad. Un objetivo agresivo de recuperación puede justificar que una infraestructura esencial no espere a un testigo temporalmente caído. En tal caso hacen falta una autoridad de excepción, consumidores delimitados, una caducidad, controles compensatorios y una reconciliación obligatoria. Sin esos campos, la presión por restaurar convierte una excepción de disponibilidad en una norma sin dueño.

Un identificador guardado junto al expediente sólo promete que habrá algo que consultar. La frase central del borrador es acertada: sin Receipt a su lado, sigue siendo promesa, no prueba.

El resultado debe medirse desde abajo

recovered-digest se calcula sobre los bytes de texto claro producidos al final del evento. No puede copiarse del valor esperado en una ficha de backup. El valor esperado sirve para comparar; no sirve para afirmar qué salió de la máquina.

La identidad del entorno exige la misma disciplina. Una medición se conserva con su algoritmo y longitud nativos. El borrador documenta que la implementación adyacente trunca a 32 octetos dos mediciones SHA-384 de 48 octetos de AWS Nitro y AMD SEV-SNP. Aunque el campo siga pareciendo un hash, ya no coincide con el objeto que compara el motor de política.

La primacía del código en ejecución no significa creer cualquier salida del programa. Significa anclar la afirmación en los bytes y medidas que la ejecución produjo, conservando la representación necesaria para volver a comprobarla.

Atestación: presencia, resultado y frescura

Los Attestation Results pueden aparecer como referencia, incorporarse a la declaración o registrarse por separado. Referenciar reduce exposición, pero la verificación futura depende de conservar exactamente esos bytes. Incorporar mejora la disponibilidad a costa de publicar más detalles. Registrar por separado ofrece otro Receipt, con otra posición y otra dependencia.

La frescura puede basarse en nonce, epoch ID, timestamp o none. none declara que la Evidence no se vinculó a un desafío y puede reproducirse. No es equivalente a «falló», pero tampoco permite al consumidor fingir actualidad.

Además, un resultado de atestación puede ser auténtico y desfavorable. La existencia del documento, la verificación de su firma, su frescura y su valoración son cuatro comprobaciones distintas.

Tres grados de equivalencia

Si el campo equivalence falta, significa none. byte-identical requiere igualdad entre el digest observado y el digest del texto claro registrado durante el sellado. operational requiere una prueba definida y referenciada: cargar, arrancar o responder a un health check. El propio texto la considera una afirmación débil.

No existe valor para equivalencia semántica o de comportamiento. Esa ausencia evita certificar que una base conserva todos sus registros porque el proceso arrancó, o que un modelo conserva su conducta porque pudo cargarse. Los sistemas con estado no reducen su identidad a la disponibilidad de un puerto.

El Receipt y la equivalencia recorren ejes distintos. El primero puede ser válido aunque la equivalencia sea none; una igualdad byte a byte también puede medirse antes de que exista el Receipt.

Dos órdenes, dos preguntas

El campo prev-event enlaza recuperaciones sucesivas bajo un subject y expresa la genealogía afirmada por el Issuer. El registro append-only ofrece orden global de inscripción. No dice que dos entradas sean la misma historia; la cadena no dice que su secuencia sea el orden global completo.

Si aparece un hueco, el verificador debe mostrarlo. Quizá el emisor desconocía un evento intermedio; quizá decidió no reconocerlo. Reparar la secuencia borraría precisamente la discrepancia que un auditor necesita ver. Los identificadores de entrada y los índices localizan; el digest de la declaración previa enlaza criptográficamente.

En una cadena repartida entre varios servicios, el orden deja de componerse. Cada servicio demuestra su propio árbol. Para conservar la continuidad durante años también se necesitan Receipts de consistencia entre raíces, no sólo una inclusión en una raíz aislada.

Privacidad y capacidad de aplicar política

Adjuntar los claims permite que el servicio examine su contenido, pero puede revelar el identificador estable del activo, frecuencia de recuperación, región, proveedor o hardware. Desprender el payload reduce esa exposición. También impide que la Registration Policy evalúe claims que el servicio no recibe y obliga al consumidor a buscarlos por un canal lateral.

Pseudonimizar el subject dificulta la correlación pública, pero rompe la unión entre custodios, crea un secreto duradero y divide la cadena cuando rota. La privacidad cambia lo que será verificable; no es una capa decorativa.

Un prototipo contiguo, no una implementación

El borrador declara que el código de referencia asociado no implementa la especificación. No emite COSE Receipts de RFC 9942, usa otros mecanismos de encadenamiento, deja incompleta la comprobación de atestación y carece de nonces. Su reconstrucción es una cadena de Markov determinista de orden 3 sobre bytes, no una validación semántica.

La separación importa: el documento propone; el código demuestra algunas operaciones adyacentes; ninguna fuente prueba despliegue o interoperabilidad. El nombre de un repositorio no debe ascender de capa por sí solo.

Fuentes y límites

Estas fuentes describen una propuesta en curso, arquitecturas publicadas y las limitaciones declaradas de un código adyacente. No prueban un despliegue, incidente, ataque, recuperación real, adopción, interoperabilidad ni equivalencia semántica. El expediente de liberación que sigue es análisis de Daniel Kade, no una obligación ya normalizada.