Resumen

  • RFC 3741 hace que las firmas sobre fragmentos XML extraídos dependan menos de las declaraciones de espacios de nombres ancestrales: serializa principalmente los prefijos que aparecen de forma visible en nombres de elementos o atributos.
  • No elimina todas las dependencias del contexto: atributos xml: heredados y prefijos que solo aparecen en valores pueden cambiar la interpretación tras volver a envolver el fragmento.

El envoltorio del mensaje no debería reescribir la firma del contenido

Supongamos que un protocolo firma un pequeño elemento XML dentro de un mensaje grande. Una pasarela quita el envoltorio externo y otro servicio inserta ese mismo elemento en un nuevo mensaje. Con Canonical XML inclusivo, algunas declaraciones ancestrales de espacios de nombres y atributos xml: pueden entrar en los bytes canónicos aunque el fragmento no los utilice. Un cambio del envoltorio puede alterar así la entrada del resumen y romper la firma de un fragmento que sigue intacto.

RFC 3741, publicada en marzo de 2004, abordó esa fricción concreta. Define una serialización exclusiva de un conjunto de nodos XPath. En lugar de importar la mayor parte del contexto ancestral, emite una vinculación cuando el prefijo se utiliza visiblemente en un nombre de elemento o atributo. El parámetro opcional InclusiveNamespaces PrefixList permite nombrar prefijos que deben tratarse de manera inclusiva pese a esa regla. El objetivo es que un subdocumento firmado pueda extraerse e insertarse en otro envoltorio sin que cada capa de transporte forme parte de su representación canónica.

Es una decisión sobre límites, no una garantía de significado independiente del contexto. La propia RFC enumera sus limitaciones. RFC 3075 trata de qué datos cubre realmente XML Signature; RFC 3076 describe cómo se canoniza un conjunto de nodos después del análisis. RFC 3741 se ocupa de qué contexto conservar cuando se mueve el subconjunto seleccionado.

«Visible» es un criterio útil, pero estrecho

La regla se basa en los nombres XML. Si un elemento o atributo usa el prefijo n1, su vinculación debe aparecer al serializar ese nombre. En cambio, un prefijo declarado por un antecesor que no figure en esos nombres puede omitirse. Esto suele quitar ruido: un envoltorio SOAP o del protocolo puede declarar espacios de nombres necesarios para el mensaje, pero irrelevantes para el fragmento extraído. La canonicalización exclusiva puede producir entonces los mismos bytes canónicos para el contenido en envoltorios distintos.

Sin embargo, el significado que usa la aplicación puede depender de información invisible en los nombres del conjunto de nodos. Un valor de atributo puede incluir una expresión XPath cuyos prefijos importan. Una aplicación también puede interpretar una cadena como xsi:type="xsd:decimal" como un QName, aunque XPath solo la vea como una cadena. Si ningún nombre utiliza visiblemente xsd y la lista inclusiva no lo menciona, su vinculación podría omitirse. El receptor podría interpretar el valor de otra manera dentro del nuevo envoltorio.

La RFC señala tres formas de gestionar esa dependencia: hacer visible el uso del prefijo en la estructura XML, mantener la misma vinculación en todos los contextos de interpretación o añadir el prefijo a InclusiveNamespaces PrefixList. Cada opción exige una decisión de diseño. La lista no detecta por sí misma las semánticas ocultas; quien diseña la aplicación debe saber qué valores dependen de espacios de nombres.

El contexto ausente de los bytes aún puede gobernar la lectura

La canonicalización exclusiva tampoco copia al fragmento huérfano valores ancestrales de xml:lang, xml:space o xml:base. Esos atributos pueden afectar la selección de idioma, el tratamiento de espacios o la resolución de referencias relativas. RFC 3741 exige que la aplicación incluya el valor necesario dentro del subconjunto o garantice un valor equivalente en cada contexto donde vaya a interpretarse.

Su advertencia sobre el contexto de destino es aún más clara. Los octetos canónicos pueden mantenerse iguales cuando el fragmento se coloca bajo un nuevo espacio de nombres predeterminado. Aun así, la aplicación receptora puede asociar el elemento sin prefijo a otro espacio de nombres y tratarlo como otro tipo de objeto. La firma verifica porque los octetos seleccionados no cambiaron; la interpretación de la aplicación puede variar porque sí cambió el contexto de destino.

RFC 3741 no define cómo extraer, insertar o reparar declaraciones de espacios de nombres, ni determina si la aplicación receptora está autorizada para hacerlo. El protocolo debe explicar qué contexto acompaña al fragmento y qué debe hacer el consumidor con el nodo resultante. La integridad criptográfica es solo un eslabón.

Un límite de firma menor exige más trabajo de integración

La canonicalización exclusiva cambia la dependencia accidental del envoltorio por la obligación explícita de inventariar las dependencias semánticas. Al revisar un fragmento firmado que se reenvía, no basta con preguntar si la firma valida; también hay que comprobar si los prefijos, atributos xml:, valores QName y referencias relativas conservan el mismo sentido en el destino. Sin un contrato explícito, la estabilidad de la firma puede confundirse con estabilidad semántica.

Este es el modelo de riesgo descrito por la especificación, no la prueba de un ataque o fallo concreto. RFC 3741 es Informational: establece el propósito y las limitaciones del algoritmo, pero no la frecuencia de despliegue de una implementación ni un error de un servicio específico. Su lección es acotada: quitar contexto de los bytes firmados puede mejorar la portabilidad, pero solo la aplicación puede identificar qué contexto omitido sigue determinando la interpretación.

Fuentes