Resumen

  • RFC 9995 define un sobre COSE cuyo payload es el resultado de un hash; protege obligatoriamente el algoritmo y puede proteger además el tipo y una ubicación orientativa del preimagen.
  • La firma o el MAC se pueden validar sin poseer el objeto original. Ese éxito prueba el alcance criptográfico del sobre, no disponibilidad, igualdad de bytes, validez semántica, vigencia ni permiso de uso.
  • La autoridad operativa exige una cadena adicional: asociar la clave con identidad y propósito, recuperar con límites, recalcular y comparar, analizar y evaluar, autorizar la acción concreta y observar su consecuencia.

Pensemos en una organización que conserva artefactos regulatorios durante diez años. El día del depósito guarda una pequeña envoltura firmada con el hash y una URI. Años después, el primer repositorio ha cerrado; una copia aparece en un archivo institucional y otra en una restauración interna. La ruta histórica ya no manda. El resumen permite preguntar si alguna copia contiene exactamente los bytes atestiguados.

Ese desacoplamiento es la fortaleza de la RFC 9995, publicada en julio de 2026 en el Standards Track del IETF. La COSE Hash Envelope reduce el coste de transmisión y facilita la firma remota porque el servicio criptográfico maneja un digest pequeño en vez del preimagen completo. El ahorro no elimina el objeto; conserva su identidad criptográfica a distancia.

El error aparece cuando una interfaz convierte «firma válida» en «objeto verificado». En ese instante todavía puede no existir objeto local, la URI puede fallar y nadie ha calculado el hash de los bytes recuperados.

El payload es el digest, no el preimagen

El preimagen es la secuencia original de bytes. El digest es la salida del algoritmo aplicado a esa secuencia. RFC 9995 coloca el digest como payload de COSE. Así, la operación criptográfica puede cubrir el valor completo sin trasladar el archivo grande.

Hay una tercera posibilidad: las reglas normales de COSE permiten separar también el propio payload-digest del objeto serializado. Por tanto, «contenido separado» puede significar que falta el preimagen grande —el caso normal del Hash Envelope— o que además se suministra por otra vía el digest pequeño. Son estados distintos y deben producir trazas distintas.

La RFC 9052 define COSE_Sign1 y otras estructuras. La firma cubre los encabezados protegidos, los datos externos autenticados que determine la aplicación y el payload usado en Sig_structure. Los encabezados no protegidos quedan fuera. El preimagen ausente tampoco entra por referencia: lo que entra es su resumen.

Por eso puede haber una validación legítima aun sin conexión de red. También por eso esa validación no aporta utilidad directa del artefacto. El consumidor necesita obtener un candidato y probar su igualdad más tarde.

Las etiquetas describen la relación

payload_hash_alg, etiqueta 258, es obligatoria. Tiene que estar en el encabezado protegido y no puede estar en el no protegido. Selecciona el algoritmo que produjo el payload-digest.

preimage_content_type, etiqueta 259, es opcional y protegida. Describe el tipo de medios o Content-Format de CoAP de los bytes originales. No es la etiqueta COSE común content_type, número 3. Esta última hablaría del payload actual, es decir, del digest. RFC 9995 la prohíbe para que un consumidor no confunda el tipo del resumen con el tipo del objeto.

payload_location, etiqueta 260, es una cadena o URI opcional dentro de la protección. Sirve de pista para hallar el preimagen. Que la pista esté firmada demuestra su integridad dentro del sobre; no promete que el servidor exista, que la ruta siga controlada por la misma parte, que el contenido sea privado o que el verificador tenga permiso de buscarlo.

El registro COSE de IANA asigna nombres y valores estables. La RFC 8126 explica cómo las políticas de registro sostienen esa coordinación. Ninguna de las dos fuentes certifica una implementación o convierte un identificador en política de aceptación.

La RFC 8610 aporta la gramática CDDL usada para expresar la estructura. El esquema puede detectar un campo ausente o mal colocado; no descubre si el signatario tenía autoridad. La RFC 7252 aporta el espacio de Content-Format de CoAP: ayuda a elegir interpretación, pero un número de formato no valida sintaxis, contenido ni consecuencias.

Firma, identidad y facultad son tres pruebas

La comprobación criptográfica responde si la estructura protegida y el digest corresponden a la clave o secreto y a las entradas que el verificador aceptó. No responde por sí sola quién controla la clave ni para qué decisiones está habilitado.

RFC 9052 exige que la aplicación empareje la clave con la identidad correcta y compruebe la autorización de esa identidad. Una empresa puede tener claves diferentes para compilar, archivar, facturar y liberar. Incluso una sola clave puede cambiar de rol cuando termina un contrato o se revoca un servicio. La firma antigua no cambia; su uso permitido sí.

Los datos autenticados externos permiten ligar contexto, pero solo cuando el perfil define bytes exactos y ambos extremos los reproducen. No se puede inferir tenant, entorno, versión o finalidad desde un contexto vacío.

La RFC 9421 firma componentes HTTP seleccionados y requiere un perfil de aplicación para interpretar el resultado. Es una frontera adyacente, no una equivalencia. La Hash Envelope protege el digest y sus coordenadas; no firma una petición HTTP ni autoriza la operación que quizá siga.

Un informe auditable separa: estructura correcta, firma o MAC válidos, clave asociada, identidad vigente, propósito permitido y contexto coincidente.

La ubicación no es una orden de red

La URI puede ser útil sin ser obligatoria. El objeto quizá ya esté en caché, quizá llegue por un canal físico o quizá el verificador opere sin conexión. Si falta el preimagen, el sistema todavía no puede comparar ni extraer su función.

Seguir automáticamente cualquier ubicación desde un servicio privilegiado crea una superficie distinta. Puede alcanzar direcciones internas, reenviar credenciales, atravesar redirecciones, consumir ancho de banda o expandir datos comprimidos. Un firmante autorizado para declarar resúmenes no debe heredar por accidente el poder de dirigir conexiones del plano de control.

La RFC 9110 distingue recurso, representación, contenido, codificación y redirección HTTP. Una política de descarga debe limitar esquemas, orígenes, saltos, DNS/TLS, credenciales, tiempo, bytes y expansión; conservar la procedencia final; y aislar la operación. Una URI histórica puede apuntar hoy a otro propietario sin que el sobre se altere.

La RFC 6920 separa el nombre basado en hash del mecanismo de localización. Esa separación permite cambiar de espejo: cualquier origen puede ofrecer un candidato, pero solo el cálculo sobre bytes establece la coincidencia.

El contrato de bytes debe existir antes de la comparación

El verificador aplica el algoritmo de la etiqueta 258 al preimagen candidato y compara el resultado con el payload. La frase parece simple hasta que el mismo recurso posee varias representaciones.

La RFC 9530 diferencia digests de contenido y de datos de representación seleccionados. La codificación de contenido puede alterar los bytes aunque la información abstracta parezca la misma. Esos campos tampoco aportan autenticación, autorización ni privacidad.

El perfil debe responder: ¿se firmó el archivo comprimido almacenado, el cuerpo después de decodificar, una serialización canónica o el flujo original? Parsear y volver a serializar JSON o CBOR cambia orden, espacios o números. Convertir finales de línea o descomprimir de forma implícita cambia el preimagen. Hay que retener los bytes recibidos, ejecutar únicamente transformaciones autorizadas, calcular y comparar.

Una coincidencia prueba relación con el digest bajo la resistencia del algoritmo. Todavía no prueba frescura, seguridad ni suficiencia para el objetivo.

La semántica tiene su propia puerta

Un SBOM coincidente puede ser ilegible. Puede ser legible y no cumplir el esquema. Puede cumplirlo y pertenecer a otra compilación. Puede pertenecer a la compilación correcta y omitir componentes. Puede ser completo y mostrar un componente que la política prohíbe.

El content type orienta al parser; no decide esos resultados. Tampoco hay una regla universal de vigencia. Un hash sigue identificando perfectamente datos antiguos. La aplicación necesita unir versión, tiempo, revocación, audiencia y acción.

RFC 9995 cubre COSE_Sign, COSE_Sign1, COSE_Mac y COSE_Mac0. Deja fuera COSE_Encrypt y COSE_Encrypt0, por lo que no otorga confidencialidad ni fija si una futura composición deberá calcular antes o después del cifrado.

La robustez exige además política algorítmica. La RFC 9053 define algoritmos COSE y validaciones de parámetros. RFC 9995 pide que la combinación de hash y firma o MAC sea al menos coherente con la fuerza del hash. La RFC 7696 deja claro que agilidad significa migrar: emitir el sucesor, desplegar consumidores compatibles, solapar, retirar y tratar los archivos históricos. Poder leer un identificador no implica aceptarlo para siempre.

La evidencia es la cadena que realmente corrió

El principio de running code de Heng Lu exige conservar los bytes producidos, hash calculado, sobre, algoritmos, clave, identidad, propósito, decisión de recuperación, trazado de descarga, nueva huella, comparación, parser, evaluación, autorización y efecto. Una casilla «RFC 9995» no sustituye esa historia.

Su propuesta de especificación inicial mínima y decisión local explica el reparto. Las etiquetas y la gramática son coordinación común. Privilegios, frescura, formatos, semántica, migración, retención y rollback corresponden a responsables locales que deben mostrar sus resultados.

La doctrina de capas de realidad impide convertir ocho hechos en una palabra: el sobre se parsea; la operación criptográfica pasa; la identidad coincide; el objeto aparece; los bytes igualan; el significado se acepta; la acción se autoriza; el efecto ocurre.

Estas fuentes no prueban adopción, rendimiento ni comportamiento de productos. El ejemplo de archivo y espejos delimita la autoridad; no describe una instalación real.