XML-Signature Syntax and Processing
obsoleted by
- rfc-3275 — (Extensible Markup Language) XML-Signature Syntax and Processing
Extracted elements (29)
Algorithm names (URIs) are included within the signed SignedInfo rather than outside it, specifically to resist attacks where an adversary substitutes a weaker algorithm identifier after the signature is created.
KeyInfo is placed outside SignedInfo and is optional: first, signers may not want to reveal key information to all document processors; second, the key may be known from application context. If the signer wants to bind KeyInfo to the signature, it can be included via a Reference.
No explicit version number is included in the syntax; future incompatible versions will use a different XML namespace URI. This avoids version negotiation complexity and lets the namespace declaration serve as the version discriminator.
The Manifest element was created to allow applications to control which references are validated and what action to take on failure. This addresses use cases where partial validity is meaningful (e.g., some references may fail without invalidating the whole signature) and where multiple signatures share a single large reference list.
Application-specific or non-standard transforms reduce verifiability: 'applications should refrain from using application-specific transforms if they wish their signatures to be verifiable outside of their application domain.' Only standardized transform algorithms guarantee broad interoperability.
Fragment identifiers in the URI attribute may cause interoperability failures if fragment processing is not performed in a standard way (e.g., by a proxy). The specification RECOMMENDS that URI attributes not include fragment identifiers and that such selection be expressed as an XPath Transform instead.
XPointer support beyond null URI and barename XPointer is OPTIONAL; barename and other XPointers in external resources are especially problematic because the application may not control fragment generation, leading to validation failures across implementations.
Compliant implementations MUST implement KeyValue and SHOULD implement RetrievalMethod. Multiple declarations within KeyInfo refer to the same key; multiple X509Data groupings about the same key but different certificates MUST be inside a single KeyInfo.
Dereferencing a same-document null URI (URI="") MUST produce an XPath node-set of every non-comment node in the containing XML document. Applications MUST support the null URI and barename XPointer for same-document references.
During signature validation, the canonical form of the SignatureMethod URI (as produced by canonicalization of SignedInfo) MUST be used; however, the required Canonical XML algorithm does not alter URIs.
If the data object is an octet stream and the next Transform requires a node-set, the application MUST attempt to parse the octets. If the data object is a node-set and the next Transform requires octets, the application MUST convert using the REQUIRED Canonical XML algorithm.
Implementations MUST support Canonical XML [XML-C14N] as the CanonicalizationMethod; this is the only REQUIRED canonicalization algorithm. Minimal canonicalization and Canonical XML with Comments are RECOMMENDED but not required.
References to an XML data element within an Object element SHOULD identify the actual element pointed to; where the content is non-XML, the reference SHOULD indicate Object as the Type. The Type attribute is advisory and no validation of it is required.
SHA-1 is REQUIRED for digest, HMAC-SHA1 is REQUIRED for MACs, DSA-with-SHA1 is REQUIRED for signatures, and Enveloped Signature transform is REQUIRED. RSA-with-SHA1 is RECOMMENDED. Use of MD5 is NOT RECOMMENDED due to known weaknesses.
The XML namespace URI http://www.w3.org/2000/09/xmldsig# MUST be used by implementations of this specification. Implementations MUST support XML and XML namespaces; use of a specific namespace prefix is OPTIONAL.
When dereferencing URIs in the HTTP scheme, implementations MUST comply with HTTP Status Code Definitions including following 302, 305, and 307 redirects to obtain a 200 response body. Applications MUST be able to parse URI syntax.
The KeyInfo element is optional and conveys key identification information such as key names, key values, X.509 certificates, PGP data, SPKI data, or retrieval references. If absent, the recipient is expected to identify the key from application context.
The Manifest element provides an application-controlled list of Reference elements whose digest validation is at application discretion rather than required by core validation. If a Manifest is referenced from SignedInfo, only the digest over the Manifest itself is checked by core validation.
The Reference element specifies a data object to be signed via an optional URI attribute, an optional ordered list of Transforms, a required DigestMethod, and a required DigestValue. The URI attribute may be omitted from at most one Reference per SignedInfo or Manifest.
The Signature element is the root element of an XML Signature, containing SignedInfo (required), SignatureValue (required), KeyInfo (optional), and zero or more Object elements. It may carry an optional Id attribute and MUST reside in the namespace http://www.w3.org/2000/09/xmldsig#.
The SignedInfo element is the actual signed content; it contains a required CanonicalizationMethod, a required SignatureMethod, and one or more Reference elements. The SignatureValue is computed over the canonicalized form of SignedInfo, not over the raw XML bytes.
Algorithm and key length choices critically affect security. MD5 is NOT RECOMMENDED; SHA-1 is REQUIRED but future stronger algorithms are anticipated. Applications must ensure that algorithm identifiers in SignedInfo cannot be substituted by attackers, which the design mitigates by signing the algorithm URIs.
Only what is 'seen' should be signed: signers should use canonicalization methods that reflect the data as it appears to users. Non-XML-aware canonicalization algorithms may fail to account for entity expansions or comments, creating a gap between what is displayed and what is signed.
Only what is signed is secure: when Transforms are applied, the signer is signing the transformed output, not the original document. An application must verify that the transforms produce the expected content, as malicious transforms could sign meaningless or misleading data.
XML Signatures establish only cryptographic integrity and authentication; they do not establish trust or the meaning of the signed data. Applications must independently define key-to-identity bindings and trust policies; a valid signature does not imply that an action should be taken.
DigestValue contains the base64-encoded digest output; for SHA-1 it is the base64 encoding of the 160-bit (20-octet) hash viewed as an octet stream. The CryptoBinary simple type restricts the base type to base64 encoding.
DSAKeyValue encodes P, Q, G, Y as mandatory base64 CryptoBinary fields; J and the pair (Seed, PgenCounter) are optional but should be present if available. RSAKeyValue encodes the modulus and exponent similarly as base64 CryptoBinary.
HMAC-SHA1 output is base64-encoded and may be truncated to a specified bit length via the HMACOutputLength child element of SignatureMethod; if HMACOutputLength is absent, all bits of the hash are output.
SignatureValue is always base64-encoded [MIME] and carries the raw cryptographic output of the SignatureMethod algorithm over the canonicalized SignedInfo. For DSA, the value is the base64 encoding of the concatenated 20-octet I2OSP encodings of integers r and s.