SignedInfo in XML-DSig and Canonical Hashing

The SignedInfo element is the core component of an XML Digital Signature (XML-DSig) structure that binds the protected data, the cryptographic algorithms, and the digest values together. This article explains the role of the SignedInfo element within the XML-DSig standard, how it functions as the actual payload of the digital signature, and why it must undergo canonicalization and hashing before the cryptographic signature is applied.

What is the SignedInfo Element?

In an XML-DSig structure, the <Signature> element encapsulates the entire digital signature. Within it, <SignedInfo> is the sub-element that defines precisely what is being signed and which algorithms are being used to perform the operation.

A standard <SignedInfo> element contains three key child components:

• <CanonicalizationMethod>: Specifies the canonicalization algorithm (such as Canonical XML 1.0 or 1.1, with or without comments) used to normalize the <SignedInfo> element itself before signing.
• <SignatureMethod>: Defines the cryptographic algorithm used to generate and verify the signature, such as RSA-SHA256 or ECDSA-SHA256.
• <Reference> Elements: Contains one or more references to the signed data objects. Each <Reference> includes:
  • A URI pointing to the target data (which can be inside or outside the XML document).
  • Optional <Transforms> applied to the target data.
  • A <DigestMethod> indicating the hashing algorithm used on the referenced data.
  • A <DigestValue> containing the actual base64-encoded hash of the referenced data.

Rather than signing the raw payload data directly, XML-DSig signs the <SignedInfo> element itself. Because <SignedInfo> securely contains the cryptographic digests (<DigestValue>) of the referenced payloads, any modification to the underlying data invalidates its digest, which in turn invalidates the signature over <SignedInfo>.

Why is SignedInfo Canonically Hashed?

Hashing and canonicalization serve two distinct, essential purposes in creating a reliable XML digital signature.

1. The Need for Hashing

Asymmetric cryptographic signing algorithms (like RSA or ECDSA) are computationally expensive and strictly limited by key size regarding the amount of data they can sign directly. Hashing reduces the <SignedInfo> XML structure to a small, fixed-length digest. The signer’s private key then encrypts (signs) this digest rather than the full XML markup, ensuring high performance and cryptographic security.

2. The Critical Role of Canonicalization (C14N)

XML documents can be syntactically altered without changing their semantic meaning. For example, intermediate network proxies, parsers, or serialization libraries might:

• Reorder attributes within an element.
• Convert character encodings (e.g., UTF-8 to UTF-16).
• Add, remove, or alter insignificant whitespace and line breaks (\r\n vs. \n).
• Normalize namespace prefixes and declarations.
• Convert empty elements from <tag></tag> to <tag/>.

Cryptographic hash functions are extremely sensitive to binary changes. A change of a single byte or space creates an entirely different hash value, causing signature verification to fail even if the underlying XML data is logically unchanged.

To prevent false signature validation failures, the <SignedInfo> element must be transformed into its canonical form (standardized XML representation) before it is hashed and signed. Canonicalization ensures that both the sender and the receiver generate the exact same byte stream from the <SignedInfo> element, regardless of how an XML parser formats or renders the physical document. Once canonicalized, the resulting deterministic byte sequence is hashed and cryptographically verified.