Resumen

  • La firma cubre una base construida con una lista ordenada de campos, componentes derivados y parámetros. Verificarla solo demuestra equivalencia semántica dentro de esa lista; lo que queda fuera puede cambiar sin romper el cálculo.
  • keyid, created, expires, nonce y tag son datos para la política del verificador. No descubren por sí mismos una identidad fiable, no consumen un uso y no autorizan un efecto.
  • Si un proxy valida, transforma y vuelve a firmar, aparecen dos declaraciones: la del cliente antes del cambio y la del proxy después. El servicio final necesita saber cuál de ellas exige y qué autoridad tenía cada actor.

El mensaje impecable que llegó a la ruta equivocada

Una plataforma recibe un cuerpo JSON firmado. La clave está activa, el algoritmo está permitido y el Content-Digest coincide. La solicitud parece más segura que una petición ordinaria.

Pero la lista de Signature-Input no contiene @target-uri ni @authority. Tampoco contiene @method o un identificador de uso único. El cuerpo puede haber sido aprobado para una simulación y terminar en la ruta que ejecuta, o haber sido destinado a una cuenta y reenviado a otra. Dentro de la base firmada no ocurrió ninguna alteración.

La firma no falló. La organización hizo una pregunta demasiado pequeña: «¿siguen siendo estos los bytes aprobados?». La pregunta operativa era mayor: «¿autorizó este actor esta acción, sobre este recurso, en este destino y una sola vez?».

Qué verifica realmente RFC 9421

HTTP no conserva siempre una imagen binaria idéntica entre extremos. Los intermediarios reordenan representaciones legítimas, traducen versiones, combinan campos y ajustan el contexto de encaminamiento. Por eso RFC 9421 no firma el paquete crudo.

El firmante elige componentes. Pueden ser campos HTTP o valores derivados como @method, @authority, @target-uri y @status. El orden forma parte de Signature-Input. Los parámetros de la firma quedan incluidos al final mediante @signature-params, de modo que no se pueda sustituir la lista o la fecha sin invalidar la prueba.

El receptor vuelve a construir la base desde el mensaje que recibió. Si la operación criptográfica es positiva, la afirmación es deliberadamente limitada: el mensaje es semánticamente equivalente al firmado respecto de los componentes cubiertos.

La firma no se extiende por simpatía a los campos vecinos. Tampoco existe una cobertura «implícita» del mensaje entero.

La lista cubierta es una decisión de producto

Un estándar general no sabe qué cambia el significado de cada API. Para una lectura pueden importar método, autoridad y ruta. Para cambiar una política de red pueden importar además el cuerpo, la identidad de la cuenta, la versión del recurso y una prueba de unicidad. Para un recibo firmado interesan el estado, el digest de la respuesta y el vínculo con la solicitud original.

La aplicación debe publicar un perfil verificable por operación. Si solo exige que exista cualquier firma válida, confunde formato con mandato.

Omitir @method permite que una prueba creada para una consulta acompañe una mutación. Omitir la autoridad o el URI abre el traslado entre servicios. Omitir el campo de autorización deja una identidad sustituible al lado de componentes intactos.

Firmar todo tampoco es una solución automática. Via y Forwarded cambian en los proxies. Si el perfil los inmoviliza, una ruta correcta puede romperse. La regla útil consiste en cubrir lo que modifica permiso o consecuencia y declarar qué puede transformar cada intermediario.

El digest es un puente hacia el cuerpo

RFC 9421 no introduce todo el cuerpo directamente en la base. RFC 9530 proporciona Content-Digest. El flujo seguro tiene tres comprobaciones relacionadas: el campo digest está cubierto por la firma, la firma es válida y el digest se recalcula sobre el contenido recibido.

Verificar solo dos deja un hueco. Un digest sin firma puede sustituirse con el cuerpo. Un digest firmado pero no recalculado puede quedar intacto mientras se intercambia el contenido. El verificador debe comparar la afirmación protegida con la realidad recibida.

También debe fijar las metadatos que cambian la interpretación. Un Content-Type libre puede entregar los mismos octetos a otro parser. Un cambio de Content-Encoding puede alterar el dominio sobre el que se espera el cálculo.

Los digests en trailers plantean una frontera temporal. Si la aplicación ejecuta durante la llegada del flujo y valida al final, la prueba llega después de la consecuencia. Es aceptable para trabajo reversible; para una operación irreversible exige búfer, transacción o una política distinta.

Una clave que verifica puede ser la clave equivocada

keyid es un selector, no una credencial autosuficiente. RFC 9421 deja fuera del protocolo la obtención de claves y la política de algoritmos. Esa separación evita convertir el formato en una autoridad universal, pero obliga a gobernar el resolver local.

Aceptar una clave adjunta por el solicitante permite al atacante firmar con su propia clave. La firma demuestra posesión, no que la clave represente a un cliente autorizado.

El verificador necesita una cadena local: fuente de confianza, versión exacta de clave, periodo de vigencia, principal, rol y operaciones permitidas. Debe registrar qué versión resolvió, no solo la cadena de texto de keyid.

Durante una rotación se pueden aceptar dos claves o algoritmos. Ese intervalo debe tener inicio, salida y telemetría. Si el sistema no distingue una migración anunciada de una ampliación inesperada, la compatibilidad se convierte en permanencia de privilegios antiguos.

Un nombre registrado por IANA hace interoperable un identificador. No aprueba el algoritmo para borrar datos, emitir dinero o controlar infraestructura.

Repetición: el reloj no consume la orden

created y expires permiten evaluar una ventana de tiempo. La aplicación decide su tamaño y el margen para relojes. Una firma puede seguir siendo criptográficamente correcta y quedar fuera de la política actual.

Pero una ventana de treinta segundos admite muchas copias en treinta segundos. Hace falta un dato que identifique el uso y un estado capaz de consumirlo.

nonce ofrece el dato, no el estado. En una arquitectura distribuida, dos regiones pueden comprobar simultáneamente que el valor no fue usado y aceptar ambas. El almacén anti-repetición necesita atomicidad, ámbito y una duración coherente con todos los verificadores.

tag ayuda a encontrar la firma destinada a un perfil, pero cualquier observador puede copiar esa etiqueta. Después de seleccionar, todavía hay que revisar cobertura, clave, tiempo y autorización.

La firma del proxy tiene otro sujeto

Según RFC 9110, los intermediarios son parte normal de HTTP. Un gateway puede validar la firma externa, retirar información privada, cambiar la autoridad interna y firmar el mensaje resultante.

La segunda firma no absorbe la primera. Prueba lo que el gateway afirma bajo su propia clave. El origen debe decidir si el gateway está autorizado a certificar solamente «validé al cliente» o a emitir la orden en su nombre.

Para conservar la cadena de custodia hay que registrar la vista externa, la firma cliente elegida, el perfil aplicado, la transformación y la vista interna firmada por el proxy. Un único booleano en el último salto no permite reconstruir la decisión.

La conversión entre HTTP/1.1 y HTTP/2 muestra por qué existen componentes derivados. La autoridad puede viajar como Host o :authority; @authority representa el concepto. Firmar una forma específica del cable puede fallar en la traducción o hacer que un servicio valide una autoridad distinta de la usada al autorizar.

Varias firmas, varias finalidades

Un mensaje puede incluir firmas de cliente, gateway y aprobador, o una pareja de algoritmos durante un cambio. Todas pueden ser válidas y ninguna ser suficiente para la operación actual.

El servicio necesita una regla de selección. Aceptar la primera que pase puede usar una firma de auditoría como permiso de ejecución. El label y el tag identifican candidatos; el perfil exige rol, clave, componentes y contexto.

En respuestas, el parámetro req permite cubrir componentes de la solicitud. El verificador necesita la solicitud exacta. Un recibo firmado separado de su petición no recupera automáticamente esa relación.

Ni TLS ni la firma deciden el negocio

TLS 1.3 aporta confidencialidad y protección de un canal. HTTP Message Signatures conserva una prueba seleccionada más allá de una conexión o a través de proxies. Una no sustituye a la otra.

La autenticación HTTP puede presentar una credencial. La aplicación aún decide si ese principal puede realizar la acción sobre el estado actual. Una respuesta firmada tampoco recibe permiso automático de caché; ese juicio pertenece a RFC 9111.

En la disciplina de capas de realidad de Heng Lu, la base canónica es un artefacto común, la verificación es un resultado ejecutado, el mapa de claves es una afirmación de identidad, la autorización es una decisión local y el commit es el efecto real. El error institucional aparece cuando el resultado de una capa se presenta como poder sobre la siguiente.

Fuentes y límites

Estas fuentes no demuestran adopción actual, conducta de proveedores, identidad humana, voluntad jurídica, no repudio ni corrección comercial. Definen mecanismos y fronteras que cada despliegue debe convertir en política comprobable.