Resumen

  • La revisión 07 utiliza la clave confirmada por un Workload Identity Token para firmar método, ruta, consulta, audiencia, campos seleccionados, digest del contenido y metadatos temporales. Esa prueba autentica una representación; no concede la operación.
  • La protección contra repetición depende del alcance real de la memoria de nonces. La autenticidad de la respuesta depende de que el cliente la exija en su solicitud firmada. Autenticación, novedad, autorización, commit y resultado necesitan comprobantes propios.

Una repetición que cada nodo ve de forma distinta

Un servicio recibe una petición firmada en el nodo A. El WIT es válido. La clave de cnf.jwk verifica la firma. El cuerpo coincide con Content-Digest, la audiencia es aceptable y el nonce aún no está en el caché local. A guarda el nonce y remite la operación.

La misma petición llega al nodo B segundos después. Sigue dentro de expires, pero B no comparte el caché de A. Para B, el nonce es nuevo y la firma continúa siendo válida. La pregunta decisiva ya no es criptográfica: ¿puede ese principal ejecutar esa acción sobre ese recurso? Y aun después de un “sí”, queda otra: ¿la aplicación llegó a confirmar el cambio?

El 20 de septiembre de 2026 se presentó draft-ietf-wimse-http-signature-07. El encabezado aspira a Standards Track y señala el 24 de marzo de 2027 como fecha de caducidad. No es un RFC. Es un Internet-Draft activo del grupo de trabajo, no una norma desplegada, un censo de adopción ni una prueba sobre un producto concreto. Las implementaciones mencionadas en el apéndice muestran experimentación, no prevalencia operativa.

El sobre criptográfico tiene bordes

WIMSE perfila RFC 9421. La solicitud cubre obligatoriamente @method, @path y @query. También debe incluir, cuando existan, Content-Type, Content-Digest, Authorization, Txn-Token y Workload-Identity-Token. Si hay cuerpo, el receptor vuelve a calcular Content-Digest sobre los bytes recibidos.

Ese nuevo cálculo evita una falsa evidencia: firmar el texto de un digest no basta si nadie comprueba el contenido al que supuestamente representa. RFC 9530 aporta la semántica de los campos digest; el perfil exige cerrar el vínculo. El registro operativo debe conservar los componentes reconstruidos, el digest calculado y la decisión de verificación.

Los parámetros incluyen created, un expires breve, nonce y la etiqueta wimse-workload-to-workload. Las solicitudes añaden wimse-aud. El perfil no usa keyid ni alg como parámetros de firma: la clave y el algoritmo proceden de cnf.jwk en el WIT. La política local todavía puede rechazar el algoritmo.

Si aparecen varias firmas con la etiqueta WIMSE, el receptor rechaza el mensaje. No debe elegir silenciosamente una firma y llamar a esa elección interoperabilidad. Una representación cubierta tiene que ser inequívoca para remitente, intermediario y servicio final.

Lo que no se cubre no queda protegido por asociación. Un encabezado omitido puede cambiar. Si un proxy vuelve a firmar, crea otra afirmación bajo otro principal; no amplía retroactivamente la firma original.

La audiencia lógica sobrevive al proxy

El conjunto obligatorio omite @authority porque los balanceadores y proxies que terminan TLS suelen reescribirlo. WIMSE desplaza la vinculación al parámetro firmado wimse-aud, pensado para identificar al destinatario lógico.

La arquitectura debe responder cómo se forma y compara ese valor. El nombre de servicio verificado en TLS, la autoridad HTTP observada en un salto y la audiencia WIMSE no son equivalentes. RFC 9525 trata la identidad de servicio en TLS. WIMSE trata una representación de solicitud y la clave de una carga de trabajo. Un canal correcto puede llevar una audiencia demasiado amplia; una audiencia estricta puede rechazar una firma correcta.

Por eso la prueba conserva el nombre esperado, el certificado presentado, el punto de terminación, la audiencia enviada, la audiencia aceptada y el servicio al que finalmente se entregó la operación. La palabra “autenticado” no contiene esa cadena.

Prueba de posesión no es mandato

Primero se valida el WIT; después, la firma con la clave vinculada. El resultado permite afirmar que un poseedor de la clave privada produjo los componentes cubiertos en la ventana aceptada. No identifica la intención humana, no demuestra custodia exclusiva en una instancia viva y no asigna un rol de negocio.

La revisión 07 declara fuera de alcance todo el subsistema de autorización. Ese límite no es una omisión para que la pasarela la rellene con una regla universal. Es una división de trabajo. La autenticación entrega un principal y una solicitud. El punto capaz de causar el efecto resuelve principal, acción, recurso, contexto y versión de política.

El comprobante de autorización anota la regla aplicada, la decisión, las obligaciones y cualquier excepción. Si una plataforma asigna un privilegio amplio a todo token de un dominio de confianza, ese poder nace en su configuración. Debe auditarse y versionarse allí.

La frescura tiene una geografía

Las fechas reducen la ventana de uso, pero no impiden una repetición dentro de ella. El nonce permite recordarla. El borrador permite que el receptor mantenga un caché y recomienda rechazar valores vistos. No obliga a compartirlo entre validadores y reconoce que una sincronización distribuida puede ser costosa. La protección contra replay no se presenta como objetivo absoluto del protocolo.

Así, “nonce ausente” significa “ausente en esta memoria bajo esta retención”. No demuestra que otro nodo, otra región o una generación previa del caché no lo aceptara. Tampoco demuestra que la aplicación no ejecutara ya una operación semánticamente idéntica con otro identificador.

Una lectura idempotente puede aceptar esa incertidumbre. Un débito, borrado o emisión irreversible necesita una segunda defensa en el punto de efecto: identificador de idempotencia, restricción transaccional o comprobante de commit. El tablero debe mostrar identidad del validador, alcance y duración del caché, y relación entre retención y expiración de firma.

La respuesta segura comienza con una exigencia

Un servidor puede firmar respuestas. La garantía fuerte aparece cuando el cliente incluye wimse-sign-response=true en los parámetros firmados de su solicitud. Si el servidor no puede firmar, no puede sustituir una respuesta exitosa ordinaria. Si llega una respuesta sin firma, el cliente debe rechazarla.

Cada respuesta firmada contiene wimse-req-nonce, que repite el nonce de la solicitud dentro de la firma. La prueba queda unida a esa petición concreta, no sólo a una clave de servidor y un instante próximo.

Cuando el cliente no exige la firma, una política interna del servidor no es observable de la misma forma. Un intermediario puede eliminar la firma y el cliente debe aceptar la respuesta sin ella. “El servidor firma” describe capacidad. “El cliente exigió y verificó una respuesta ligada a su nonce” describe el hecho de una transacción.

Ni siquiera ese hecho prueba un resultado final. Una respuesta auténtica puede anunciar que un trabajo fue aceptado, mientras el trabajo asíncrono fracasa después. El resultado requiere su propia observación.

La última transformación define dónde autorizar

Los intermediarios terminan TLS, normalizan, enrutan y pueden volver a firmar. Un campo cubierto no puede cambiar sin invalidar la firma; uno no cubierto sí. Si el servicio decide la cuenta, el tenant o el objeto a partir de un campo no firmado después de que la pasarela ya autorizó, la decisión ocurrió demasiado pronto.

La traza correcta une validación de entrada, política de transformación, identidad de la nueva firma, diferencia de componentes y autorización posterior. No hace falta congelar HTTP. Hace falta saber qué campos determinan el efecto y qué actor puede modificarlos.

De ahí surge una cadena de seis comprobantes: credencial WIT; firma y digest; nonce y memoria consultada; principal, acción, recurso y política; idempotencia y commit; observación del resultado. Pueden discrepar sin que el sistema sea incoherente. Esa discrepancia localiza la responsabilidad.

Una declaración de conformidad o un ejemplo de interoperabilidad no sustituye la cadena. Para evaluar código real hay que capturar la base de firma, la validación del token, el diseño de los cachés, el log de autorización y la transición de estado. Una revisión futura del borrador puede cambiar reglas; la decisión debe fijar versión y desviaciones.

Fuentes