Signing and Encryption

## Two hashes, not one An XML signature does not sign a document. It signs a small block, `<ds:SignedInfo>`, that *names* what was hashed and *states* the hash. Reading it as a chain is the fastest way to get it right: 1. Take the element to be protected — for SAML, a `<saml:Assertion>` or a `<samlp:Response>`, identified by its `ID` attribute. 2. Run the transforms listed in `<ds:Transforms>` over it, in order. 3. Hash the resulting octets; that value goes in `<ds:DigestValue>`, inside the `<ds:Reference>`. 4. Canonicalise `<ds:SignedInfo>` using the algorithm its own `<ds:CanonicalizationMethod>` names, and sign *that*; the result is `<ds:SignatureValue>`. So `<ds:SignatureValue>` covers `<ds:SignedInfo>`, and `<ds:SignedInfo>` covers the element only indirectly, through the digest. Break either link and verification fails — but note what the structure implies: **the signature's reach is exactly one subtree, the one the URI names.** Anything outside that subtree is present in the document and unprotected. ## What SAML pins down Generic XML Signature is far more permissive than SAML allows. The profile narrows it hard: - the signature MUST be **enveloped** — the `<ds:Signature>` sits inside the element it protects, rather than alongside it or in a separate document; - it MUST contain a **single** `<ds:Reference>`, so there is never an argument about which of several digests applies; - that reference MUST be a **same-document reference** to the root element's `ID` attribute value, written `URI="#_a1b2"` against `ID="_a1b2"`. The narrowing exists because multi-reference, detached and externally referenced signatures make it genuinely hard for a receiver to state what it verified. One element, one digest, one answer. ## The two transforms and why each is there | Transform | Algorithm | Job | |---|---|---| | Enveloped signature | `http://www.w3.org/2000/09/xmldsig#enveloped-signature` | Removes the `<ds:Signature>` element from the subtree before hashing, resolving the circularity of a signature that sits inside what it signs | | Exclusive canonicalisation | `http://www.w3.org/2001/10/xml-exc-c14n#` | Produces one defined octet stream from a subtree whose serialisation may legitimately vary | The second deserves the explanation, because it is what interviewers push on. XML has many byte sequences for the same information content: attribute order, whitespace inside a tag, `<a/>` against `<a></a>`, which namespace declarations are written where, character references. A hash over raw bytes would break whenever a parser round-tripped a document. Canonicalisation defines one serialisation so both parties hash the same octets. **Exclusive** canonicalisation goes further, and that is the point for SAML specifically. Inclusive canonicalisation pulls in namespace declarations inherited from ancestors; exclusive canonicalisation includes only those the subtree actually uses. That is what lets a signed `<saml:Assertion>` be lifted out of the `<samlp:Response>` it arrived in and placed inside a different document — a very normal thing to do — and still digest to the same value, because the ancestors' declarations were never part of the hash. SAML states this as a **SHOULD**, not a MUST; the variant `http://www.w3.org/2001/10/xml-exc-c14n#WithComments` retains comments. ## What the reference does not tell you Three limits are worth stating out loud, because each is a real production failure: - **It does not say which element the application will read.** Verification selects a subtree by `ID` lookup. Consumption usually selects by position — "the first assertion in the response". When the two selections disagree, the receiver verifies one element and acts on another. - **It does not cover the rest of the document.** A signature over one `<saml:Assertion>` says nothing about a second assertion, about the enclosing `<samlp:Response>`, or about anything added beside it. - **It does not tell you the key was the right one.** `<ds:KeyInfo>` and the `<ds:X509Certificate>` it may carry are attacker-supplied in the sense that matters: a receiver that verifies against the certificate the message brought has established only that the message is self-consistent. The verification key must come from the trust the two parties established beforehand. The digest algorithm also ages. Deployments built when SHA-1 was standard still carry SHA-1 digests and signature methods; current federations use SHA-256-based algorithms, and mismatched algorithm support between two partners is a routine cause of a signature that verifies on one side and not the other.