Because the XMLDSIG standard provides a very flexible digital signature mechanism, there are lots of ways to misuse it and produce insecure or misleading results. When designing a system using XMLDSIG, you should consider the factors discussed in this section.
The Transforms mechanism makes it easy to sign data derived from processing the content of an identified resource. For instance, an application might wish to sign a form, but permit users to enter limited field data without invalidating a previous signature on the form. The application could use an XPath-based Transform to exclude those portions that the user will change. Transforms can also include encoding changes, canonicalization instructions, or even XSLT and user-defined transforms. Note the following three cautions with respect to this feature:
Only What Is Signed Is Secure
Obviously, signatures over a transformed document do not secure any information discarded by transforms: Only what is signed is secure.
When signing XML, use of canonicalization (as described in Chapter 9) is critical. It can ensure that all internal entities and visibly used XML namespaces are expanded within the data being signed. All entities are replaced with their definitions, and the canonical form generally includes or excludes the namespace that an element would otherwise inherit, as appropriately selected by the application designer.
Failure to canonicalize XML content is generally a bad idea. The resulting applications are arguably not XML applications, as they do not strictly follow the XML Recommendation [XML]. Nevertheless, to have a chance of working, such applications should satisfy two criteria:
Information that is not signed but is merely part of an envelope containing signed information is obviously not secured. For instance, unsigned recipient headers accompanying signed information within an encrypted envelope do not have their authenticity or integrity protected.
Only What Is "Seen" Should Be Signed
If the intent of signing is to convey the judgment or consent of a user (an auto mated mechanism or person), then it is normally necessary to secure, as closely as possible, the information as presented to that user. Applications could accomplish this by literally signing what was shown a user, such as a screen image. However, the result would be difficult for subsequent software to manipulate. Instead, applications can sign the data along with whatever filters, style sheets, client profile or other information that affects its presentation. But there are practical limits. For example, if the data were viewed through a browser, it would be reasonable to secure any style sheets used and perhaps the browser version. However, it would almost certainly not be practical or worthwhile to sign and preserve a complete copy of the browser and operating system that the browser was running on.
"See" What Is Signed
In a context where a user is seeing and approving something, the user should sign only what he or she "sees." Persons and automated mechanisms that trust a transformed document on the basis of a valid signature should operate over the data that were transformed and signed, not the original, pre-transformation data.
This recommendation applies to transforms specified within the signature as well as those that are part of the document itself. For instance, if an XML document includes an embedded style sheet [XSLT], then the transformed document should be presented to the user and signed. When a document references an external style sheet or external data having a visible effect, then a signature Reference should also sign the content of that external resource. Failure to do so could permit later change of that external data, thereby altering the resulting document without invalidating the signature.
Some applications might operate over the original or intermediary data. In such a case, they should be careful about potential weaknesses that can occur between the original and transformed data. This kind of a trust decision about the character and meaning of the transforms creates a situation in which a system designer needs to exercise caution. Consider a canonicalization algorithm that normalizes character case (lowercase to uppercase) or character composition ("e and accent" to "accented-e"). An adversary could introduce changes that are normalized and therefore inconsequential to signature validity but material to a Document Object Model (DOM) processor.
For instance, by changing the case of a character, you might influence the result of an XPath selection or database query. A serious risk is introduced if that change is normalized for signature verification but the processor operates over the original data and returns a different result than intended. Consequently, while it is recommended that all documents operated on and generated by signature applications appear in "normal form C" [NFC], encoding normalization should not occur as part of a signature transform operation.
10.6.2 Check the Signature Security Model
XMLDSIG provides signature algorithms based on public key signatures and keyed hash authentication codes. These algorithms rely on substantially different security models. Furthermore, XMLDSIG permits user-specified algorithms that may utilize still other models. (See also Chapter 2 on this topic.)
With public key signatures, any number of parties can hold the public key and verify signatures, even though only the parties with the private key can create signatures. It is preferable to minimize the number of holders of the private key, keeping it as close to one holder as practical. An important issue is confidence by verifiers in the public key used and its binding to the entity or capabilities represented by the corresponding private key. Certificate or online authority systems usually address this issue.
Keyed hash authentication codes, based on secret keys, usually work much more efficiently than do public keys in terms of the computational effort required. Unfortunately, all verifiers need to have the same key as the signer with such systems, which means that any verifier can forge signatures.
XMLDSIG permits user-provided signature algorithms and keying information designators. Such user-provided algorithms might have other security models. For example, methods involving biometrics depend on physical characteristics of the authorized user that cannot be changed in the same way that public or secret keys can be; they might have other security model differences as well.
10.6.3 Signature Strength
The strength of a particular signature (i.e., how difficult it is to forge a signature on new or altered data) depends on all links in the security chain. They include, but are not limited to, the following:
A system's overall security also depends on the security and integrity of its operating procedures, its personnel, and the administrative enforcement of those procedures. All factors mentioned in this section are important to the overall security of a system; most, however, are beyond the scope of the XML Signature, Encryption, and other XML Security recommendations.
10.6.4 Algorithms and Executable Content Caution
Applications must exercise care when executing the various algorithms specified in an XML digital signature. They must also exercise care when processing any "executable content" that might be provided to such algorithms as parameters, such as [XSLT] transforms. A trusted library will usually implement the algorithms specified by the standards. Even there, however, perverse parameters might cause unacceptable processing or place overwhelming demands on memory. Application-defined algorithms might warrant even more care.