Resumen

  • La revisión 04 del perfil de recibos CCF para SCITT incluye la hoja y una ruta de hashes hermanos con indicaciones izquierda/derecha, pero no incluye el tamaño del árbol ni un índice de hoja explícito.
  • La inclusión continúa siendo verificable. El límite aparece después, cuando una aplicación interpreta la raíz válida como prueba de orden, secuencia o posición.

No hace falta imaginar un árbol enorme. La ruta 1, con un solo paso desde la hoja hacia la raíz, corresponde al índice 1 si el árbol tiene dos hojas. Si el árbol tiene tres, cinco o nueve, esa misma ruta corresponde a los índices 2, 4 u 8. Sin conocer el contorno del árbol, el bit no identifica una coordenada única.

El hallazgo llegó durante la última llamada del IETF sobre CCF Profile for COSE Receipts, revisión 04. El registro del Datatracker lo sitúa en el flujo IETF, con Proposed Standard como nivel previsto, enviado al IESG y todavía “In Last Call”. La consulta empezó el 24 de agosto y termina el 7 de septiembre de 2026. Sigue siendo un Internet-Draft: no es un RFC ni una aprobación o rechazo consumados.

Verificar una raíz no asigna una coordenada

El perfil construye el árbol con una regla heredada de Certificate Transparency. Cuando hay más de una hoja, divide en la mayor potencia de dos inferior al tamaño total. Los tamaños 2, 4, 8 y sucesivos forman árboles equilibrados. Entre ellos aparecen subárboles derechos más pequeños.

La sección 3 representa la prueba mediante la hoja candidata y una lista de hashes hermanos. Cada uno lleva un booleano que indica si queda a la izquierda. El borrador afirma que esas direcciones pueden leerse como la descomposición binaria del índice, avanzando desde la hoja. La afirmación describe bien los árboles equilibrados, pero no todas las formas que produce la propia regla de división.

El 6 de septiembre, Henri Sirkkavaara corrigió su primera revisión tras probar tamaños del 2 al 11. Todos los tamaños que no eran potencias de dos mostraron al menos una hoja cuyo camino producía un índice ordinal equivocado. En 2, 4 y 8 no hubo discrepancias.

Emek Can Dogru repitió el análisis de manera independiente y publicó un programa de once líneas. Al extender la enumeración hasta 1.024 hojas, sólo las diez potencias de dos acertaron para todas sus hojas; 1.013 tamaños presentaron al menos un caso erróneo. El código exacto de la reproducción permite inspeccionar el mecanismo sin convertirlo en una afirmación de ataque.

En un árbol de tres hojas, la hoja 2 se lee como 1. En uno de cinco, la 4 también se lee como 1. En uno de nueve ocurre lo mismo con la 8. La ambigüedad no depende del azar ni de romper un hash; deriva de intentar recuperar una posición global con información local de la ruta.

La verificación definida en la sección 3.2 sigue funcionando. El verificador toma el hash de la hoja candidata, lo combina con cada hermano en el lado indicado y obtiene una raíz. Si la firma COSE cubre esa raíz, la inclusión de la candidata queda validada. No es necesario conocer su número ordinal para realizar ese cálculo.

La prueba responde “esta candidata está incluida bajo esta raíz firmada”. No responde necesariamente “esta candidata era la hoja número x”. Son afirmaciones distintas, aunque una interfaz pueda comprimir ambas en una luz verde.

Los antecedentes conservan el sistema de coordenadas

RFC 9162, Certificate Transparency versión 2, verifica una inclusión recibiendo expresamente el tamaño del árbol y el índice de la hoja. RFC 9942, que define un perfil de recibo COSE para ese árbol, codifica ambos y explica que el índice es relativo a un tamaño concreto.

Esos campos no son decoración. Delimitan el espacio en el que “posición” tiene sentido. Sin el tamaño, un índice queda incompleto. Sin tamaño ni índice, una secuencia izquierda/derecha puede corresponder a más de un lugar ordinal.

Una implementación CCF puede disponer de contexto adicional. La documentación oficial de verificación obtiene el recibo para un identificador de transacción, y la evidencia de compromiso puede contener el TxID completo. El perfil SCITT también incluye internal-evidence, una cadena que el verificador puede ignorar y que no se define como gramática interoperable de posición. El contexto externo ayuda a una instalación; no convierte la prueba en autosuficiente para otra.

Por eso no estamos ante una falsificación, una colisión ni una raíz inválida. Los dos participantes calificaron el punto de no bloqueante y mantuvieron su apoyo a la publicación. En su último mensaje, Sirkkavaara explicó que la longitud de la ruta tampoco basta sin el tamaño y favoreció un índice explícito.

El significado se amplía fuera del verificador

Los recibos acaban en políticas de versiones, registros de auditoría, sistemas de transparencia y automatizaciones. Algunas sólo necesitan saber que un objeto fue incorporado. Otras toman decisiones sobre qué apareció primero o qué elemento ocupó una posición. El mismo artefacto no puede sostener ambas clases de afirmación si no conserva las entradas de la segunda.

La especificación inicial mínima de Heng Lu sugiere el remedio adecuado: normalizar el mínimo común y dejar que cada sistema adopte garantías adicionales de forma explícita. Sus capas de realidad impiden que una relación matemática se convierta sin aviso en autoridad narrativa. La primacía del código en ejecución obliga a conservar las entradas que realmente produjo la luz verde.

El perfil no necesita fingir más de lo que ofrece. Para inclusión, la prueba actual conserva valor. Para orden, debe vincularse el tamaño del árbol o un índice explícito.

Fuentes

  1. Documento en IETF Datatracker
  2. Eventos del documento
  3. CCF Profile for COSE Receipts, revisión 04
  4. Anuncio de última llamada
  5. Corrección de Henri Sirkkavaara
  6. Reproducción de Emek Can Dogru
  7. Conclusión sobre el remedio
  8. Código de reproducción
  9. RFC 9162
  10. RFC 9942
  11. RFC 9943
  12. Verificación de recibos CCF
  13. Heng Lu: especificación inicial mínima
  14. Heng Lu: capas de realidad
  15. Heng Lu: primacía del código en ejecución