Summary

  • draft-sirkkavaara-vaara-receipt-12 incorpora a cada frontera un seq y un runningCount firmados; si aparece un recibo posterior, la ausencia de un número intermedio queda expuesta.
  • Los registros 0..k pueden ser una historia completa o un prefijo al que se le quitó todo el sufijo. El sello terminal fija N, pero también puede desaparecer junto al tramo final.
  • Un anclaje RFC 3161 del conteo de cierre aporta custodia temporal externa. No sustituye la cobertura, la validez actual de la clave, el recibo de ejecución ni la observación del efecto.

El fraude sin huecos

Es fácil imaginar la anomalía que una secuencia detecta. Un servicio autónomo emite recibos 0, 1, 2, 3 y 4; alguien borra el 2 y entrega los demás. El runningCount del 4 dice que deberían existir cinco piezas, de modo que el salto queda a la vista.

El caso serio es más silencioso. El servicio llega hasta 9, pero el auditor recibe sólo 0..4. El recibo 4 afirma que se habían emitido cinco y el expediente contiene cinco. Cada firma es válida. No hay salto, duplicado ni contador incompatible. La omisión se produjo después del último objeto visible, en un lugar que ese objeto no podía anticipar.

La revisión 12 de Vaara Receipt no oculta esta limitación. Define una construcción por capas para que una auditoría sepa qué ha demostrado: primero el ámbito observado; después la integridad de cada decisión; luego los huecos internos; más tarde el cierre; por último, una evidencia externa de que el cierre existía.

Una frontera antes que un contador

El bloque opcional de cobertura nombra el punto de control y la superficie de capacidades o comandos que éste observaba. Su declaración es modesta: cubre las llamadas que pasaron por allí. Una invocación directa, un segundo gateway o una ruta local quedan fuera.

Sin esa frontera, “no hay recibo de rechazo” sólo significa “no aparece en este conjunto”. Incluso con ella, significa “no fue rechazado dentro de esta cobertura”, no “la acción no sucedió en ningún lugar”. Contar piezas sin fijar primero el universo observado convierte la precisión aritmética en una falsa exhaustividad.

El bloque de completitud firma boundaryId, una secuencia creciente desde cero y runningCount = seq + 1. Cuando existe una pieza posterior, su contador acusa una eliminación previa. El valor operativo está en ese vínculo: un registro presente establece cuántos registros anteriores reclama el emisor.

Sellar el total

El registro de cierre puede declarar {sealed: true, total: N}. Si el auditor lo conserva, el final deja de ser implícito. Un conjunto con menos de N piezas es incompleto aunque termine sin salto. El sello puede añadir maxClass para indicar la clase más alta de acción autorizada dentro de la frontera y limitar el peor caso de un hueco.

Sin embargo, el sello no cae del cielo. Lo emite el mismo sistema de registros y puede desaparecer con el sufijo. Si se eliminan las últimas decisiones y la pieza que fijaba N, el prefijo restante sigue siendo criptográficamente honesto acerca de su propio pasado. Es imposible deducir un futuro borrado a partir de bytes anteriores que eran válidos.

Por eso el borrador coloca un anclaje RFC 3161 sobre el conteo final. El objetivo no es volver más verdadera cada decisión, sino trasladar a otra custodia la afirmación de que a la hora T existía un conteo N. Cuando el portador enseña k, el auditor dispone de una expectativa que no nació dentro del prefijo reducido.

La independencia no viene incluida en el nombre del estándar. Una autoridad de sellado de tiempo gestionada por el mismo operador puede producir un token sintácticamente correcto y seguir formando parte del mismo dominio de ocultación. Hay que registrar quién controla la autoridad, qué clave se acepta, qué política valida el tiempo y dónde se conserva la respuesta.

Registro transparente y tiempo no son sinónimos

La propuesta también permite registrar la declaración en un servicio SCITT. Ese recibo de transparencia compromete la declaración que fue registrada. El borrador lo trata como evidencia complementaria, transportada junto al recibo, no como otra entrada en timestampAnchors.

La diferencia importa cuando un proveedor promete “trazabilidad”. RFC 3161 vincula una huella con una afirmación temporal. SCITT vincula una declaración con el acto y la política de registro. La secuencia identifica huecos anteriores. El sello fija el total terminal. RFC 9162 recuerda que incluso un log transparente separa prueba de inclusión y prueba de consistencia. Ninguna etiqueta genérica reúne automáticamente esas propiedades.

La recomputación conserva una afirmación, no garantiza su mundo

JCS, definido en RFC 8785, permite que productor y auditor reconstruyan los mismos bytes JSON antes de firmar o calcular una huella. Los vectores públicos del proyecto prueban que otro verificador puede recalcular enlaces, firmas y casos de completitud sin cargar la biblioteca del emisor. Eso es running code pertinente.

El hash idéntico demuestra identidad de contenido, no veracidad. La firma demuestra qué clave emitió la afirmación, no que la clave siga vigente. El propio texto reconoce que no define revocación ni frescura. La política local debe aportar resolución de claves, tolerancia de antigüedad y conservación del registro de evidencia.

Tampoco debe mezclarse decisión con ejecución. Un recibo allow dice que se autorizó una acción. El recibo de ejecución posterior puede enlazar el predecesor, declarar executed o refused y comprometer un resultado. Aun así, la observación del efecto en el sistema externo tiene su propia fuente y su propio responsable.

Las capas de realidad de Lu Heng ofrecen la disciplina correcta: representación, decisión, operación y resultado no se vuelven equivalentes por compartir una firma. Una especificación inicial puede ser estrecha y útil; las decisiones futuras sobre custodia, cierre y consecuencia deben seguir localizadas. Los vectores ejecutables prueban interoperabilidad de la construcción, no completitud del mundo observado.

Sources and limits

Estas fuentes establecen una Internet-Draft individual activa y documentos públicos relacionados. No prueban consenso IETF, RFC de Vaara Receipt, adopción por un grupo, auditoría independiente, despliegue amplio, cobertura exhaustiva, autoridad temporal independiente ni resultado operativo. Este artículo se limita al borde entre hueco interno, final sellado y anclaje externo de la revisión 12.