(Extensible Markup Language) XML-Signature Syntax and Processing
obsoletes
- rfc-3075 — XML-Signature Syntax and Processing
Extracted elements (30)
KeyInfo is outside SignedInfo and is therefore optional, for two reasons: the signer may not wish to reveal key information to all parties, and the information may be known from application context. Applications that want to bind key information to the signature can include a Reference to KeyInfo from within SignedInfo.
No explicit version number is included in the XML Signature syntax; if a future version is needed, it will use a different namespace URI. This avoids version negotiation complexity while allowing clean evolution.
The Manifest element exists to allow applications to reserve reference validation logic for themselves: a single SignedInfo can reference one Manifest containing many References, avoiding expensive repeated public-key signature operations over large SignedInfo elements when multiple signatures on the same document set are required.
Use of fragment identifiers in the URI attribute is NOT RECOMMENDED because fragment processing by a proxy may not be standardized, causing reference validation failures. Instead, XPath Transforms are recommended for selecting XML subtrees.
Applications using Canonical XML with Comments (section 6.5.1) or minimal canonicalization alternatives will not interoperate with applications that do not support the specified algorithm. Non-required canonicalization algorithms may also introduce security issues in entity and comment processing.
Comparison of digest and signature values during validation MUST be over the numeric or decoded octet sequence, not the encoded string, because different implementations may produce different base64 encodings (e.g., accidental whitespace differences) of the same underlying value.
Implementations MUST generate laxly schema valid Signature elements as specified by the schema. The Signature element is the root element of an XML Signature and contains SignedInfo, SignatureValue, optional KeyInfo, and zero or more Object elements.
Implementations MUST support the REQUIRED canonicalization algorithm (Canonical XML). Implementations MUST support DSA-SHA1 signature algorithm (REQUIRED). RSA-SHA1 (PKCS1) is RECOMMENDED. SHA-1 as a digest algorithm is REQUIRED. HMAC-SHA1 is OPTIONAL.
The canonical form of the SignatureMethod URI MUST be used during signature validation because canonicalization of SignedInfo may alter relative URIs (e.g., absolutization). However, the required Canonical XML algorithm does not change URIs.
The XML namespace URI that MUST be used by implementations of this specification is 'http://www.w3.org/2000/09/xmldsig#'. While applications MUST support XML and XML namespaces, use of internal entities or the 'dsig' prefix and defaulting/scoping conventions are OPTIONAL.
When processing a same-document reference, dereferencing a null URI (URI='') MUST result in an XPath node-set including every non-comment node of the XML document. Applications MUST support the null URI and barename XPointer; '#xpointer(/)' and '#xpointer(id(ID))' are RECOMMENDED if comments are to be preserved.
XML-based canonicalization implementations MUST be provided with an XPath node-set originally formed from the document containing SignedInfo, indicating SignedInfo, its descendants, and the attribute and namespace nodes. Text-based canonicalization of SignedInfo is NOT RECOMMENDED.
XML signature applications MUST be able to parse URI syntax. Dereferencing a URI in the HTTP scheme MUST comply with the HTTP Status Code Definitions (302, 305, and 307 redirects MUST be followed to obtain the entity-body of a 200 response).
The DSAKeyValue element encodes DSA public key parameters: P and Q (optional pair), G (optional), Y (required), J (optional efficiency parameter), and Seed/PgenCounter (optional paired generation parameters). All fields are encoded as ds:CryptoBinary (base64).
The KeyInfo element is optional and enables recipients to obtain the key needed to validate the signature. It may contain KeyName, KeyValue, RetrievalMethod, X509Data, PGPData, SPKIData, MgmtData, or extension elements. Compliant implementations MUST implement KeyValue and SHOULD implement RetrievalMethod.
The Manifest element provides an optional list of Reference elements that are not subject to mandatory core reference validation (unlike References in SignedInfo). Applications may perform selective or custom reference validation on Manifests, enabling partial-failure semantics.
The Reference element specifies a digest algorithm (DigestMethod), digest value (DigestValue), optional URI identifying the data object, optional Type attribute, and optional Transforms. At most one Reference per SignedInfo or Manifest may omit the URI attribute.
The RSAKeyValue element encodes an RSA public key with two fields: Modulus and Exponent, both encoded as ds:CryptoBinary (base64 big-endian octet strings).
The Signature element is the root of an XML Signature with structure: SignedInfo (required), SignatureValue (required), KeyInfo (optional), Object* (zero or more), and an optional Id attribute. The SignedInfo element is the information actually signed.
The SignatureProperties element within an Object element holds assertions about the signature itself (e.g., time of signing, hardware serial number). Each SignatureProperty MUST have a mandatory Target attribute referencing the applicable Signature element.
The SignedInfo element contains CanonicalizationMethod, SignatureMethod, and one or more Reference elements. It is the content that is canonicalized and then signed; the algorithms used in calculating the SignatureValue are included within SignedInfo.
The X509Data element contains identifiers for X.509 certificates: X509IssuerSerial (issuer DN/serial number pair, SHOULD be RFC 2253 compliant), X509SubjectName, X509SKI (base64 SubjectKeyIdentifier), X509Certificate (base64 DER), and X509CRL. All certificate references within one X509Data element MUST relate to the same certificate.
Applications should select appropriate algorithm identifiers, key lengths, and certificates for their security requirements. The specification defines mandatory (DSA-SHA1, SHA-1, Canonical XML) and optional algorithms, but algorithm strength and key management are application responsibilities.
Only what is 'seen' should be signed and verifiers must 'see' what is signed. A malicious CanonicalizationMethod inside SignedInfo could rewrite URIs, erase itself from SignedInfo, or transform SignedInfo so validation always succeeds. Applications MUST exercise great care before accepting and executing an arbitrary CanonicalizationMethod.
Only what is signed is secure. When transforms are applied, the signer signs the transformed (not native) document. Verifiers must understand and validate the transforms; content excluded by XPath transforms can change without invalidating the signature, which may create security gaps if the excluded content is security-relevant.
XML Signature alone does not specify how keys are associated with persons or institutions, nor the meaning of signed data. Applications must specify additional key, algorithm, processing, and rendering requirements. HMAC-based signatures provide message authentication, not signer authentication.
The Reference Processing Model defines data-type transitions: if the current data object is an octet stream and the next Transform requires a node-set, the application MUST parse the octets as XML; if the data is a node-set and the next Transform requires octets, the application MUST convert using Canonical XML. The final output is an octet stream fed to DigestMethod.
The DigestValue element contains the encoded digest value, always encoded using base64 [MIME], of type ds:DigestValueType (restriction of base64Binary).
The ds:CryptoBinary simple type encodes arbitrary-length integers as base64 [MIME] octet strings: the integer is converted to big-endian bitstring, padded to a multiple of 8 bits, leading zero octets are removed, then base64-encoded. Used for RSA/DSA key parameters.
The SignatureValue element contains the digital signature value always encoded using base64 [MIME]. It is defined as base64Binary (not CryptoBinary) to preserve leading zero octets, e.g., in HMAC-SHA1 output.