Resumen

  • SignatureValue autenticaba la forma canónica de SignedInfo; sus Reference comprometían resúmenes de objetos obtenidos después de una cadena ordenada de transformaciones.
  • El éxito central no certificaba todo el XML de origen, lo mostrado al usuario, la confianza institucional de KeyInfo, cada objeto de un Manifest ni la autorización decidida por la aplicación.

Un documento XML podía contener el contrato, la firma y también información que nunca había entrado en el cálculo. Podía además mostrar una apariencia construida por recursos externos. RFC 3075 no escondió esa posibilidad: definió una máquina de selección y autenticación cuyo resultado debía leerse con exactitud.

La norma apareció en marzo de 2001 como trabajo del grupo XMLDSIG. Permitía firmar datos XML o binarios, dentro del elemento Signature, alrededor de él o en una ubicación remota. Esta versatilidad servía a la arquitectura distribuida de la Web. A cambio, obligaba a abandonar la idea de una firma como sello indivisible sobre un archivo.

La validación central tenía dos obligaciones

Para cada Reference de SignedInfo, el verificador obtenía el objeto, producía la entrada indicada, calculaba el resumen y lo comparaba con DigestValue. Luego canonizaba SignedInfo y comprobaba SignatureValue con el método y la clave elegidos.

Una firma matemática correcta sobre SignedInfo no solucionaba un resumen de referencia incorrecto. Un conjunto de resúmenes coincidentes tampoco autenticaba por sí solo la lista que los contenía. Las dos comprobaciones juntas vinculaban una clave a compromisos concretos, no a cualquier contenido que compartiera el mismo árbol o la misma ventana.

Por eso un registro auditable debía guardar la representación canónica de SignedInfo y la secuencia exacta de bytes entregada a cada función de resumen. El mensaje «válido» era una conclusión; no era el expediente que permitía reproducirla.

La salida de las transformaciones definía la materia firmada

Una Reference podía aplicar XPath para conservar ciertos nodos, XSLT para fabricar una representación, Base64 para recuperar un binario o canonización para serializar un conjunto XML. El resumen se calculaba al final. Lo eliminado no quedaba protegido.

La selección podía ser legítima. Un formulario necesitaba campos editables; una firma enveloped debía excluir su propia SignatureValue; un paquete podía proteger el binario decodificado en vez del envoltorio. El error comenzaba cuando la interfaz llamaba «documento firmado» al conjunto de origen sin revelar esa frontera. Un destino, importe o instrucción excluidos podían alterarse y la firma seguiría validando correctamente el objeto elegido.

Además, la comprobación central no demostraba necesariamente que el verificador hubiese recuperado la URI en ese instante y ejecutado todos los pasos. La aplicación podía aceptar una copia ya transformada; otra política podía exigir obtención fresca. La coincidencia del resumen no identificaba por sí sola la procedencia ni la edad de la entrada.

Canonizar no convertía sintaxis en significado

Los analizadores XML normalizan saltos de línea y atributos, expanden entidades y proyectan espacios de nombres sobre nodos. DOM y SAX pierden detalles físicos del texto original. La canonización proporcionaba una serialización común para que ambos extremos calcularan sobre los mismos octetos.

Ese acuerdo era mecánico, no semántico. No validaba el esquema, no garantizaba una representación visual, no convertía un nombre de espacio en autoridad y no declaraba irrelevante lo que una selección había omitido. Canonical XML 1.1 mantuvo esa división entre equivalencia general de representación y equivalencias definidas por cada aplicación.

Firmar y ver debían encontrarse

La sección de seguridad de RFC 3075 decía que, si una firma quería expresar juicio o consentimiento, debía proteger de la manera más fiel posible la información presentada. Firmar una imagen exacta de pantalla era una opción poco flexible. La alternativa era incluir datos, filtros, hojas de estilo, perfil de cliente y demás elementos que condicionaban el resultado visible.

El receptor también debía operar sobre la forma transformada y firmada. Si mostraba el original o un estado intermedio, podía atribuir la firma a otra cosa. Una hoja de estilo externa no incluida en las referencias podía cambiar la presentación sin invalidar el resumen de los datos.

La norma no definía por ello la identidad civil del firmante ni el significado jurídico del acto. Asociaba una clave con contenido referenciado. La semántica, el renderizado y la decisión de confianza pertenecían al perfil de aplicación.

KeyInfo era información para verificar, no una política de confianza

KeyInfo podía llevar una clave pública, certificados, un nombre o una referencia para obtenerlos. También podía faltar si el contexto proporcionaba la clave. En la estructura normal se encontraba fuera de SignedInfo; una Reference adicional podía incluirlo si se quería fijar su contenido.

Pero fijar su contenido no concedía atribución ni permiso. Un certificado podía ser auténtico y no estar autorizado para una operación; un nombre de clave podía funcionar solo como índice local. RFC 2807 había dejado fuera del mandato central las semánticas arbitrarias de confianza y afirmación.

Firmar el Manifest no completaba sus verificaciones internas

El elemento Manifest agrupaba referencias cuya política de error podía definir la aplicación. Cuando SignedInfo apuntaba al Manifest, la validación central comprobaba el resumen del contenedor. La decisión de verificar referencias internas y la reacción a fallos o recursos inaccesibles seguían siendo responsabilidad del programa.

Así, una lista auténtica no equivalía a una colección enteramente comprobada. Un sistema que mostraba un único éxito necesitaba demostrar qué miembros había recuperado y validado; de otro modo convertía una posibilidad de aplicación en un hecho criptográfico inexistente.

La experiencia posterior impuso perfiles más estrechos

RFC 3275 sustituyó a RFC 3075 en marzo de 2002 y modificó varias estructuras a partir de la experiencia de interoperabilidad. XML Signature 1.1 y las recomendaciones posteriores del W3C preservaron el modelo y añadieron disciplina operativa: autenticar SignedInfo antes de ejecutar referencias peligrosas, establecer la confianza de la clave por separado, limitar XPath, XSLT, RetrievalMethod, el número de transformaciones y las URI externas, y confirmar que los elementos usados por la aplicación estén realmente firmados.

Esos textos no prueban un ataque o fallo concreto en una instalación de 2001. Demuestran por qué la libertad expresiva del formato necesitaba límites locales alrededor de la primitiva.

Los ensayos posteriores de Lu Heng sobre primacía del código en ejecución y capas de realidad ayudan a separar declaración, bytes, resultado criptográfico, presentación, confianza y efecto. No pertenecen a RFC 3075 ni fueron avalados por sus autores. La idea que refuerzan ya estaba en el diseño: el valor de la firma dependía de no ampliar su alcance mediante lenguaje impreciso.

Fuentes

Lu Heng no escribió ni aprobó RFC 3075, RFC 3275 o las recomendaciones del W3C. Sus ensayos se usan como marcos analíticos posteriores y declarados.