Resumen

  • RFC 3076 no operaba sobre un archivo intacto: primero, un procesador XML convertía el flujo de octetos en nodos XPath y, durante ese paso, normalizaba y expandía información.
  • La igualdad canónica era un recibo preciso sobre ese modelo, la opción de comentarios y el algoritmo; no reconstruía el original ni conservaba por sí sola el contexto DTD, la URI base o el significado de la aplicación.

La representación común llegaba después del análisis

En marzo de 2001, RFC 3076 y la Recomendación del W3C Canonical XML Version 1.0 resolvieron un obstáculo real. XML permitía escribir de maneras distintas información que muchas aplicaciones trataban como equivalente: atributos en otro orden, codificaciones diferentes, elementos vacíos abreviados o expandidos, referencias de caracteres o entidades en lugar de su contenido literal. Una firma necesitaba calcular siempre sobre los mismos octetos.

La respuesta fue una serialización UTF-8 con reglas explícitas. Se eliminaban la declaración XML y el DTD; los elementos vacíos se convertían en pares de apertura y cierre; los atributos usaban comillas dobles; espacios de nombres y atributos se ordenaban; se quitaban declaraciones redundantes. Incluir comentarios o excluirlos era un parámetro. Aplicar de nuevo el mismo método a una forma canónica bien formada no la modificaba.

Sin embargo, el objeto formal era un conjunto de nodos XPath. Si la entrada era un flujo de octetos, había que analizarlo antes. La salida estable no nacía en el borde del archivo, sino después de una primera máquina interpretativa.

El parser ya había modificado la evidencia

El procesador normalizaba finales de línea y valores de atributos, convertía CDATA en caracteres, resolvía referencias de caracteres y entidades analizadas, y podía incorporar atributos predeterminados declarados en el DTD. El espacio de nombres se convertía en nodos; los caracteres consecutivos, en un nodo de texto.

Por eso dos archivos diferentes podían converger correctamente. Un carácter literal y una referencia numérica, una entidad interna y su texto de sustitución, o <e/> y <e></e> podían producir el mismo modelo. Esa convergencia era la utilidad de la especificación.

También destruía la posibilidad de reconstruir la escritura original. El encoding inicial se perdía al emitir UTF-8. Desaparecían la declaración XML, el DTD, los límites de CDATA y entidades, y el orden de los atributos. Canonical XML era una representación de la información analizada, no un contenedor reversible de la procedencia.

Por tanto, el recibo debe comenzar antes: hash de los octetos recibidos, URI y momento de recuperación, encoding, versión y configuración del parser, validación, política de entidades y subconjuntos externos, bytes exactos de cada dependencia, URI base y atributos añadidos por defecto. El hash canónico solo no responde a esas preguntas.

Una salida idéntica podía no conservar el comportamiento

La propia RFC enumeró información ausente del modelo XPath: la URI base; las notaciones y entidades externas no analizadas; y los tipos de atributo declarados en el DTD.

Una entidad externa puede incluir una URI relativa. Cuando el parser inserta el texto de esa entidad en el documento principal, la referencia puede quedar ligada a otra base. Los octetos canónicos siguen siendo estables aunque el recurso que abra la aplicación sea distinto. RFC 3076 aconsejaba establecer xml:base o resolver las URI relativas antes de canonicalizar.

El DTD muestra otra separación. Un atributo por defecto puede aparecer ya en el conjunto de nodos y en la salida, aunque se elimine la declaración que lo introdujo. En cambio, los tipos ID, IDREF, enumeración o NOTATION dejan de acompañar al archivo. Un nuevo parser recibe el valor textual sin heredar necesariamente su contrato de tipo.

Las notaciones y entidades no analizadas podían vincular datos externos con una aplicación. El modelo no retenía todo ese enlace. Que el documento calificara estos casos de infrecuentes no autorizaba a ignorarlos cuando el sistema dependía de ellos.

Un conjunto de nodos no equivalía a un subárbol completo

En una canonicalización parcial, XPath aportaba nodos individuales. Elegir un elemento no incluía automáticamente atributos, texto y descendientes. Un nodo excluido no se imprimía por estar su padre presente. Al mismo tiempo, un ancestro omitido podía influir en el contexto de espacios de nombres o atributos XML heredables.

RFC 3076 trasladaba al creador del conjunto la obligación de conservar la información necesaria para la semántica. La salida de un subconjunto podía no ser XML bien formado. La palabra “canónica” no implicaba que el fragmento fuese completo ni autónomo.

Esta cuestión precede a la de RFC 3075. Allí importaba qué referencias y transformaciones cubría una firma. Aquí importa qué objeto había producido el parser antes de serializarlo. Una firma válida no repara una procedencia de análisis que nunca se registró.

Canónico no era sinónimo de equivalencia universal

La RFC rechazó convertir la forma canónica en una prueba “si y solo si” de toda equivalencia. Una aplicación podía ignorar espacios concretos o tratar black y rgb(0,0,0) como un mismo color. Otras recomendaciones podían definir equivalencias adicionales. Dos formas distintas podían significar lo mismo para esa aplicación.

Tampoco se hacía una normalización general del modelo de caracteres Unicode. Los prefijos de espacios de nombres se conservaban porque renombrarlos podía romper expresiones XPath o valores similares a QName escritos dentro de texto o atributos. La norma establecía una igualdad ejecutable y limitada, no una teoría completa del significado.

La evolución posterior volvió a señalar el contexto

En 2006, una nota del W3C documentó que C14N 1.0 podía copiar una xml:base relativa a un descendiente seleccionado sin conservar la ruta acumulada de sus ancestros. La posterior definición de xml:id mostró además que un identificador no debía heredarse como otros atributos del espacio XML.

Canonical XML 1.1 corrigió ambos puntos en 2008 mediante reglas especiales para xml:base y la no herencia de xml:id. Es evolución documentada, no prueba de que todos los sistemas anteriores fallaran. Exclusive XML Canonicalization trató el contexto de espacios de nombres al mover subconjuntos. RFC 3275 integró C14N 1.0 en XML Signature. Ninguna de esas capas convirtió los bytes canónicos en el archivo original o en una autorización.

Qué conservar

Un archivo probatorio debe guardar los octetos recibidos, origen, encoding y hash; parser y ajustes; modo de validación; DTD, catálogos, subconjuntos y entidades consumidos; URI base; atributos predeterminados; expresión y resultado XPath; opción de comentarios; algoritmo exacto; y salida canónica. Después debe guardar el resultado de comparación o firma, la regla semántica de la aplicación, la decisión y su efecto.

Las ideas posteriores de Lu Heng sobre código en ejecución y capas de realidad sirven como lente declarada. La reproducción de octetos es más fuerte que una etiqueta institucional porque puede probarse. Pero ese recibo de ejecución no absorbe la historia de la fuente, la autoridad ni el resultado.

Fuentes