Resumen

  • draft-mih-scitt-checkpointed-local-log-01 compromete un registro privado mediante checkpoints de una Merkle Mountain Range, pero la consistencia sólo demuestra que la rama presentada amplía su propio pasado.
  • Para detectar equivocar historiales hace falta un testigo independiente que conserve el último checkpoint aceptado para la misma identidad. El registro SCITT ordinario acredita inclusión, no continuidad automática.

La trampa aparece cuando un sistema conserva recibos firmados y alguien pregunta si falta alguno. Verificar cada firma no responde. Ordenar los archivos por fecha tampoco. Un operador puede borrar una decisión incómoda, reconstruir la carpeta y presentar una colección plausible.

El Checkpointed Local Log propone añadir los resúmenes de esos registros a una Merkle Mountain Range. Los datos permanecen en manos del productor; un checkpoint firmado compromete la cantidad de entradas y el acumulador. Publicar ese objeto pequeño permite supervisión sin entregar miles de registros privados.

Sin embargo, un checkpoint correcto no hace único el historial.

Dos extensiones correctas pueden contradecirse

Cada checkpoint enlaza su estado actual con prev_size y prev_commitment. Una prueba de consistencia permite comprobar que las entradas ya incluidas en esa rama no se cambiaron. Es una garantía importante: dentro de lo que se muestra, la historia no fue reescrita.

El productor aún puede mantener A y B. A2 amplía A1 con una prueba válida; B2 amplía B1 con otra. Un auditor recibe A y no ve nada roto. Otro recibe B y tampoco. La criptografía verifica la relación presentada, no una relación que el auditor desconoce.

La defensa está fuera del productor. Un testigo consciente de checkpoints guarda el último estado que aceptó para la pareja formada por emisor e identificador del registro. Cuando llega el siguiente checkpoint, exige que su predecesor coincida. Si no coincide, debe rechazarlo y tratar la diferencia como evidencia de mutación. Reintentar hasta que pase destruiría precisamente la señal que el control fue diseñado para producir.

Así, la continuidad depende de memoria persistente y de una negativa vinculante. Una firma sin ese estado no puede reemplazarlas.

Inclusión bajo una clave no equivale a continuidad

La propuesta reutiliza SCITT. El checkpoint se registra como Signed Statement y el servicio devuelve un Receipt COSE. El recibo prueba que el servicio incluyó aquel objeto bajo su clave. Sólo prueba una hora si incorpora una afirmación temporal firmada.

Un Transparency Service puede desconocer CLL y aceptar el objeto como cualquier otra declaración. Su Receipt continúa siendo útil, pero no significa que el servicio comparó el predecesor con el último checkpoint que había aceptado para ese registro. Esa semántica adicional exige un servicio consciente de checkpoints y con estado.

La diferencia no es terminología. En una investigación, “estaba registrado” responde quién incluyó qué objeto. “Era continuo” responde si ese testigo vio una extensión del mismo pasado que había custodiado. Son consultas y responsabilidades distintas.

La contresignatura directa exige la misma comparación. En cambio, un marcador local de pruebas no constituye testimonio. La revisión 01 pospone el formato stub porque no existe una implementación distribuida que produzca la estructura RFC 9338 imaginada. Es preferible declarar trabajo futuro que normalizar evidencia ficticia.

La independencia debe sobrevivir al organigrama

La propuesta obliga a nombrar a los testigos. Si el productor opera también al testigo, éste es una réplica. Puede conservar copias y mejorar disponibilidad, pero la autoridad capaz de crear ambos historiales controla también la memoria que debería denunciarlos.

Consultar varios testigos independientes reduce la posibilidad de equivocar: el productor necesita mantener particionado a todo testigo que consulte el verificador. El beneficio depende de que no compartan control, de que retengan su estado y de que el verificador los consulte de verdad. “Tres testigos” en una misma cuenta administrativa puede ser una sola frontera disfrazada.

El límite temporal también debe verse. Las entradas posteriores al último checkpoint presenciado siguen siendo no presenciadas. Un Receipt de ayer no cubre la cola de hoy. Declarar una cadencia máxima vuelve detectable una ausencia, aunque la ventana de retrodatación aún incluya la cadencia y la latencia del testigo.

El compromiso describe la forma del historial

El testigo recibe compromisos, no registros. Puede respaldar inclusión, extensión coherente y completitud de un intervalo bajo un checkpoint. No puede buscar ni servir por sí solo una decisión individual. Otro custodio debe aportar los bytes y la prueba de inclusión.

Si el segmento fue archivado y ya no puede recuperarse, el compromiso demuestra que hubo una entrada, pero no reconstruye el contenido. La revisión propone una negativa honesta —retención vencida— en vez de afirmar que nunca existió.

Tampoco verifica la verdad. Un registro perfectamente presenciado puede contener mentiras firmadas. La autorización del emisor, la ejecución, el efecto observado y la suficiencia de la política requieren otras pruebas. CLL tampoco demuestra que éste sea el único registro del productor ni que todas las decisiones creadas fueran añadidas.

La revisión 01 endurece la interoperabilidad del checkpoint: la lista de picos MMR en CBOR canónico es la representación de red. Una raíz plegada puede mantenerse como optimización privada, pero el plegado no está estandarizado y no debe viajar en commitment. El texto menciona convergencia de implementaciones, no aporta un informe independiente de pruebas. Además sigue siendo un Internet-Draft individual sin estatus formal en el IETF.

Fuentes