Summary

  • RFC 3075 did not sign an intuitive “document.” It signed canonicalized SignedInfo, whose Reference entries committed to the digests of selected data after an ordered transform chain.
  • Core validation could succeed while unsigned source nodes, a changing external style sheet, unbound KeyInfo, unchecked Manifest members or application trust remained outside that receipt.

The file on the desk looked like one document. The signature engine saw a sequence of boundaries.

First came a resource, identified by a URI or supplied by application context. Then came zero or more transformations. XPath could select a subset. XSLT could construct another representation. Base64 decoding could turn visible characters into different input bytes. Canonicalization could serialize an XML node set into a repeatable octet stream. Only after those operations did the digest enter a Reference. The references, methods and digest values went into SignedInfo. A second canonicalization prepared SignedInfo for SignatureValue.

Published in March 2001 by the XMLDSIG Working Group, RFC 3075 turned this chain into an interoperable syntax and processing model. It could cover XML or non-XML data, enveloping content inside the signature, enveloped content around it, or detached resources elsewhere. That flexibility made a digital signature useful on the Web. It also made the scope of a successful result narrower than the human phrase “the document is signed.”

Two validations made one core result

The RFC required core validation to do two different jobs. Reference validation obtained the data object for every Reference in SignedInfo, produced the digest input, calculated the named digest and compared it with DigestValue. Signature validation obtained a key and checked SignatureValue over canonicalized SignedInfo with the named signature method.

Neither job could substitute for the other. A correct signature over SignedInfo did not cure a bad reference digest. Matching reference digests did not authenticate SignedInfo. When both passed, the result joined a key to a particular set of digest commitments and processing identifiers. It did not expand itself to every node near the signature, every resource a viewer opened, or every meaning an application assigned.

This distinction separates RFC 3075 from a simpler story about sealed files. SignedInfo was the signed control surface. The data objects were bound indirectly through reference digests. An operator investigating a result therefore needed at least two receipts: the exact canonical SignedInfo checked by the signature algorithm and the exact post-transform bytes checked by each digest.

The transform decided the signed object

Each Reference could identify a resource and carry an ordered list of transformations. The signer might use XPath to omit fields meant to remain editable, remove an enveloped signature from its own calculation, decode an encoded object, or apply XSLT before digesting. The RFC was explicit about the consequence: information discarded by a transform was not secured by the signature.

That was not automatically a flaw. A reusable form could intentionally protect its fixed clauses while leaving a designated input area open. A detached signature could cover the decoded binary represented inside XML rather than the wrapper tags. The boundary was a feature when signer and verifier agreed on it and the application enforced the intended shape.

The danger began when a user, reviewer or business rule treated the source tree as though the transform had selected all of it. An excluded amount, destination, instruction or style resource could change while the selected digest input remained identical. The signature would correctly validate the object it was asked to validate. The surrounding claim would be wrong.

RFC 3075 added an easily missed qualification. Core validation did not necessarily prove that the verifier freshly dereferenced a URI and executed each transform step. An application could accept a cached copy of already transformed data and verify its digest. Another application could demand fresh retrieval and execution. Both policies sat outside the bare equality test. A complete audit must therefore record not just the declared pipeline but how the actual digest input was obtained.

Canonical form removed variation, not meaning

Digital signatures require the verifier to calculate over the same bits as the signer. XML complicated that requirement because parsers normalize line endings and attributes, expand entities, map namespaces and may discard surface choices such as attribute order. DOM and SAX expose structured information rather than the original byte stream.

Canonicalization supplied a stable serialization of the relevant node set. It made two calculations comparable despite permitted syntactic variation. It did not certify that two renderings meant the same thing, that a schema was authentic, that a namespace described what an application assumed, or that an omitted node was harmless.

The later Canonical XML 1.1 specification stated the boundary in another way: canonical form accounts for defined representational differences, while application-specific equivalence remains outside a general XML canonicalizer. Repeatable bytes were indispensable evidence. They were not a universal semantics engine.

What the signer saw had to meet what was signed

RFC 3075’s security section did not leave presentation as a cosmetic matter. If a signature was intended to express a person’s or automated agent’s judgment, the protected material should approximate what that actor was presented. A screen image could be signed literally, but that was difficult for software to process. The alternative was to sign the data together with the filters, style sheets, client profile or other inputs that shaped its presentation.

The relying side had the reciprocal duty: operate on the transformed signed form, not casually on the original or an intermediate representation. An external style sheet offered the clearest example. If it changed how the document appeared but was not itself referenced and signed, a valid data signature did not freeze the resulting view.

This was not a declaration that every XML signature represented human consent. The RFC said the opposite in scope terms. XML Signature associated a key with referenced octets; it did not normatively establish how the key related to a person or institution, or what the signed data meant. Rendering requirements and agreement semantics belonged to the application.

KeyInfo could find a key without binding trust

KeyInfo could carry a public key, certificate data, a name, a retrieval instruction or application-defined material. It was optional because the recipient might already know the key from context. In the core structure it sat outside SignedInfo.

That placement matters. If a signer wanted to bind KeyInfo cryptographically, a Reference could include it. Without such a reference, changing the surrounding key description did not necessarily change SignatureValue, even though signature validation still used key information as parsed or supplied externally.

Binding the bytes of KeyInfo would not finish the trust decision. A certificate could be intact while unacceptable for the operation. A KeyName could be faithfully signed while meaning something only inside one system. RFC 2807 had already bounded the working group’s charter: XML Signature syntax associated content with a key, while arbitrary trust and assertion semantics had to be supplied by applications.

A signed Manifest was not every object’s receipt

RFC 3075 also offered Manifest, a list of references useful when an application wanted more flexible failure policy. If SignedInfo referenced a Manifest, core validation checked the digest of the Manifest element. But the application decided which inner references to validate and what to do when an object was unavailable or a comparison failed.

The outer list could therefore be authentic while one or more listed resources lacked a successful validation receipt. Saying “the Manifest was signed” and saying “every Manifest object was retrieved, transformed and matched” were different statements. A reviewer needed the member-level results, not only the outer green mark.

Later practice narrowed executable freedom

RFC 3275 obsoleted RFC 3075 in March 2002 after interoperability experience and made several syntax changes. It retained the essential architecture: references select transformed data, SignedInfo carries the commitments, key trust is an application concern and presentation must align with what was signed.

Later W3C XML Signature 1.1 and best-practice guidance made the operational perimeter more explicit. Authenticate SignedInfo before performing potentially dangerous reference work. Establish trust in the verification key. Limit XPath, XSLT, retrieval methods, transform counts and external URI schemes. Check that references protect the elements the application actually intends to use.

Those recommendations are not evidence that a particular RFC 3075 deployment suffered an exploit. They show why a flexible, executable signature description requires policy around the cryptography. The signature engine can answer its exact question and still leave the application with the wrong question.

The durable receipt was a chain, not a badge

Lu Heng’s Running-Code Primacy supplies a later lens: an algorithm identifier, schema-valid Signature element or successful library return is not the end of operational proof. The verifier must preserve the bytes and decisions that produced the return value. Reality Layers adds a second lens: the symbolic statement “signed” can outrun the transformed object, rendered experience and downstream effect if those layers are collapsed.

Neither essay was part of RFC 3075 and neither authorizes rewriting its history. Together they sharpen the standard’s own warning. A signature was not vague ceremonial authority. It was a bounded receipt over selected data. Its strength came from refusing to claim more.

Sources

Lu Heng did not write or approve RFC 3075, RFC 3275 or the W3C recommendations. His essays are disclosed later analytical lenses.