XMLDSIG Design Principles and Modes of Use

for RuBoard

To begin our discussion of the XMLDSIG signature standard, we focus on the design principles and specification requirements that guided the work of the IETF/W3C XML Signature Working Group. These requirement and design principles were published in the original charter for the working group and expanded upon in IETF Informational RFC 2807 ” "XML Signature Requirements." Readers interested in the detailed requirements are advised to download the Requirements document from the IETF or W3C Web sites.

NOTE

The "XML-Signature Requirements" document can be found on the Web at http://www.w3.org/TR/xmldsig-requirements or http://www.ietf.org/rfc/rfc2807.txt.

The following is a list of the key requirements and design principles:

1. The specification must describe how to sign digital content, and XML content in particular. The XML syntax used to represent a signature (over any content) is described as an XML signature.

   This is the core requirement for XML digital signatures and it states the overall goal of the standard ”provide a means of digitally signing any content and representing that signature in an XML structure. The requirement that it must be possible to sign non-XML content with an XMLDSIG signature meant that XMLDSIG must support a "detached" mode of operation in which the XML object containing the signature is physically separate from the signed content.

   There are three ways in which an XMLDSIG signature can be associated with some signed content; each method is depicted graphically in Figure 32.1.

   Figure 32.1. Three types of signatures ”wrapped, detached, and enveloped.

   

   • First, the digital signature can be wrapped around the signed content. A wrapped digital signature carries the signed content embedded within it, as shown in Figure 32.1(A). Readers familiar with the S/MIME and OpenPGP secure mail standards will recognize that these standard always (S/MIME) or often (OpenPGP) use wrapped signatures with embedded content. Wrapped signature formats have the advantage that they put the signature and signed content together in a single recognizable package, but necessarily obscure the original format of the signed data.

   • An example detached signature is shown in Figure 32.1(B). Detached signatures are carried in objects physically separated from the signed content. The detached signature may or may not carry an explicit reference to the signed content. In XMLDSIG, detached signatures always contain a reference pointer (URI) to the signed content (part of the ds:Reference element described in detail in "The Structure of an XMLDSIG Signature" section later in this chapter). In contrast, OpenPGP detached signatures do not contain an explicit reference pointer to the signed content.

   • The third and final mode of operation supported by XMLDSIG is the enveloped or embedded signature, shown in Figure 32.1(C). Enveloped signatures embed the digital signature object within the signed content. An enveloped signature can be used only when there exists a mechanism for adding the signature data to the signed content without changing the hash of the signed content. XMLDSIG defines a mechanism (a type of ds:Transform element) that allows signature data to be embedded within another XML document yet ignored when that document is hashed . Enveloped signatures cannot be used with non-XML signed content.

2. The Working Group is not chartered to specify trust semantics, but syntax and processing rules necessary for communicating signature validity (authenticity, integrity, and non- repudiation ).

   Another difference between prior signature standards like S/MIME and XMLDSIG is that XMLDSIG defines only the mechanics of creating and verifying signature cryptographic values and explicitly does not specify a trust model. The S/MIME and OpenPGP standards specify how a verifying application should determine whether the key pair used to create the signature is "trusted" for some purpose. For example, in the case of S/MIME, these semantics are inherited from S/MIME's underlying reliance on PKIX certificates. XMLDSIG explicitly leaves all trust- related questions to the verifying application, recognizing that every application may have different policies concerning what evidence is required to prove a key pair trustworthy.

NOTE

Readers familiar with the concepts of trust management will recognize that by taking this approach, XMLDSIG chose to specify the process of verifying a piece of signed evidence input to an application's trust management engine, but did not specify the behavior of that engine. There were two main reasons for XMLDSIG to take this approach. First, based on the experiences of the IETF PKIX Working Group, it was clear that no fixed standard for policy evaluation could possibly satisfy all customer needs. Second, by explicitly delegating the policy evaluation tasks to the application, XMLDSIG makes clear the difference between cryptographic signature validation and making policy decisions based on the receipt of a signature.

3. The specification must only require the provision of key information essential to checking the validity of the cryptographic signature. For example, identity and key recovery information might be of interest to particular applications, but they are not within the class of required information defined in this specification.

   The third major requirement of XMLDSIG is a prohibition on requiring any sort of key validation information to be included within the Signature objects. Furthermore, key-related information provided in the Signature is present only to provide "hints" to the verifying application. This requirement flows naturally from requirement 2; if XMLDSIG is not required to follow any specific trust model, by extension information related to making a policy determination about a key pair cannot be required to be present. XMLDSIG does define XML structures for carrying commonly used key validation information within a Signature ; these are the various child elements of the KeyInfo element and are discussed in "The Structure of an XMLDSIG Signature" section later in this chapter.

4. The specification must define or reference at least one method of canonicalizing and hashing the signature syntax.

5. XML signatures are generated from a hash over the canonical form of a signature.

   The previous two requirements deal with canonicalization algorithms. Recall from Chapter 31, "Using Cryptography with the .NET Framework: Advanced Topics," that digital signatures over digital content are generally computed by signing the hash of the digital content. That is, the to-be-signed content is converted into a sequence of bytes, the sequence of byte is hashed by a cryptographic hash function, and the output hash value is the input to the digital signature function. Because the output hash value is sensitive to changes in each and every bit of the content, changing any bit of the content will yield a different hash value and invalidate the digital signature. Canonicalization deals with the first step in the process, the conversion of an XML document into a sequence of bytes.

   At first, you would probably think that converting an XML document in a sequence of bytes would be easy. After all, XML documents are text documents containing Unicode characters (or a subset of Unicode characters, such as ASCII characters ), and each Unicode character can be encoded as a sequence of bytes using standard encodings (for example, UCS-2 or UTF-8). The problem with this straightforward approach is that there are often multiple ways of writing the same XML object and, ideally , we want XML documents with the same semantic content to have the same hash value. For an illustrative example, consider the simple XML fragment shown in Listing 32.1.

   Listing 32.1 A Simple XML Fragment

    <MyElement attribute1=foo attribute2=bar>   MyValue </MyElement> 

   This XML fragment shows a single XML element, MyElement , with two attributes ( attribute1 and attribute2 ) and one enclosed text value (the string "MyValue" ). Now compare this fragment with the fragment shown in Listing 32.2.

   Listing 32.2 Another Simple XML Fragment

    <MyElement attribute2=bar attribute1=foo>   MyValue </MyElement> 

   The only difference between the XML fragments in Listings 32.1 and 32.2 is the order in which attributes are listed after the opening MyElement element tag; both fragments represent the same abstract XML object, but their textual representations are quite different. If we naively convert an XML document (or fragment) into a byte sequence without taking into account equivalent semantic forms of an XML object, we will end up computing two different hashes for the objects in Listings 32.1 and 32.2, and thus two different signature values. Once signed, semantic-neutral processing of the signed XML content will potentially break the digital signature, yet XML processors are allowed to rewrite XML as much as they want as long as the rewrites are semantically neutral.

   The answer to the problem illustrated in Listings 32.1 and 32.2 is to define for each XML expression a canonical form for that expression. The canonical form of an XML document has the same semantic content as the original document, and there is one and only one canonical form for every set of semantically equivalent XML documents. An XML canonicalization algorithm converts any XML document (or document fragment) into its corresponding canonical form. Thus, the hashes computed from the canonical forms of Listings 32.1 and 32.2 will be equal because their semantic content is identical. Returning to requirements 4 and 5, we now see why it was critical for the standard to include a canonicalization algorithm for XML. To the extent possible, signatures over XML objects needed to be resistant to permissible (semantically neutral) rewrites of the signed content as it moves around the network.

   In parallel to the development of the XMLDSIG standard, the Working Group also defined a standard for Canonical XML and the algorithm for computing the canonical form of any XML object. The detailed operation of the Canonical XML algorithm is beyond the scope of this book; interested readers can download the specification from the IETF and W3C Web sites. The .NET Framework includes an implementation of the Canonical XML algorithm for internal use by the XMLDSIG-related classes.

NOTE

The Canonical XML algorithm is often abbreviated C14N because there are 14 letters between the initial "c" and final "n" in the word canonicalization.

6. XML signatures must be able to apply to a part or totality of an XML document.

   Another major requirement for XML digital signatures necessitated a design that allowed digital signatures to be computed over subsets of an entire XML document. Previous digital signature standards, including both S/MIME and OpenPGP, always computed signatures over the entire content that they wrapped. While sufficient for e-mail application, always signing the entire document content blocks key workflow and online forms scenarios. Consider, for example, an online form that will be partially filled out by Alice and then completed by Bob, as illustrated in Figure 32.2. Alice wants to be able to sign the incomplete document at the time she finishes her portion of work to attest to her contribution to the document. After Alice finishes and passes the signed, partially completed document on to Bob, Bob will add additional information to the document. As long as Bob doesn't modify any of Alice's contributions, we want Alice's signature to continue to verify. At the same time, we do not want Alice's signature to cover the portions of the document that Bob will fill in. Thus, Alice needs to be able to specify exactly which portions of the compound document she is signing. Bob also has the choice of signing just the portion of the document he completed, or Bob may want to sign the combination of Alice's content and his own. These two possibilities are illustrated in Figure 32.3.

   Figure 32.2. Sample online form scenario: Alice and Bob must each complete portions of the form.

   

   Figure 32.3. Two ways for Alice and Bob to sign the form.

   

   In Figure 32.3(A), Alice and Bob each sign their respective portions of the document, and Alice's signed content does not overlap any portion of Bob's signed content. In contrast, Figure 32.3(B) shows Alice's signature over part of the document and Bob's subsequent signature over both Alice's content and his own additions.

NOTE

A brief digression about time is in order here, specifically the signing time of the four signatures illustrated in Figure 32.3. Unless there is specific evidence included within the digital signature, it is not possible to tell in either scenario A or scenario B which signature was created first.

In Figure 32.3(A), Alice's signature is completely disjoint from Bob's signature, and it is quite possible that the two signatures were computed without any knowledge of the overall document or any relationship between the two signed contents. Alice's and Bob's signatures may have been created in different locations and only merged together into a single document after all the pieces of the document were brought together.

The situation depicted in Figure 32.3(B) is a little more subtle. Here, we know that the content signed by Bob strictly includes the content signed by Alice. However, we do not know when Bob created his signature relative to Alice creating her signature. At the time Bob creates his signature, he sees Alice's content and his own content, but he is not required to see Alice's signature because he is not signing Alice's signature. Therefore, it is actually possible in this scenario for Bob to sign in parallel with Alice, or even before Alice, because their respective signatures are added after the fact. Because there is no temporal relationship between Alice's signature and Bob's signature, the two signatures are independent ”they could have been made in any order.

7. XML signatures are first class objects themselves and consequently must be able to be referenced and signed.

   In some scenarios, such as document workflow or online forms applications, it is often desired to represent a chain of processing steps by a series of "chained" signatures, where subsequent signatures sign previous signatures in the chain.

   For example, consider the loan application scenario depicted in Figure 32.4. In this scenario, Alice applies for a loan through an online loan application form. She fills in some fields on the application, such as her current income and assets, signs the partially completed application, and submits it. The application is then routed to Bob, a loan officer. Bob performs two tasks with the application ”he verifies the information Alice submitted, and he also adds information about Alice's credit rating to the loan. Bob then signs the entire document, including Alice's original signature on the portion she completed. Bob's signature explicitly includes Alice's signature as a piece of content, because Bob wants to commit to what Alice signed, not just what information she provided. Bob's signature is, in effect, a counter-signature on Alice's signature. Counter-signatures (sometimes also called a cascaded signature ) are signatures over other signatures, and they are easy to create in XMLDSIG because every Signature element is also content that can be signed.

   Figure 32.4. Cascaded signatures: Bob's signature over Alice's signature implicitly signs Alice's content.

   

8. The specification must permit arbitrary cryptographic signature and message authentication algorithms, symmetric and asymmetric authentication schemes, and key agreement methods .

9. The specification must specify at least one mandatory to implement signature canonicalization, content canonicalization, hash, and signature algorithm.

   The last major design requirement for XML Digital Signatures deals with the underlying cryptographic algorithms that must be supported by the standard. The requirement has two components . First, XMLDSIG was required to be algorithm-neutral; it must be possible to use any digital signature algorithm or cryptographic hash function with the structures defined in the standard.

   Second, for interoperability purposes, the standard had to define a set of mandatory-to-implement algorithms that would be guaranteed to be present and supported in every conforming implementation. The cryptographic algorithms specified in XMLDSIG are listed in Table 32.1. Required algorithms are mandatory-to-implement in all conforming applications; it is guaranteed , for example, that an XMLDSIG processor will be able to parse and understand a Signature block made using a DSA signature key. Recommended algorithms are not guaranteed to be present but are expected to be implemented in most implementations . RSA-SHA1 digital signatures are generally supported by implementation (including the .NET Framework) but is not a mandatory-to-implement algorithm.

Table 32.1. XMLDSIG Required and Recommended Algorithms

Algorithm Type	Algorithm	Status
Digest (hash function)	SHA1	Required
Signature	DSA with SHA1	Required
	RSA with SHA1	Recommended
MAC	HMAC-SHA1	Required
Canonicalization	Canonical XML (C14N)	Required
	Canonical XML with Comments	Recommended

This concludes our overview of the requirements that led to the final design of the XML Digital Signature standard. In the next section, we will see how each of these requirements impacts and is reflected in the actual structure of an XMLDSIG Signature element.

for RuBoard