Resumen

  • La revisión 03 da a cada referencia tipada uno de cuatro resultados: Malformed, Unresolved, Failed o Verified. Admitir la estructura no demuestra todavía que el artefacto citado haya sido obtenido y comprobado.
  • Verified exige seleccionar exactamente un contexto de resumen autorizado por el perfil, recuperar el artefacto, ejecutar la construcción declarada y comparar en la representación prevista.
  • La firma, la autenticación del emisor, el recibo SCITT, la evaluación del artefacto y la autorización operativa conservan pruebas y responsables distintos.

Lo que cambió el 5 de septiembre

Steven Mih y Anton Sokolov publicaron el 5 de septiembre de 2026 la revisión 03 de Canonical Payload Binding: A Signed Statement Construction Profile. El Datatracker la registra como un Internet-Draft individual activo. Sus autores señalan SCITT como grupo de trabajo previsto, pero el documento no tiene stream del IETF, AD responsable, decisión de adopción ni consenso declarado. Puede cambiar, ser sustituido o caducar.

Esa condición importa porque el borrador no es una noticia de despliegue. Su interés está en haber hecho explícito un problema de implementación que suele quedar escondido detrás de la palabra “verificado”. Frente a -02, la revisión separa el mecanismo neutro de CPB de los perfiles de carga, convierte la referencia tipada en un modelo de información de cuatro miembros y permite que cada perfil defina su propio transporte. También ofrece cpb-refs como transporte opcional en el encabezado protegido de COSE.

La revisión abandona la idea de un registro universal de tipos de artefacto dentro de CPB. El perfil consumidor debe definir mediante una referencia normativa estable qué tipos y contextos de resumen admite. Distingue además el modo Full-Payload de RFC 9943 del Hash Envelope de RFC 9995, prohíbe mezclar dos transportes de referencia en el mismo Signed Statement y nombra cuatro estados de procesamiento que antes podían colapsar en un booleano.

Cuatro estados, cuatro hechos diferentes

Malformed es un rechazo de admisión. Falta un miembro obligatorio, aparece un tipo CBOR incorrecto, se supera un límite, hay una clave duplicada, se repite el mismo cuádruple o surge una clave desconocida en el mapa cerrado. En cpb-refs, las claves distintas de 1, 2, 3 y 4 no son extensiones tolerables. Una entrada mal formada impide certificar selectivamente otra entrada del mismo encabezado como Verified, aunque el resultado de la firma se pueda informar por separado.

Unresolved aparece después de que la sintaxis haya pasado. El verificador no puede elegir exactamente un contexto permitido por el perfil; o sí puede elegirlo, pero no logra obtener el artefacto; o dispone de ambos y carece de la construcción necesaria. No se ha probado una discrepancia. Tampoco se ha probado una vinculación. Un corte de red y una política normativa ambigua no son el mismo incidente, pero ambos deben permanecer visibles bajo el estado que indica que la pregunta sigue abierta.

Failed requiere haber avanzado más. Existe un contexto único, pero el algoritmo o la representación no son compatibles con él, el identificador está definitivamente sin asignar o prohibido, o el cálculo sobre el artefacto obtenido no coincide con el valor declarado. Si una plataforma convierte Failed en Unresolved, pierde la evidencia de una diferencia material. Si convierte Unresolved en Failed, culpa al contenido por una incapacidad de recuperación, de implementación o de gobierno.

Verified cierra una cadena concreta: contexto autorizado, artefacto obtenido, selección y exclusión de campos, canonicalización, separación de dominio cuando corresponda, codificación del preimage, función de resumen, representación de salida y comparación igual. Su afirmación es deliberadamente estrecha: ese artefacto quedó vinculado a esa referencia bajo ese contexto. No dice que el artefacto sea verdadero, vigente, seguro o utilizable.

SHA-256 no es un contexto de resumen

El nombre del algoritmo solo describe una parte de la construcción. Un digest context incluye qué campos entran, cuáles se excluyen, qué canonicalización se aplica, si hay separación de dominio, cómo se codifica el preimage y en qué representación se produce el resultado. Dos cadenas hexadecimales iguales solo son una unión probatoria si todo ese contexto también coincide.

La selección empieza con type y, cuando sea necesario, purpose. Si el perfil admite un único contexto para un tipo, purpose puede faltar; si está presente, debe coincidir. Si admite varios, cada uno necesita un purpose distinto y no vacío, y la referencia debe seleccionar uno. Cero coincidencias o más de una conducen a Unresolved.

El verificador no puede adivinar a partir del orden de una lista, la longitud del resumen, la forma de la carga, una costumbre del proveedor o una copia de un registro que el perfil nunca incorporó normativamente. RFC 8785 puede decirle a una biblioteca cómo canonicalizar JSON; no le dice qué campos decidió excluir una organización ni qué versión del perfil gobierna el statement.

Lo mismo vale para un identificador derivado incluido en la carga. El borrador lo trata como una pista. El verificador debe recalcularlo después de aplicar el conjunto normativo de exclusión y todas las transformaciones ordenadas. Copiar el valor emitido a una columna local llamada verified solo duplica una afirmación; no crea una observación independiente.

Un transporte, no una fusión de conveniencia

Cada perfil elige cpb-refs en el encabezado protegido o un transporte propio dentro de la carga. No puede usar ambos, aunque las listas apunten a objetos diferentes. Si un verificador consciente del perfil encuentra los dos, debe declarar el statement no conforme, no unirlos ni escoger el primero que vea su analizador.

La prohibición evita que una referencia de carga aparente corregir otra protegida, que los duplicados funcionen como votos o que dos implementaciones construyan grafos diferentes. Una sola superficie de entrada también permite que el recibo de admisión diga con claridad qué fue aceptado.

En el transporte de encabezado, cpb-refs vive únicamente en el encabezado protegido. El array contiene entre una y 64 referencias. Cada mapa cerrado asocia claves enteras con type, purpose opcional, digest_alg y digest, además de límites de longitud y cantidad. Las claves duplicadas deben detectarse antes de convertir el CBOR a una estructura que las descarte. No hay margen para políticas first-wins, last-wins, éxito parcial o ponderación por repetición.

El CDDL restringe el modelo de datos, pero no impone una sola serialización CBOR. Un vector de prueba puede fijar bytes exactos para reproducibilidad. Una implementación conforme no debe rechazar otra codificación CBOR válida solo porque no coincide byte a byte con el fixture. Esa cuestión dialoga con la cobertura previa sobre las múltiples codificaciones CBOR, pero aquí el centro es distinto: cómo una referencia admitida llega —o no— a ser una vinculación externa comprobada.

Recuperar y representar también son decisiones

Treinta y dos bytes crudos, una cadena hexadecimal minúscula de 64 caracteres y una forma con prefijo son representaciones diferentes. Convertir silenciosamente entre ellas no es una ayuda inocua. Solo es válido cuando la especificación o el perfil define la conversión y la representación en la que se realiza la comparación.

La obtención del artefacto tiene además su propia temporalidad. Con un contexto único y un objeto inaccesible, el resultado es Unresolved. Una caída de red, un permiso denegado, una laguna de retención o un esquema de recuperación no implementado no prueba que el digest sea incorrecto. Un reintento puede resolver la referencia más tarde sin cambiar el Signed Statement; el registro de auditoría debe conservar ambas observaciones y sus fechas.

Si una instalación entiende el contexto pero no puede ejecutarlo, la decisión pasa a la política local: derivar el trabajo a un verificador capaz, aplazarlo, instalar una capacidad aprobada o rechazar. Lo que no puede hacer es reutilizar la luz verde producida por otro componente sin importar también su contexto, entrada, versión y recibo.

La firma no responde por toda la cadena

Como cpb-refs está en el encabezado protegido, una firma COSE válida cubre su integridad. Esa cobertura no demuestra que la clave estuviera autorizada para hablar por el supuesto emisor. La revisión separa por eso Signature-Valid de Issuer-Authenticated; el segundo resultado depende de la política local de claves e identidad.

Un statement con firma válida puede contener una referencia Unresolved o Failed. Una coincidencia de resumen tampoco repara una firma inválida ni autentica al autor. Las API y las consolas de operación deberían mostrar el resultado de firma y el resultado de cada referencia como campos separados, no como una puntuación o un color general.

El recibo SCITT prueba otra cosa. RFC 9943 define cómo un Transparency Service registra un statement y emite un receipt gobernado por una verifiable data structure. Para basarse en él hay que verificarlo con una clave de servicio confiable y leer el identificador VDS en su encabezado protegido. Registrar el statement no recupera el artefacto citado y no convierte por sí solo Unresolved en Verified.

Incluso Verified deja fuera la autoridad del emisor, la vigencia, el alcance, la revocación, la semántica, la conformidad de política y el permiso de ejecutar una acción. El perfil del artefacto decide qué significa la coincidencia. La organización que soporta la consecuencia decide qué hacer con ella.

Integridad visible no equivale a confidencialidad

El encabezado protegido de COSE queda protegido contra modificación cuando la firma se valida; no está cifrado. cpb-refs revela tipos, purposes, algoritmos, valores de digest y la forma del grafo de referencias. Valores estables facilitan la correlación entre statements. Un artefacto de baja entropía puede admitir búsquedas por diccionario.

Si esa exposición no es aceptable, el borrador aconseja omitir cpb-refs o definir en el perfil un transporte confidencial dentro de la carga. Esa elección ocurre antes de distribuir el statement. Añadir después un control de acceso en la interfaz no retira un grafo ya replicado.

Una solicitud a IANA todavía no es una asignación

La revisión 03 solicita un registro de algoritmos de canonicalización y un parámetro COSE para cpb-refs. Son solicitudes del borrador, no evidencia de que IANA haya creado esas coordenadas. Un piloto responsable debe fijar revisión, valores provisionales y plan de migración, y no presentar un número experimental como si fuera estable.

Aquí encaja la idea de Heng Lu sobre una especificación inicial mínima. La capa compartida solo necesita hacer reproducible un hecho pequeño: se aplicó un contexto declarado a un artefacto obtenido y la comparación produjo un resultado. Los perfiles y las organizaciones pueden decidir después significado, vigencia y uso. El running code cuenta cuando conserva bytes, decisiones y recibos suficientes para que otra parte pueda repetir la observación.

Límites de esta lectura

Este análisis no afirma adopción por el IETF, consenso de SCITT, acción de IANA, soporte de producto ni despliegue operativo. Los ejemplos del apéndice no prueban interoperabilidad general. No se probaron servicios, bibliotecas, registros, incidentes, exploits, rendimiento ni prevalencia.

La canonicalización tampoco hace que una carga sea correcta o segura. Los cuatro estados describen una prueba limitada. Firma, identidad del emisor, recibo, vinculación, evaluación, decisión local y efecto observado siguen separados porque pertenecen a responsables distintos.

Fuentes