Safeguarding the Identity and Integrity of XML Messages

XML Signature and XML Encryption, two of the three major pillars of the WS-Security standard, are so predominant in current thinking about Web Services Security that some people mistake them as the only strategy for securing Web services. This is really not the case at all. Read more in this chapter from Securing Web Services with WS-Security, by Rosenberg and Remy (ISBN 0672326515, SAMS, 2004).

Securing Web Services with WS-SecurityIntroduction to and Motivation for XML Signature

Chapter 2, “The Foundations of Web Services,” and Chapter 3, “The Foundations of Distributed Message-Level Security,” provided an overview of Web services (including XML) and security concepts. This chapter and the next bring two of the key security principles—confidentiality and integrity—into the world of XML. Confidentiality, in the world of XML, manifests itself as XML Encryption. Integrity manifests itself as XML Signature. XML Signature and XML Encryption are fundamental strategies for securing XML and are pillars of WS-Security. Because XML is one of the foundations of Web services, it follows that these two technologies are extremely important to understand and apply when you are implementing secure Web services.

A W3C Standard

XML Signature (as discussed in Chapter 3) is a joint standard of the IETF and the W3C for digitally signing all of an XML document, part of an XML document, or even an external object. Similarly, XML Encryption is a W3C standard, which followed XML Signature, for encrypting all of an XML document, part of an XML document, or an external object. Actually, you can sign or encrypt pretty much anything you can point to with a URL.

Critical Building Block for WS-Security

XML Signature and XML Encryption are fundamental to the next generation of emerging standards that use these two standards as building blocks. For example, WS-Security, the emerging OASIS standard for Web services security; XML Key Management Specification (XKMS), and Security Assertion Markup Language (SAML), among many others, all rely on XML Signature and/or XML Encryption.

Close Associations with Web Services Security

XML Signature and XML Encryption, two of the three major pillars of the WS-Security standard, are so predominant in current thinking about Web Services Security that some people mistake them as the only strategy for securing Web services. This is really not the case at all. When reading Chapter 3, you probably realized that Web Services Security must involve a broad spectrum of security technologies and strategies. Web services involve active use of XML messages across trust domains. Securing the message itself is critical, but it represents only one aspect of the whole Web Services Security picture.

That being said, we encourage you to pay special attention to the information in this chapter and, if you are interested in more detail, to pick up a book that treats this subject in more depth—for example, Secure XML by Donald Eastlake and Kitty Niles(Addison Wesley 2002).

The Goal of Ensuring Integrity (and Usually Identity) and Non-repudiation Persistently

XML Signature technology, like digital signature, is a tool for ensuring integrity and, usually, identity and non-repudiation. XML Signature takes the building block of digital signature as described in Chapter 3 and greatly expands upon it, taking advantage of the power and flexibility of XML as well as key Web technologies (such as URLs) to sign almost any type of resource, whether an XML document, a part of an XML document, or a non-XML object such as an image.

XML Signature and XML Encryption: Fundamental Web Services Security Technologies

You might think that Web Services Security in relationship to XML Encryption and XML Signature is about encrypting and digitally signing SOAP messages. This aspect of the application of these two technologies is certainly important, and this usage is well covered in this book; however, this probably will not be the most important usage for you, as a developer or administrator of Web services, at least in the near future. Web services containers or special Web services firewalls help manage this complexity by signing/encrypting or verifying/decrypting all or parts of the SOAP message based on policies you configure. It really does not make sense for Web services developers to have to worry about the blocking and tackling involved in securing the SOAP payload uniquely for every application and/or operation within a Web service. This operation will become part of the infrastructure. As a Web services developer, you should be able to focus on the SOAP payload itself, which is an XML document. Much of your direct use of XML Signature and XML Encryption will be for your applications themselves to take advantage of the power of these technologies to enrich the functionality of your systems.

The goal of this chapter is to inform you how XML Signature works while not burying you with too much detail. This standard is powerful and complex, so we focus on the parts that we think will be most applicable.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=XML Signature Fundamentals}

XML Signature combines the utility and power of digital signature technology with the power and flexibility of XML. An XML Signature is itself a piece of XML, and there is a corresponding XML Schema for how this XML will be structured. Within the XML Signature itself are references—URIs—to what is being digitally signed. These references are quite flexible as they can point to items within the same document or be external. Also, a single XML document can contain multiple XML Signatures. This flexibility and power make XML Signature technology somewhat complex when you consider the details. However, the basic concepts are not very difficult to understand, and the structure for an XML Signature, which is always rooted at the Signature element, provides a nice guide for understanding how XML Signatures work.


XML Signature Requirements - Understanding the formal requirements that were provided/gathered by the W3C Working Group can help you understand why certain parts of the standards turned out the way they did. The following are some of the key requirements that stand out (you can see the full requirements at http://www.w3.org/TR/xmldsig-requirements):

  • XML Signatures apply to any resource addressable by a “locator” (uniform resource identifier), including non-XML content.

  • XML Signatures must be able to apply to a part or the whole XML document.

  • Multiple XML Signatures must be able to exist over the static content of a Web resource.

  • The specification must permit the use of varied digital signature and message authentication codes, such as symmetric and asymmetric authentication schemes as well as dynamic agreement of keying material.

Other specified requirements affect the resulting standards as well, but considering these four demonstrates that XML Signatures are not just a simple application of digital signature technology on a piece of XML text. They are much more.


SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=XML Signature Structure}

In the following sections, we review the XML Signature element’s basic structure and discuss its most significant aspects. We stay high level at first and then provide more detail further into the chapter.

Basic Structure

Before we delve deeply into the syntax of the Signature element, let’s discuss it in concept first. At a very basic level, an XML Signature contains four major items, with the third and fourth being optional:

  1. A set of pointers (references) to things to be signed

  2. The actual signature

  3. (Optional) The key (or a way to look up the key) for verifying the signature

  4. (Optional) An Object tag that can contain miscellaneous items not included in the first three items

The syntax of the Signature element is shown in Listing 4.1.

Listing 4.1 The Syntax of the <Signature> Element

<Signature>
  <SignedInfo>
    (CanonicalizationMethod)
    (SignatureMethod)
    (<Reference (URI=)? >
      (Transforms)?
      (DigestMethod)
      (DigestValue)
    </Reference>)+
  </SignedInfo>
  (SignatureValue)
  (KeyInfo)?
  (Object)*
</Signature>

Listing 4.2 is a highly oversimplified XML Signature snippet to give you a feel for what an XML Signature might look like if it is cut down to its bare essence.

Listing 4.2 A Highly Simplified XML Signature Snippet

<Signature xmlns=”http://www.w3.org/2000/09/xmldsig#”>
 <SignedInfo>
  <Reference URI=”
http://www.foo.com/secureDocument.html” />
 </SignedInfo>
 <SignatureValue>…</SignatureValue>
 <KeyInfo>…
 </KeyInfo>
</Signature>

In this example, the three children of the Signature element are the SignedInfo element, the SignatureValue element, and the KeyInfo element. The SignedInfo element contains information about what is being signed, the SignatureValue element contains the actual signature bits, and the KeyInfo element contains information about the public key needed to validate this digital signature. Of course, this example is highly simplified; there is more detail to each of these elements, and there are more elements to discuss. However, these are the most significant three elements within a typical XML Signature.

Specifying the Items Being Signed

The set of pointers, represented by the Reference element, can point to an internal resource in the XML document, in which case they point to an XML node, or they can be external. If they are external, they can point to a binary or non-XML file (for example, an image or text document), or they can point to another XML document or even a node within another XML document. We discuss this usage in more depth in the section titled “The Reference Element.” The content behind these references is what is being signed.

Understanding this reference concept is important because it can affect the meaning and usage of XML Signatures substantially. Most descriptions of XML Signature describe three classifications of XML Signatures: Enveloping, Enveloped, and Detached. Each reflects where the Reference element is pointing. Let’s go through these three types of XML Signatures and then come back to that point.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=Types of XML Signatures}

As we mentioned previously, when reading about or discussing XML Signature, you will often hear about three different types of XML Signatures: Enveloping, Enveloped, and Detached. In the next three sections, we describe each of these signature types and show you how they work.

Enveloping Signatures

An Enveloping Signature wraps the item that is being signed, as shown in Figure 4.1. Later, we discuss specifically how this is done, but for now suffice it to say that the reference is to an XML element within the Signature element itself. The following simplified example in Listing 4.3 shows what an Enveloping Signature might look like (notice that the URI points to an item within the Signature Object element):

Listing 4.3 A Simplified Enveloping Signature

<Signature xmlns=”http://www.w3.org/2000/09/xmldsig#”>
 <SignedInfo>
  <Reference URI=”#111″ />
 </SignedInfo>
 <SignatureValue>…</SignatureValue>
 <KeyInfo>…</KeyInfo>
 <Object>
   <SignedItem id=”111″>Stuff to be signed</SignedItem>
 </Object>
</Signature>

Safeguarding the Identity and Integrity of XML Messages

Figure 4.1  Structure of an Enveloping Signature.

Enveloped Signatures

In an Enveloped Signature, the reference points to a parent XML element, as shown in Figure 4.2. The following simplified example in Listing 4.4 shows what an Enveloped Signature might look like (notice that the Reference is to an element that is a parent of the Signature):

Listing 4.4 A Simplified Enveloped Signature

<PurchaseOrder id=”po1″>
 <SKU>125356</SKU>
 <Quantity>17</Quantity>
 <Signature xmlns=”
http://www.w3.org/2000/09/xmldsig#”>
  <SignedInfo>
   <Reference URI=”#po1″ />
  </SignedInfo>
  <SignatureValue>…</SignatureValue>
  <KeyInfo>…</KeyInfo>
 </Signature>
</PurchaseOrder>

Introduction To and Motivation for XML Signature

Figure 4.2  Structure of an Enveloped Signature.

Detached Signatures

Finally, a Detached Signature points to an XML element or binary file outside the Signature element’s hierarchy. In other words, the item being pointed to is neither a child (Enveloping Signature) nor a parent (Enveloped Signature) of the Signature element. Therefore, a Detached Signature could point to an element within the same document, as shown in Figure 4.3, or to a another resource completely outside the current XML document, as shown in Figure 4.4. The following example in Listing 4.5 of a Detached Signature points to another XML element within the same XML document but is not an ancestor or child of the Signature:

Listing 4.5 Structure of a Detached Signature

<PurchaseOrderDocument>
 <PurchaseOrder id=”po1″>
  <SKU>12366</SKU>
  <Quantity>17</SKU>
 </PurchaseOrder>
 <Signature xmlns=”
http://www.w3.org/2000/09/xmldsig#”>
 <SignedInfo>
  <Reference URI=”#po1″ />
 </SignedInfo>
 <SignatureValue>…</SignatureValue>
 <KeyInfo>…</KeyInfo>
</Signature>

Introduction To and Motivation for XML Signature

Figure 4.3 Structure of a Detached Signature within the same
XML document.

A Detached Signature can also point to an external resource such as another XML document, a node in another XML document, a text file, or generally any type of resource that can be referenced by a URI, as shown in Figure 4.4. The following simplified example in Listing 4.6 of a Detached Signature points to a JPEG file:

Listing 4.6 A Detached Signature of an External JPEG File

<Signature xmlns=”http://www.w3.org/2000/09/xmldsig#”>
 <SignedInfo>
  <Reference URI=”
http://www.foo.com/picture.jpg” />
 </SignedInfo>
 <SignatureValue>…</SignatureValue>
 <KeyInfo>…</KeyInfo>
</Signature>

Safeguarding the Identity and Integrity of XML Messages

Figure 4.4  Structure of Detached Signature referencing an
external resource.

Even though these are often called signature types, even in the XML Signature specification, they are really about references. It would be more accurate to describe them as Enveloping Reference, Enveloped Reference, and Detached Reference. Then the next statement becomes more understandable. An XML Signature can be enveloping, enveloped, and detached all at the same time! This means that the Signature element can contain more than one Reference element, and a Reference element can be enveloping, enveloped, or detached.

We wanted to give you the highest level overview of XML Signature and emphasize that XML Signature is mostly just one or more pointers (references) that can point to XML elements, internal or external to the Signature itself, or to an external resource. These pointers are dereferenced and grouped together; then they go through a signature process resulting in a signature. All of this—the pointers, the signature itself, and, optionally, the key information to validate the signature—goes into an XML Signature element.

Now let’s go to the next level of detail and explore the different aspects of the Signature element.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=The Signature Element Schema}

Look at Listing 4.7 for an XML shorthand schema for the Signature element. It comes directly from the XML Signature specification1 and, for convenience, is a repeat of the schema shown previously. Understanding this structure is key to understanding XML Signature.

Listing 4.7 XML Shorthand Schema for the <Signature> Element

<Signature ID?>
 <SignedInfo>
  <CanonicalizationMethod/>
  <SignatureMethod/>
  (<Reference URI? >
   (<Transforms>)?
   <DigestMethod>
   <DigestValue>
   </Reference>)+
 </SignedInfo>
 <SignatureValue>
 (<KeyInfo>)?
 (<Object ID?>)*
</Signature>


Reading an XML Shorthand Schema - A common shorthand for describing XML is to show the XML syntax with a set of “cardinality” indicators, the number of times that an element can occur. If there is always exactly one, there is no cardinality indicator. If there can be zero or one occurrence, the element or attribute is given a question mark (?) cardinality indicator. If the element or attribute can have one or more occurences, the element or attribute is given a plus sign (+) cardinality indicator. And finally, if the element or attribute can have zero or more occurences, the element or attribute is given an asterisk (*) cardinality indicator.

If an element has a cardinality indicator, it is usually wrapped in parentheses, and the cardinality indicator appears after the closing parenthesis. For example, in the XML Signature shorthand schema, the KeyInfo element is represented as (<KeyInfo>)?, which means that the KeyInfo can exist one or zero times. The Object element, shown as (<Object ID?>)*, can appear zero or more times, and its ID attribute can exist zero or one time within an Object attribute.


You need to familiarize yourself with this shorthand schema at a high level before you focus on each element. The more familiar you become with this schema, the better. A Signature must have at least a SignedInfo and a SignatureValue. A Signature can optionally have a KeyInfo or an Object. For now, just think of the Object as the place to put the thing that is being signed when you have an Enveloping reference.

At the next level, the SignedInfo must contain a CanonicalizationMethod, a SignatureMethod, and one or more Reference elements.

At a high level, canonicalization is a strategy for standardizing XML structures so that they compare the same across multiple platforms or different equivalent XML syntax. CanonicalizationMethod is a pointer to the actual algorithm used to do this. We discuss this in more detail in “The CanonicalizationMethod Element and Canonicalization” section later in this chapter.

SignatureMethod is a pointer to the signature algorithm (one you will be familiar with from Chapter 3) used to calculate the digital signature.

The Reference elements are the pointers to what is being signed. The Reference element has a URI attribute, which is the actual pointer we alluded to earlier. We talk more about URIs later, but you need to understand now that the power and flexibility of URIs to point to just about any type of resource are critical to the power and flexibility of XML Signature. The Reference element can optionally contain one or more Transform elements—a powerful, necessary, but potentially dangerous, way of changing the document in some fashion before it is digested. Finally, the Reference element has a DigestMethod that contains the one-way hash algorithm (for example, SHA1) used to calculate the DigestValue for the Reference.

These elements are in SignedInfo, which is the XML block representing the information that will be signed.

The SignatureValue element is a digital signature of the SignedInfo block. This is an important point: What is signed is the SignedInfo block, not what was referenced in the SignedInfo block. In reality, both are signed at the same time because, if you remember from Chapter 3, with a digital signature you are encrypting/signing a digest. By digitally signing the SignedInfo block, which contains the digest of the references, you are not only signing the references, but you are also signing critical information about the signature itself, such as which signature algorithm was used, so that these items are also protected. This is required because it might be possible, by fiddling with the type of information that is in the SignedInfo element, to compromise a signature. The SignatureValue has no children; it just has the Base-64 encoded value of the binary signature data in it.

These two elements, SignedInfo and SignatureValue, are the guts of an XML Signature. Optionally, you can have a KeyInfo block that either contains the key to use for verifying the signature or has information necessary to look up such a key. KeyInfo has many children and is fairly complex. Also, under the Signature element, you can have an Object element. We discuss both KeyInfo and Object in more detail later in this chapter.

Now that we have quickly gone through most of the elements that comprise an XML Signature, let’s look at a fuller but still simplified snippet of an XML Signature in Listing 4.8.

Listing 4.8 A Fuller XML Signature Example

<Signature xmlns=”http://www.w3.org/2000/09/xmldsig#”>
 <SignedInfo>
  <CanonicalizationMethod
    Algorithm=”
http://www.w3.org/TR/2000/WD-xml-c14n-20001011” />
  <SignatureMethod Algorithm=”
http://www.w3.org/2000/09/xmldsig#rsa-sha1” />
  <Reference URI=”
http://www.foo.com/securePage.html“>
   <DigestMethod Algorithm=”
http://www.w3.org/2000/09/xmldsig#sha1” />
   <DigestValue>60NvZvtdTB+7UnlLp/H24p7h4bs=</DigestValue>
  </Reference>
 </SignedInfo>
 <SignatureValue>
  hTHQJyd3C6ww/OJz07P4bMOgjqBdznSUOsCh6P+0MpF69w2tln/PFLdx/EP4/VKX
 </SignatureValue>
 <KeyInfo>
  <KeyValue>
   <RSAKeyValue>
    <Modulus>
     uCiukpgOaOmrq1fPUTH3CAXxuFmPjsmS4jnTKxrv0w1JKcXtJ2M3akaV1d/karvJ
    </Modulus>
    <Exponent>
     AQBB
    </Exponent>
   </RSAKeyValue>
  </KeyValue>
  <X509Data>
   <X509SubjectName>
    CN=David Remy,O=BEA Systems Inc,ST=WA,C=US
   </X509SubjectName>
   <X509IssuerSerial>
    <X509IssuerName>
     CN=Test CA,O=GeoTrust Inc,ST=MA,C=US
    </X509IssuerName>
    <X509SerialNumber>167355</X509SerialNumber>
   </X509IssuerSerial>
   <X509Certificate>
    MIICeDCCAeGgAwIBAgIEOd3+iDANBgkqhkiG9w0BAQQFADBbMQswCQYDVQQGEwJJ
    …
    C/I/k9xGr7fneoIW
   </X509Certificate>
  </X509Data>
 </KeyInfo>
</Signature>

As you can see, this XML Signature signs the Web page http://www.foo.com/securePage.html. Of course, you know this because you looked at the Reference element child of the Signature element (bold in the preceding code snippet). A lot of other information is also included in an XML Signature. As you will see in the following sections, each piece of information plays a significant role.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=XML Signature Processing}

We have reviewed at a high level the XML Signature elements. Now let’s review how an XML Signature is created and then subsequently verified before we go into each element in more detail. This process is actually relatively straightforward. The basic steps are described in the following sections. (Note that unless you are writing a signature processing engine, you won’t be performing this process yourself. This description is provided mainly so that you understand what is going on under the covers.)

XML Signature Generation

XML Signature generation is broken down into two components: Reference generation and Signature generation.

Reference Generation

When generating an XML Signature, an XML Signature processing engine first creates all the References. This process involves iterating through all the data objects that are to be signed and calculating their digest value. This basic process is as follows:

  1. Obtain the resource specified by the Reference URI or, if not specified, as determined by the application. Note that seeing XML Signatures that do not use that Reference element to refer to what is being signed is rare; however, the specification allows for the possibility that what is being signed is known from the context of the situation and therefore does not have to be specified.

    In the example earlier, the reference http://www.foo.com/securePage.html would be dereferenced.

  2. Apply the Transforms.

    Transforms were used in the earlier example. A simple Transform might be an XPath statement that causes the signature to apply only to a part of an XML document. We describe Transforms in more detail later in the chapter.

  3. Calculate the Digest using the DigestMethod specified. This step results in the creation of the DigestValue element.

  4. Create the Reference element, including all the sub-elements described previously.

At the end of Reference generation, the XML Signature processing engine will have everything necessary to generate the Reference element. In the simple example used earlier, this looks like Listing 4.9.

Listing 4.9 The XML Signature <Reference> Element

<Reference URI=”http://www.foo.com/securePage.html“>
 <DigestMethod Algorithm=”
http://www.w3.org/2000/09/xmldsig#sha1” />
 <DigestValue>60NvZvtdTB+7UnlLp/H24p7h4bs=</DigestValue>
</Reference>

Signature Generation

After all the Reference elements are created, the XML processing engine can create the Signature itself. To do this, it must gather all the information necessary to create the SignedInfo element, which is what is actually signed in an XML Signature. Here are the steps:

  1. Create the SignedInfo element itself, including the Reference objects created in Reference generation and the CanonicalizationMethod, SignatureMethod, and DigestMethod. The information in SignedInfo is what is actually signed. Listing 4.10 shows the SignedInfo from the earlier example.

    Listing 4.10 The <SignedInfo> Element

    <SignedInfo>
     <CanonicalizationMethod
       Algorithm=”http://www.w3.org/TR/2000/WD-xml-c14n-20001011″ />
     <SignatureMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#rsa-sha1″ />
     <Reference URI=”http://www.foo.com/securePage.html”>
      <DigestMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#sha1″ />
      <DigestValue>60NvZvtdTB+7UnlLp/H24p7h4bs=</DigestValue>
     </Reference>
    </SignedInfo>

  2. Canonicalize SignedInfo using the CanonicalizationMethod specified. We talk in detail about canonicalization later, but suffice it to say that whenever XML is being signed, it needs to be “normalized” before creating the hash and actually signing the SignedInfo information.

  3. Using the output from the canonicalization algorithm, create a hash of the SignedInfo element using the specified DigestMethod.

  4. Calculate the SignatureValue using the algorithm specified in SignatureMethod against the hashed, canonicalized SignedInfo element that was calculated in step 3. Listing 4.11 shows the SignatureValue element from the earlier example:

    Listing 4.11 The <SignatureValue> Element

    <SignatureValue>
     hTHQJyd3C6ww/OJz07P4bMOgjqBdznSUOsCh6P+0MpF69w2tln/PFLdx/EP4/VKX
     </SignatureValue>

  5. Bundle the SignedInfo, SignatureValue, KeyInfo (if supplied), and Object (if necessary) into the Signature element.

You now have an XML Signature. The key point to remember here is that the SignedInfo element is what is really being signed, not the direct resource(s) targeted by the Reference URI(s). Of course, because a digest of the target URI(s) is included in the SignedInfo element, it is being indirectly signed along with the information about the signature in the SignedInfo element.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=XML Signature Validation}

The process to validate an XML Signature is similar, except that it occurs in reverse. It is composed of two major processes like Signature generation: Reference validation and Signature validation. The goal of Reference validation is to ensure that the resource being pointed to by each Reference has not been changed. The goal of Signature validation is to ensure that the entire SignedInfo block has not been changed. Only if both of these processes succeed is integrity confirmed for the entire Signature.

Reference Validation

For Reference validation, you need to validate that the resources pointed to by the Reference elements have not changed. The first step is to canonicalize the SignedInfo element based on the CanonicalizationMethod element. Then the following steps are completed for each Reference element in the SignedInfo.

  1. Get the data that is pointed to in the Reference. This will either be from the URI attribute, or as we mentioned above, it may be supplied by the application calling the XML Signature processing engine.

  2. Apply any Transforms to the data returned. For example, if the Reference URI points to an XML document, it is likely that a Canonicalization Transform will be specified in the Reference element.

  3. Create a hash of the data using the DigestMethod specified in the Reference.

  4. Compare the resulting hash with the DigestValue in the Reference. If there is any difference, the validation fails.

Signature Validation

If Reference validation is successful, the XML Processing engine can proceed to Signature validation. The objective of the Signature validation step is to confirm that SignedInfo has not been changed (integrity) and, as in any digital signature verification, that the appropriate key has signed this information (that is, non-repudiation). Here are the steps for Signature validation:

  1. Obtain the key for verification from the KeyInfo block, or in some other manner. Note that it is critical to determine trust for this key—ensuring that it is certainly bound to the expected identity. You learn more about this topic in Chapter 9, “Trust, Access Control, and Rights for Web Services.”

  2. Using the output of the SignedInfo canonicalization, create a hash of the SignedInfo.

  3. Using the verification key, decrypt the SignedInfo element. Compare the hash from step 2 to the result of this verification. If they do not match, Signature validation has failed.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=The XML Signature Elements}

So far, we have discussed the XML Signature element and its schema at a high level and reviewed the processing steps necessary to create and verify a Signature. In the process, we have glossed over a lot of the specifics; now let’s discuss each element in more detail.

The SignedInfo Element

As we mentioned, the SignedInfo element contains all the information about what is digitally signed. As shown in Listing 4.12, the SignedInfo element contains three children elements—CanonicalizationMethod, SignatureMethod, and zero or more Reference elements.

Listing 4.12 XML Shorthand Schema for the <SignedInfo> Element

<SignedInfo>
  <CanonicalizationMethod/>
  <SignatureMethod/>
  (<Reference URI? >
     (<Transforms>)?
     <DigestMethod>
     <DigestValue>
  </Reference>)+
</SignedInfo>

We describe each of these three elements in turn, starting with CanonicalizationMethod.

The CanonicalizationMethod Element and Canonicalization

Canonicalization is quite a mouthful and is often abbreviated as C14N (14 letters bracketed by the C and the N). The concept behind canonicalization is straightforward, but you wouldn’t know this to look at the amount of discussion and work it has engendered. The W3C has published multiple specifications on canonicalization and the subtle issues surrounding it. It continues to be a well-discussed subject (a recent google search on canonicalization located 35,500 hits). Let’s look at this topic at its simplest level first and then determine where the more subtle issues arise.

As we discussed in Chapter 3, if even a single bit changes in a document that is being signed, the digest (hash) will not be the same, and Signature/Reference validation will fail. With XML, in particular, certain differences may exist between an XML document or XML fragment that has nothing to do with the underlying meaning of the XML but is introduced simply because of the operating system or a difference in the way an XML parser resolves the XML. For example, a file created on a Windows operating system or one created on a Unix operating system typically ends a line of text with different ASCII character sequences. Another example is that the whitespace outside the tags of an XML element might be handled slightly differently among different XML parsers. From an XML language definition standpoint, these whitespace differences mean nothing and are ignored.


Note - Normally, whitespace outside elements is ignored by XML parsers. The one exception to this rule is for elements that have been declared “mixed.” Such elements can contain content as well as other elements.


As we mentioned, however, any difference between the resulting XML at signature time and the resulting XML that is resolved at validation time will result in the Signature validation failing. Canonicalization is the strategy used to deal with this issue.

Canonicalization normalizes the XML so that, regardless of inconsequential physical differences in the XML, two logically equivalent XML documents will become physically, bit-to-bit equivalent. This is a critical requirement for digital signatures to work.

The following simple scenario illustrates the issue. Say that Bob is creating an XML Signature over the XML structure in Listing 4.13.

Listing 4.13 An XML Structure to be Signed

<GroceryList>
  <GroceryStore>Safeway</GroceryStore>
  <Item Category=”produce”>Lettuce</Item>
  <Item Category=”produce”>Tomato</Item>
  <Item Category=”meat”>Bacon</Item>
</GroceryList>

Now, say that Bob created this XML document on a Windows platform. Hidden within Bob’s hypothetical XML document is whitespace in the form of spaces, tabs, and end-of-line characters. His document actually looks like Listing 4.14 (hidden characters are bold and delimited by + in this example).

Listing 4.14 The GroceryList XML Structure with Embedded Whitespace from Windows

+t+<GroceryList>+c-r++l-f+ +t++t+<GroceryStore>Safeway</GroceryStore>+sp++c-r++l-f+ +t++t+<Item Category=”produce”>Lettuce</Item>+sp++c-r++l-f+ +t++t+<Item Category=”produce”>Tomato</Item>+c-r++l-f+ +t++t+<Item Category=”meat”>Bacon</Item>+c-r++l-f+ +t+</GroceryList>+c-r++l-f+


Note - In this and the following two examples, we had to refer to the hidden characters with abbreviations due to space considerations. Refer to the following legend to understand these abbreviations:

c-r carriage-return

l-f line-feed

sp space

t tab


Now say this document is emailed to Alice, who is running on a Unix platform and needs to validate this document. One difference between the Windows and Unix environments is the extra carriage return put in by Windows. As a convenience to Alice, when she opens her emails, the reader software converts the carriage returns and linefeeds to single linefeeds. So, now the XML document looks like Listing 4.15.

Listing 4.15 The GroceryList XML Structure with Embedded Whitespace from Unix

+t+<GroceryList>+l-f+ +t++t+<GroceryStore>Safeway</GroceryStore>+sp++l-f+ +tb++t+<Item Category=”produce”>Lettuce</Item>+sp++l-f+ +t++t+<Item Category=”produce”>Tomato</Item>+l-f+ +t++t+<Item Category=”meat”>Bacon</Item>+l-f+ +t+</GroceryList>+l-f+

Are these two XML documents different? Not semantically. But, from a classic digital signature perspective, any change to the underlying bits would break the signature. If Bob had digitally signed this XML using a traditional digital signing approach, the digital signature validation would fail verification (although the email reader could get around this problem by validating the signature before doing any convenience manipulation of the document). It is clear, however, that logically these two XML documents are identical, and they should compare equally. This is where canonicalization comes into play. There needs to be a common way to format XML regardless of platform so that, no matter what underlying physical changes have occurred, two semantically identical XML documents will be considered physically identical. This is not limited to physical changes, but also to certain syntactic changes where XML gives you options that do not change the underlying logical equivalence. We come back to this topic soon because this is the place where some of the difficulties of canonicalization lie.

Let’s return to our simple Bob and Alice scenario with the concept of canonicalization. This time, before signing the XML document, Bob (or more accurately, the tool that he is using to create the XML Signature) canonicalizes the XML. Here are some simple rules for canonicalization for this example (note that these are not the canonicalization rules for XML Signature, just some simple rules for this example):

  • Change carriage returns/linefeeds into single carriage returns.

  • Strip any whitespace (tabs or spaces) that appears outside tags.

Applying these rules to the preceding XML document creates the structure in Listing 4.16.

Listing 4.16 The GroceryList XML Structure After Canonicalization

<GroceryList>+l-f+
<GroceryStore>Safeway</GroceryStore>+l-f+
<Item Category=”produce”>Lettuce</Item>+l-f+
<Item Category=”produce”>Tomato</Item>+l-f+
<Item Category=”meat”>Bacon</Item>+l-f+
</GroceryList>+l-f+

These examples might not be pretty to look at, but canonicalization is not for human consumption; it is to feed directly into the Digest algorithm. This canonicalized output is not stored anywhere. It is not in the Signature element, and the XML information being referenced is not changed.

The purpose of the CanonicalizationMethod element in the SignedInfo block is to provide the name of the canonicalization algorithm that Bob employed when digitally signing the XML. Alice’s XML Signature processing engine will read the CanonicalizationMethod and apply the same canonicalization algorithm on the XML that might have been subtly changed by her operating system. Consequently, due to the canonicalization, the same XML will result, and the signature will be verified correctly.

The CanonicalizationMethod algorithm attribute is applied to the SignedInfo element. It is also a type of Transform that can be used as a Transform element with References that we will talk more about later.

The initial XML specification contains only one required canonicalization algorithm (http://www.w3.org/TR/2001/REC-xml-c14n-20010315). This version ignores comments, so, for example, you could put XML comments into a SignedInfo section and they would be ignored in the signature. There is also a recommended canonicalization algorithm that includes comments (http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments).

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=Canonicalization Actions from Canonical XML Version 1.0}

Following is a list of the changes that occur to an XML document when it goes through a Canonical XML version 1.0 Transform (you can find the XML Canonicalization specification at http://www.w3.org/TR/2001/REC-xml-c14n-20010315):

  • The document is encoded in UTF-8.

  • Line breaks are normalized to #xA on input, before parsing.

  • Attribute values are normalized, as if by a validating processor.

  • Character and parsed entity references are replaced.

  • CDATA sections are replaced with their character content.

  • The XML declaration and Document Type Definition (DTD) are removed.

  • Empty elements are converted to start-end tag pairs.

  • Whitespace outside the document element and within start and end tags is normalized.

  • All whitespace in character content is retained (excluding characters removed during linefeed normalization).

  • Attribute value delimiters are set to quotation marks (double quotes).

  • Special characters in attribute values and character content are replaced by character references.

  • Superfluous namespace declarations are removed from each element.

  • Default attributes are added to each element.

  • Lexicographic order is imposed on the namespace declarations and attributes of each element.

Canonicalization Subtleties: Exclusive Canonicalization

Although the concept of standardizing the XML before digesting and before verifying is reasonably simple, complex subtleties arise in some specific situations. One of the subtleties became a significant issue as practical implementations of XML Signing were in the early stages of creation. It came up when applying XML Signing to fragments of XML within a larger XML document—which is the predominant scenario in Web services using SOAP. The issue was primarily related to namespaces. The XML Canonicalization 1.0 specification says that namespaces are to be propagated down to all its descendents. This makes sense because, in the context of the document, these namespaces are implicit, so making them explicit seems like a reasonable strategy. However, when you remove an XML fragment from the context of a document, as in the case of SOAP when you have an XML payload within the overall document, this can cause significant problems.

This issue resulted in the creation of a new canonicalization algorithm called Exclusive Canonicalization (http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/). This canonicalization method strives to “exclude ancestor context” as much as is practical. It primarily does this by not propagating the ancestor namespaces down to the children nodes. This canonicalization approach turns out to be the most practical in most circumstances and the one that you should use.

The extensibility of the canonicalization method is a tribute to the XML Signature working group and is what made the advent of the Exclusive Canonicalization method possible. Custom canonicalization methods are also possible; however, you should be extremely careful about using one because the canonicalization algorithm modifies the XML to be signed and verified in a way that is difficult to see. It would not be difficult for a canonicalization algorithm to do something such as modify the XML to have all signatures verified correctly.

To summarize, canonicalization is an important concept that is straightforward but can quickly become complex. (Just search canonicalization on the Net, and you will see what we mean.) Most of the time in Web Services Security, you can use Exclusive Canonicalization and you will be fine. We describe canonicalization further when we discuss the Transform element because, as we mentioned earlier, the CanonicalizationMethod designates which Canonicalization Transform to use over the SignedInfo element.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=The SignatureMethod Element}

SignatureMethod names the algorithm that will be used for signing and verifying signatures. Two signature algorithms are required: DSAwithSHA1, which is an implementation of the Digital Signature Algorithm (DSA), and HMAC-SHA1. DSAwithSHA1 is a public key strategy (sign with a private key, decrypt with a public key), and HMAC-SHA1 is a shared key hashed message authentication code strategy. This is a little unusual. Digital signatures are typically meant to validate integrity (that the document has not changed) and identity (that a particular individual, device, or process signed the document). Validation of identity is associated with public key cryptography (for example, DSA or RSA), not shared key cryptography. A shared key approach is typically not associated with digital signatures; however, the XML working group wanted to allow for a situation in which the primary purpose for the signature was integrity, and HMAC-SHA1 is an excellent (and fast) way to accomplish this goal.

In addition to the DSA algorithm, RSAwithSHA1 is recommended (but not required). Remember that the DSA algorithm and, consequently, DSA keys can be used only for digital signatures. The RSA public key algorithms can be used for both digital signatures and encryption and are more commonly used than DSA. Most, if not all, XML Signature implementations support RSAwithSHA1.

The following is an example of a SignatureMethod element:

<SignatureMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#dsa-sha1″ />

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=The Reference Element}

While SignedInfo can be considered the meat of an XML Signature, in turn the Reference element can be considered the meat of SignedInfo.


Tip - When you are reading an XML Signature, which can often be remarkably long, the first place you usually look to get a feel for what is being signed is the Reference element(s). The URI attribute points to what is being signed.


As review, Listing 4.17 is the Reference XML fragment pulled from the Signature shorthand schema shown earlier.

Listing 4.17 XML Shorthand Schema for the <Reference> Element.

 (<Reference URI? >
  (<Transforms>)?
 <DigestMethod>
 <DigestValue>
 </Reference>)+

The objective of the Reference element is to point to a resource to be included in the overall XML Signature. There must be at least one Reference, which stands to reason because you have to be signing something. To say that this element points to the resource is actually oversimplifying because it also can contain Transform elements that manipulate the resource that is being pointed to prior to its being digested. Arguably, most of the power and complexity of XML Signatures come from the Reference element. That power comes from the power of the uniform resource identifier.

See the sidebar titled “The Powerful, Enigmatic, and Confusing Uniform Resource Indentifier (URI)” in Chapter 2 for more information about what a URI is and how to use it. In XML Signature, URIs can show up in a variety of ways; see the sidebar here titled “URI/URL Variants in XML Signature” for a review of the different ways a URI can show up as a Reference URI in an XML Signature.


URI/URL Variants in XML Signature - For XML Signature and most of the XML security standards, you need to understand URIs well. The locator aspect of URIs when referring to XML is quite a bit more involved than the equivalent HTML usage. Let’s review the locator type URI options in XML Signature:

  1. Refers to an external XML document. This is straightforward and might look like URI=http://www.mycompany.com/myDocument.xml.

  2. Refers to the current XML document root. It is common, especially with enveloping references to specify the root of the document that contains the Signature element. This looks like URI=””.

  3. Uses the same document reference. If you are referring to an XML element in the same document, you can use a “same document reference,” which looks like URI=”#PurchaseOrder”.

  4. Uses external document “bare fragment.” This is similar to a same document reference, except that it is to a portion of an external XML document. It looks something like URI=”http://www.mycompany.com/myDocument.xml#PurchaseOrder”.

  5. Refers to a non-XML file (binary, text, and so on). This is similar to any URL you are already familiar with; it looks like URI=”http://www.mycompany.com/myPicture.gif”.

  6. Uses an internal URI with an XPointer argument (this type is recommended but not required, so all toolkits might not support it). It looks like URI=”#xpointer(/)”, which refers to the root element. External URIs with XPointer arguments are not recommended.

Another fact to know about URIs is that they can be absolute or relative. An absolute URI is completely spelled out, including all parts of the URI, such as http://www.mycompany.com/ mySignatureExample. A relative URI contains a resource path and name that is meant to be resolved from the BaseURI. The BaseURI, if not made explicit, is the same directory as your current location. For example the relative URI myPicture.gif would look for myPicture.gif in the same directory where the XML document is located. Using relative URIs can provide the advantage of portability by allowing you to move a set of resources around without having to change references.


SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=The Transform Element}

Transforms receive the results of dereferencing the Reference URI and alter the results in some way. A Transform algorithm can essentially change anything about the original XML document. Multiple Transforms can appear under a Reference working in a pipeline-type fashion, with the results of one Transform algorithm feeding into the next one. This is an extremely powerful capability but fraught with risk. We discuss this topic later, but the problem is probably obvious: After a Transform occurs, there is no way for a signer or validator to view what has been signed without going through the exact same Transforms in the exact same order. That being said, in some situations Transforms are necessary. You just need to be careful when you use them.

Actually, we already described one type of Transform when we discussed canonicalization algorithms. In the XML Signature specification, five Transforms are mentioned:

  • Canonicalization

  • Base-64

  • XPath Filtering

  • Enveloped Signature Transform

  • XSLT Transform


XML Signature Transforms: Nodeset or Octets? - Remember that Transforms work in a pipeline fashion, taking in the input from the Reference URI or another Transform and outputting to either another Transform or to the final digest algorithm. This brings up a new wrinkle: The results of the Reference URI can be either an XML nodeset or octets (a true 8-bit byte). The digest algorithm needs octets. If only a Reference URI is included and no Transforms, the transformation from an XML nodeset to octets occurs automatically.

When Transforms are being used, however, you sometimes need to be aware of whether a particular Transform algorithm requires a nodeset or octets as input and whether the Transform algorithm outputs an XML nodeset or octets. The Reference URI is always the first input, and there is a basic rule as to whether it will result in an XML nodeset or octets. If it is a same document reference, it will result in an XML nodeset; if it is an external reference, even if the external document is XML, it will be octets. The final Transform must always output octets because that result is required for the digest algorithm. Your tool for converting from an XML nodeset to octets is canonicalization.

Don’t sweat this issue too much; most of the conversions are handled for you. Just remember that the digest algorithm needs octets. Therefore, if, after applying one or more Transforms, you end up with an XML nodeset, you may need to add one more Transform, a Canonicalization Transform, to convert the XML nodeset to octets.


Canonicalization Transform

Any canonicalization algorithm that can be used in the CanonicalizationMethod can be used as a Transform. Canonicalization algorithms take XML nodesets as input and output octets.

Base-64 Transform

Base-64 is an algorithm for converting binary data into text, as discussed in Chapter 3. This algorithm maps the binary values to a subset of ASCII values that are human-readable text. See Appendix A for more detailed information on the Base-64 algorithm.

You would use the Base-64 Transform, for example, if the Reference URI were pointing to a GIF image like that in Listing 4.18.

Listing 4.18 A <Reference> URI for a GIF Image Requiring Base-64 Transform

<Reference URI=”myPicture.gif”>
  <Transform
        Algorithm=http://www.w3.org/2000/09/xmldsig#base64 />
  <DigestAlgorithm … />
  <DigestValue … />
</Reference>

The Base-64 Transform takes in octets and outputs octets.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=XPath Filtering Transform}

The XPath Filtering Transform allows you take advantage of the powerful XPath language2. See Chapter 2 for more information on XPath.

In addition to the Algorithm attribute, the XPath Filtering Transform adds a child called XPath to the Transform element. This is the place you put the XPath expression that will pull out the piece you want from the XML nodeset that was returned by the Reference URI or the previous Transform. An example of this is shown in Listing 4.19.

Listing 4.19 The <Transform> Element Using Xpath Transform

<Transform Algorithm=”http://www.w3.org/TR/1999/REC-xpath-19991116″>
    <XPath xmlns:dsig=”&dsig;”>
     not(ancestor-or-self::dsig:Signature)
   </XPath>
</Transform>

You commonly use the XPath Filtering Transform in XML Signatures when you want to sign just a fragment of an XML document. For example, it is not uncommon to want to create a Signature element that is a peer with the element you want to sign. Consider the following document shown in Listing 4.20:

Listing 4.20 An <Order> XML Structure Where <Signature> Needs to be a Peer With <UserAgreement>

<Order>
  <CustomerInformation>
    <Name>David Remy</Name>
    <Address>123 Somewhere Street</Address>
    <City>West Linn</City>
    <State>OR</State>
    <Country>US</Country>
  </CustomerInformation>
  <LineItems>
    <LineItem Sku=”1235″>Lime green Umbrella</LineItem>
  </LineItems>
  <UserAgreement>
    I agree to be spammed, pay early and extra,
    and enjoy your popup adds.
  </UserAgreement>
  <Signature>– Signature of UserAgreement here –</Signature>
</Order>

The requirement here is to create an XML Signature that is a peer (at the same level in the XML tree) of UserAgreement. You can accomplish this by using an XPath Filtering Transform like that used in Listing 4.21.

Listing 4.21 Use of Xpath Filtering to Create an XML Signature at the Peer Level

<Signature>
  <SignedInfo>
    <Reference URI=””>
     <Transforms>
      <Transform
       Algorithm=”
http://www.w3.org/TR/1999/REC-xpath-
      19991116″>
       <XPath>
       ancestor-or-self:UserAgreement[parent:Order]
       </XPath>

      </Transform>
     </Transforms>
    …
   </Reference>
  </SignedInfo>
</Signature>

As you can see, the Reference element specifies the current document (URI=””), and the Transform element has XPath (http://www.w3.org/TR/1999/REC-xpath-19991116) as its algorithm and a child XPath element. This element contains the XPath expression ancestor-or-self:UserAgreement[parent:Order], which is a simple way of asking for the UserAgreement element and all its siblings. This particular XPath expression is somewhat brittle because it assumes the UserAgreement element is always a child of Order. XPath would allow a more elaborate expression to pick up a UserAgreement at any level in the document.

The XPath Filtering Transform takes in and outputs an XML nodeset.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=Enveloped Signature Transform}

The Enveloped Signature Transform is commonly used in XML Signature when the parent element is to be signed. The problem is that the Signature element would be within the information to be signed, so it must be removed before doing the validation. You actually can remove the Signature element by using the XPath Filter Transform described previously, so this Transform is primarily provided for convenience.


Note - The Enveloped Signature Transform is the only Transform (other than the canonicalization Transforms defined by CanonicalizationMethod) required by the XML Specification. The XPath Filter Transform is recommended, but it is not required. You will find in practice that most, if not all, current XML Signature toolkits support the XPath Filter Transform.


Using the Enveloped Signature Transform is the same as using the XPath Filter Transform with the following expression in Listing 4.22:

Listing 4.22 The XPath Expression Equivalent to the Enveloped Signature Transform

<XPath>
  count(ancestor-or-self::dsig:Signature |
  here()/ancestor::dsig:Signature[1]) >
  count(ancestor-or-self::dsig:Signature)
</XPath>

This XPath expression can a bit difficult to deal with, so having this Transform is convenient. If you are signing a parent element, you should use it. For example, say you want to sign the Order XML document in Listing 4.23 and want the Signature to be the last element within the Order:

Listing 4.23 An <Order> Element Where <Signature> Needs to be the Last Element

<Order>
  <LineItems>
    <LineItem sku=”00001″>Soap on a Rope</LineItem>
    <LineItem sku=”00002″>Cinnamon Shampoo</LineItem>
  </LineItems>
  <Signature> … </Signature>
</Order>

To accomplish this, you must use the Enveloped Signature Transform (or XPath Filtering Transform). The Signature element would then look something like Listing 4.24.

Listing 4.24 The <Signature> Element After the Enveloped Signature Transform

<Signature>
 <SignedInfo>
  <CanonicalizationMethod … />
  <SignatureMethod … />
  <Reference URI=””>
   <Transforms>
    <Transform
     Algorithm=”http://www.w3.org/2000/09/xmldsig#enveloped-signature”/>
   </Transforms>

   <DigestMethod … />
   <DigestValue>…</DigestValue>
  </Reference>
 </SignedInfo>
 <SignatureValue>…</SignatureValue>
</Signature>

In this example, the Reference URI points to the document itself (URI=””), and the Transform algorithm is the Enveloped Signature Transform. If the target of the Signature is not the root of the document, you could use the “same document reference” type for the URI (for example, URI=”#someElementID”) or an XPath Filtering Transform just prior to the Enveloped Signature Transform to reduce the resulting XML fragment to just the nodes you plan to sign.

Similar to the XPath Filtering Transform, the Enveloped Signature Transform takes in and outputs an XML nodeset. The only difference is that an Enveloped Signature Transform must be applied to a nodeset from within its parent document.

XSLT Transform

It is good practice to sign what the signer (a human being) actually sees, especially when the meaning of the signature represents the signer’s intent. The visual aspects—even seemingly insignificant aspects such as a word being bold—can influence the meaning of a document. If an XML Stylesheet (XSL) is used, you have two choices for how to digitally sign it. One option is to have two Reference URIs: one pointing to the base XML document and the other to the XSL. Another is to use the XSLT Transform. The XSLT Transform simply applies the specific XSL expressions that are included under the Stylesheet element. To refer to an external stylesheet, you can use the xsl:include or xsl:import XSL expressions.


Note - The XSLT Transform requires octets as input, and the output is an octet stream. Also, because different XSLT processors do not necessarily return consistent results, it is a good idea to use a Canonicalization Transform after an XSLT Transform.


SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=XPath Filter 2.0 Transform}

The XPath Filter 1.0 Transform described in the preceding section allows for any type of XPath expression to be used. The underlying usage for XPath Filter 1.0 is often either to explicitly include some fragment of a document to be signed or to explicitly exclude some part of the document that could legitimately change without breaking the signature of the document. For example, say you want to have two signatures that are not co-signatures (one signature does not include the other). To do this, you would use an XPath statement to exclude the other signatures (and the Enveloped Signature Transform to exclude the current signature). These are “set” type functions that often require fairly complex XPath statements to accomplish. The XPath Filter 2.0 Transform adds the capability to shortcut these common types of XPath statements by specifying intersection, union, and subtraction. For example, to remove another signature, you would use the following XPath 2.0 filter:

<XPath Filter=”subtract” xmlns=”http://www.w3.org/2002/06/xmldsig-filter2″> id(“TheOtherSignature”)
</XPath>

On the other hand, if the goal is to sign the other signature, such as when a counter-signature is desired, you might use the following:

<XPath Filter=”intersect” xmlns=”http://www.w3.org/2002/06/xmldsig-filter2″> id(“TheOtherSignature”)
</XPath>

Using these intersect, subtract, and union set operations can be cleaner than using the equivalent XPath statements, and it is also possible for the Signature processor to work more efficiently. You can find an excellent example of the XPath Filter 2.0 Transform using the three set operators at the following location:

http://www.w3.org/TR/xmldsig-filter2/#sec-Examples

The Reference URI when using the XPath Filter 2.0 Transform must be an XML document. Often, it is the current document URI (URI=”” without comments or URI=”#xpointer[/]“ with comments). This Transform takes in and returns an XML nodeset.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=The DigestMethod Element}

The DigestMethod element represents an identifier for the algorithm used to calculate the digest of the Reference URI plus all the Transforms.


Note - The digest algorithm itself must receive its information in the form of octets. Typically, if a conversion is needed from an XML nodeset to octets, it is handled automatically. However, in some cases, an additional Transform may be required to ensure that the input to the digest algorithm is in the form of octets or to ensure that the XML nodeset is canonicalized so that it has the highest likelihood of valid comparison on any platform.


The only required digest algorithm is SHA1, and it is designated by

Algorithm=http://www.w3.org/2000/09/xmldsig#sha1

The DigestValue Element

The DigestValue element contains the Base-64 encoded value of the digest. The following DigestValue element is taken from the example we gave near the beginning of the chapter:

<DigestValue>60NvZvtdTB+7UnlLp/H24p7h4bs=</DigestValue>

The SignatureValue Element

At this point, the SignatureValue element must seem anti-climactic even though it represents the signature itself. The SignatureValue element is the Base-64 encoded resulting value of encrypting a digest of the SignedInfo element. The particular signature method used is defined within the SignatureMethod element itself (for example, RSA-SHA1). Here is an example of a SignatureValue:

<SignatureValue> hTHQJyd3C6ww/OJz07P4bMOgjqBdznSUOsCh6P+0MpF69w2tln/PFLdx/EP4/VKX </SignatureValue>

So far, we have reviewed the core aspects of the XML Signature, SignedInfo, and SignatureValue elements. If you understand them well, you have a good basis for understanding and using XML Signatures. The next two elements, Object and KeyInfo, are optional, but in many circumstances, necessary and important elements.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=The Object Element}

We have not talked much about the Object element, but when we described Enveloping Signatures, we were discussing a function that the Object element facilitates. In the case of an Enveloping Signature, the Reference URI points to an element within the Object element. We further describe this use of the Object element later in the chapter.

The Object element is essentially an element in which you put miscellaneous items other than SignedInfo, SignatureValue, and KeyInfo. It is defined in a way that you can put anything you want into it; however, typically one of three things is included within an Object element:

  • Something you want signed, such as an XML fragment or perhaps a Base-64 encoded binary object. This is to implement the Enveloping Signature concept mentioned previously.

  • A Manifest element (described later).

  • A SignatureProperties element (described later).


Tip - Remember that none of these items are inherently signed and therefore secured by the XML Signature. For these elements to be signed, they must be referred to by one of the Reference URIs in the SignedInfo section of the signature.


Listing 4.25 uses an Object element in the Enveloping Signature scenario.

Listing 4.25 An <Object> Element Used in the Enveloping Signature Scenario

<Signature>
  <SignedInfo>
  …
  <Reference
URI=”#MyOrder”
    Type=”
http://www.w3.org/2000/09/xmldsig#Object“>
    <DigestMethod
        Algorithm=”http://www.w3.org/2000/09/xmldsig#sha1″/>
    <DigestValue>…</DigestValue>
  </Reference>
 </SignedInfo>
 …
 <Object id=”MyOrder”>
    <Order>
      <LineItem sku=”12348″>Web Service Security Book</LineItem>
      <LineItem sku=”2345″>Life as a Geek Book</LineItem>
    <Order>
 </Object>
</Signature>


Note - In this example, the Object start and end tags would be included in the digest calculation for the Reference. If you do not want the Object tags to be included in the digest calculation, either

  • The Reference URI should point to the element below the Object tag that is to be signed.

    or

  • An XPath statement should exclude the Object tag.


    First, notice that the Reference URI points to an ID (MyOrder) of an Object element. Also, notice that a Type parameter is included in the Reference to provide information about what the Reference is pointing to. We deferred mentioning this point when describing the Reference element.

    The following three Type attributes are mentioned in the XML Signature specification; they all relate to items that can be contained within an Object element or the Object element itself:

    • Object (Type=”http://www.w3.org/2000/09/xmldsig#Object”)—The reference is to an Object element.

    • Manifest (Type=”http://www.w3.org/2000/09/xmldsig#Manifest”)—The reference is to a Manifest element (see the Manifest Element section next in this chapter for more information on the Manifest element).

    • SignatureProperties (Type=”http://www.w3.org/2000/09/ xmldsig#SignatureProperties”)—The reference is to a SignatureProperties element (see the Signature Properties section later in this chapter for more information on SignatureProperties).

    The Object element, when used in an Enveloped Signature scenario like this, can also have attributes for MimeType and Encoding. For example, if the enveloped item is a GIF image, your Object tag might look like this:

    <Object id=”MyGif” MimeType=”image/gif” Encoding=”base64″>
    … a string of base64 characters …
    </Object>

    You can have as many Object elements as you want. You typically create a single Object tag for each use. So, for example, if you have a signed Object and you have SignatureProperties (which is always within an Object), you have two Object elements.

    Now let’s discuss the two optional children of the Object tag: Manifest and SignatureProperties.

    SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

    Buy this book now.

    {mospagebreak title=The Manifest Element}

    In terms of ocean shipping, a manifest is the list of things that the ship has onboard. In that sense, all the References within SignedInfo are a type of manifest because they list what is included in the XML Signature. Similar to SignedInfo, the Manifest element contains a list of Reference elements (exactly like the Reference elements that are children of SignedInfo). The only difference is that the References referred to in SignedInfo must be validated for the signature to be considered valid. The meaning of a Manifest Reference not validating is left up to you, as the application developer. In other words, you typically have the opportunity to be notified if a problem occurs with validation of the Manifest Reference elements; therefore, you can determine how best to handle the situation.

    You might find at least two major uses for the Manifest element:

    • You may want to have more granular control over which References matter and which do not (contextually). For example, you might want it to be okay if two out of three References are valid. You would not be able to accomplish this with SignedInfo alone.

    • For performance reasons, when doing multiple signatures over the same information, you could refer to a Manifest element. The Manifest element would be computed only once, and the References from multiple signatures could point to the one Manifest. This approach could be valuable when multiple signers are signing a contract.

    Use of the Manifest element is similar to the Object example described earlier, except that the Manifest element exists at one level below Object, as shown in Listing 4.26.

    Listing 4.26 Use of the <Manifest> Element

    <Reference URI=”#MyManifest”
    Type=”http://www.w3.org/2000/09/xmldsig#Manifest“>
        <DigestMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#sha1″/>
        <DigestValue>. . .</DigestValue>
     </Reference>
     …
     <Object>
        <Manifest Id=”MyManifest”>
          <Reference>
            …
          </Reference>
          <Reference>
            …
          </Reference>
        </Manifest>
     </Object>

    As we mentioned previously, the Reference elements in Manifest are exactly like the Reference elements in SignedInfo, except that it is up to you to decide what to do if the validation on the DigestValue fails.

    The SignatureProperties Element

    The SignatureProperties element provides a place to put name value information about the signature itself. For example, you often need to know the time of the signature. This is a classic candidate for a signature property. Listing 4.27 shows this type of usage (it is a slightly edited version from an example in the XML Signature specification).

    Listing 4.27 Use of the <SignatureProperties> Element

    <Signature id=”MySignature”>
      <SignedInfo>
        …
        <Reference URI=”#AMadeUpTimeStamp”
       Type=”http://www.w3.org/2000/09/xmldsig#SignatureProperties”
    >
          <DigestMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#sha1″/>
          <DigestValue>. . .</DigestValue>
        </Reference>
      </SignedInfo>
      …
      <Object>
        <SignatureProperties>
          <SignatureProperty Id=”AMadeUpTimeStamp” Target=”#MySignature”>
            <timestamp xmlns=”http://www.ietf.org/rfcXXXX.txt”>
              <date>19990908</date>
              <time>14:34:34:34</time>
            </timestamp>
          </SignatureProperty>
        </SignatureProperties>
      </Object>
    </Signature>

    Notice that the Reference element points to a specific SignatureProperty within SignatureProperties and specifies a SignatureProperties Type. Also, notice that the Target points back to the Signature that this property is associated with.

    That wraps up our discussion of the Object element. It is kind of a quirky element but important in many circumstances.

    SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

    Buy this book now.

    {mospagebreak title=The KeyInfo Element}

    The KeyInfo element is perhaps the thorniest element in the XML Signature specification. Its purpose is to give you the key needed to validate the signature or give you information to allow you to look up the key. XML Signature goes out of its way to define a flexible structure for KeyInfo such that

    • It can be omitted completely.

    • It can provide the key in a raw form right in the XML.

    • It can provide the key within a digital certificate.

    • It can give you a variety of types of keys to support different cryptography standards.

    • It can simply provide a name for you to use to look up the key.

    As it always seems when discussing PKI and security, things become more difficult as we move closer to the issues of key management and trust.

    Because the KeyInfo element allows such a wide variety of options for providing information about the key needed to validate the signature, it consists mostly of optional elements. Listing 4.28 is a shorthand schema for KeyInfo.

    Listing 4.28 The Shorthand XML Schema for <KeyInfo>

     (<KeyInfo (id=)?>
      (<KeyName>)?
      (<KeyValue>)?
      (<RetrievalMethod>)?
      (<X509Data>)?
      (<PGPData>)?
      (<SPKIData>)?
      (<MgmtData>)?
    <KeyInfo>)?

    As you can see, everything is optional. This is a clue about the unwieldy nature of this element. Obviously, the XML Signature working group wanted to support as many possible key standards as it could; however, most of the time, you will encounter one of these three scenarios:

    • You will receive an X.509 certificate within the X509Data element. X.509 certificates, issued by a certificate authority, either private or public (such as VeriSign or GeoTrust), are the predominant container for public keys.

    • You will receive one of the X509Data elements that uniquely identify an X.509 certificate in a directory. We discuss these elements briefly later in this section, but examples include X509IssuerSerial and SerialNumber, which together can uniquely identify a certificate. In this case, you use this information to look into a directory to locate the X.509 certificate yourself.

    • You will receive no KeyInfo. In this case, it is expected that you know what the validation key (either public or secret key) should be. For example, if you are in a protocol situation, exchanging multiple messages in a sequence, you may already have knowledge of the key.

    As we mentioned earlier, X.509 certificates are the predominant standard for containing public key certificates. Practically every type of security application contains support for them, including Web browsers, Web servers, VPNs, email, and so on. X.509 certificates are ASN.1 structures (see the sidebar “XML Versus ASN.1 Paradigm Shift: A Battle to the Death?” in Chapter 2), and there is a common thread across XML security standards to not force applications to have both ASN.1 and XML parsers. However, X.509 certificates (either directly included or specified via some identifier approach) have two distinct advantages over other methods of providing keys:

    • Most applications, tools, libraries, and environments support X.509 processing.

    • X.509 certificates are digitally signed by a certificate authority in a standard way that leads to trust decisions. We discuss trust issues in depth in Chapter 9, but suffice it to say here that “trusting” that the key really represents the identity you think it does is fundamental to digital signatures. X.509 certificates fit into a relatively mature (although at times overly complex) strategy for establishing that a key is legitimate.

    In certain circumstances, you might receive something other than an X.509 certificate or pointer to an X.509 certificate. These situations are most likely to occur when you are working within a known trust domain. In this case, the raw public key may even be provided directly in the KeyInfo structure.

    KeyInfo is discussed again in later chapters about XML Encryption (which also uses KeyInfo and adds a few elements) and XKMS. XKMS allows you to pass a KeyInfo element to a “trust engine” to determine whether, based on your own trust policies, you can trust the key located through this KeyInfo.

    Now let’s examine the possible KeyInfo sub-elements.

    KeyName

    The KeyName element is simply a name to identify the key. It could be some string agreed upon in advance, or it could represent a unique value used to look up the key in a directory. For example, KeyName could contain an email address or a Distinguished Name (DN) for a digital certificate.

    KeyValue

    The KeyValue element is the actual key itself embedded in the XML. The format of this element varies based on the type of key. The two types of keys mentioned in the XML specification are DSA and RSA. Each of these has its own elements as children of KeyValue, DSAKeyValue, and RSAKeyValue.

    RetrievalMethod

    The RetrievalMethod element is used to reference a key that is stored at a separate location. It contains a URI (like the Reference URI) pointing to the key with an optional Type for the type of key information being retrieved. Most of the major KeyInfo elements can be targeted by RetrievalMethod. The valid Type values for remote KeyInfo structures are as follows:

    http://www.w3.org/2000/09/xmldsig#DSAKeyValue http://www.w3.org/2000/09/xmldsig#RSAKeyValue http://www.w3.org/2000/09/xmldsig#X509Data http://www.w3.org/2000/09/xmldsig#PGPData http://www.w3.org/2000/09/xmldsig#SPKIData http://www.w3.org/2000/09/xmldsig#MgmtData

    In addition to these, there is a Type value for a binary X.509 certificate:

    http://www.w3.org/2000/09/xmldsig#rawX509Certificate

    One use of the RetrievalMethod element is to save space in the XML document because KeyInfo values such as X.509 certificates can be large. If multiple signatures use the same key or perhaps part of a certificate chain, you can store the KeyInfo structure in a standalone element in the document with a unique ID attribute and then refer to it using the same document reference in each Signature element’s KeyInfo RetrievalMethod URI attributes.

    X509Data

    The X509Data element is a commonly used KeyInfo element. The objective of the X509Data element is to provide either an identifier to look up an X.509 certificate or the X.509 certificate itself.

    A certificate chain can also be contained in X509Data. The idea is that there would be a set, or chain, of related certificates under X509Data. A certificate chain typically means all the certificates necessary to get to a root certificate. See Chapter 3 for more information about certificate chains and root certificates.

    PGPData

    The PGPData element is similar to the X509Data element; it can either point you to a PGP key or contain actual key material. It is unlikely that you will use this element for XML Signatures, although it is possible and the specification allows for it. The child element PGPKeyID is a unique ID of the key, and PGPKeyPacket is a structure that can contain a PGP public and/or private key. PGPKeyID and PGPKeyPacket are defined in the OpenPGP standard(3). The PGPData and SPKIData elements are written flexibly, so elements in a different namespace can add to these elements, or if a PGP XML standard is written, it could replace the PGPData element.

    SPKIData

    The Simple Public Key Infrastructure (SPKI) was an effort to improve and simplify PKI. It does not have much momentum right now, due to slow commercial acceptance, so you are unlikely to need to use it. The structure of SPKIData is similar to PGPData in the sense that it contains sub-elements to help locate or contain the public key, and it can be extended and replaced by external namespace elements when and if they are defined.

    We’ve now concluded our discussion of KeyInfo and the rest of the XML Signature elements. We will now discuss strategies for actual usage of XML Signature.

    SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

    Buy this book now.

    {mospagebreak title=Security Strategies for XML Signature}

    XML Signature, just like any security strategy, is effective only if it is used correctly within the context and constraints of the situation. It is effective in certain areas but can be inappropriate in others. The following sections describe some security considerations when you are using XML Signatures.

    Using Transforms

    Perhaps the scariest aspect of XML Signatures, at least when you come from a traditional digital signature perspective, is the concept that you can change (transform) the information being signed in a hidden way (by an algorithmic process) before it is digitally signed. This capability seems to go against the assumptions about fundamental integrity on which digital signatures are based. However, as we discussed earlier when talking about Transforms, there are completely legitimate reasons for using a Transform algorithm, such as when you need to Base-64 encode a binary object or remove a signature when creating/validating an Enveloped Signature. The XML Signature working group was concerned enough about the security issues around Transforms to call out three specific principles to consider when using Transforms in XML Signatures.

    Only What Is Signed Is Secure

    The principle “only what is signed is secure” seems obvious, but the point is that when a Transform is involved, you must be extra diligent to understand what the Transform does and to understand that the discarded information is not digitally signed. For example, in a Web services scenario, if an XML Signature has signed the XML payload, only the XML payload is secured, not the SOAP envelope information.

    Only What Is Seen Should Be Signed

    If a user’s judgment or consent is being conveyed by the signature, every practical effort should be made to sign what a user has seen. For example, if a contract being signed (showing intent) has been rendered to the signer as XML with an XSL stylesheet, both the XML and the XSL stylesheet should be signed. In general, implementers should adhere to the principle of What You See Is What You Sign (WYSIWYS).

    “See” What Is Signed

    The idea behind the principle “see what is signed” is that you should make sure you are working with (seeing) what was actually signed. Making presumptions about the signature is risky. You should run the actual Reference URI and Transforms and work with the output to be sure. For example, you may know that a signature is supposed to contain a certain field, such as an amount. If Transforms are involved (and they always are when you consider canonicalization of the SignedInfo element), you cannot be positive that that field’s integrity has been validated unless you run the Reference URI/Transform algorithms and then access the field’s contents from the result.

    Knowing the Security Model

    In the context of our discussion, the term security model means the set of assumptions and constraints associated with a particular security or cryptographic strategy. For example, XML Signature supports both public key signatures and keyed hashed authentication codes (such as HMAC).

    We discussed the security model around public key signatures in Chapter 3. The main point here to remember is that public key signatures are associated with identity and integrity.

    Keyed hashed authentication codes, such as HMAC, are shared key based. They tend to run much faster than public key signatures, but they are primarily associated with integrity, not identity.

    XML Signatures can and will be extended over time to include other types of algorithms and techniques. If you choose one of these approaches, it is critical that you understand the underlying security model well.

    Knowing Your Keys

    Key management is a fundamental issue of cryptography whether it is public key or shared key oriented. It is critical (and challenging) that you protect the private keys that are used for signing and confirm that the keys you are using for validation are valid, not revoked, and represent the identity that you expect them to represent.

    Signing Object Elements

    XML Signature processing does not automatically sign Object elements within a Signature element. If you want an element signed, you must create a Reference and point specifically to the Object element. This point is obvious when you are creating an Enveloping Signature, but it may seem less obvious when you are adding a SignatureProperties or Manifest element. Most of the time, you will want these elements signed. For example, if you add a “Time of Signature” property to a SignedProperties element, you usually want to add a Reference to it; otherwise, why would you provide this information to the verifier and potentially have it tampered with?

    Signing DTDs with Entity References

    One of the key capabilities of DTDs is keeping entity references that are resolved for you at XML parse time. For example, say you have a DTD that contains the following entity references:

    <!ENTITY companyname “CompanyA”>
    <!ENTITY companylocation “Chicago, IL”>

    Then you receive a signed XML document representing an order commitment for $1,000,000 that was signed by Company A like Listing 4.29.

    Listing 4.29 An <OrderCommittment> Document Signed by Company A

    <?xml version=”1.0″?>
    <!DOCTYPE ordercommittment SYSTEM “ordercommittment.dtd”>
    <OrderCommittment>
      <CompanyName>&companyname;</CompanyName>
      <CompanyLocation>&companylocation;</CompanyLocation>
      <CommittedItem type=”cash” denom=”USD”>$1,000,000</CommittedItem>
      <CommittedDate>ASAP</CommittedDate>
      <Signature>
        <SignedInfo>
          <CanonicalizationMethod … />
          <SignatureMethod … />
          <Reference URI=””>
            <Transforms>
             <Transform
              Algorithm=”http://www.w3.org/2000/09/
              xmldsig#enveloped-signature”/>
            </Transforms>
          <DigestMethod … />
          <DigestValue>…</DigestValue>
         </Reference>
      </SignedInfo>
        <SignatureValue>…</SignatureValue>
      </Signature>
    </OrderCommittment>

    Notice that the signature is an Enveloped Signature that signs everything under the OrderCommittment element. Because the Reference URI is “”, the entire document includes the <?xml and <!DOCTYPE lines; however, the DTD itself has not been signed. Notice that the DTD has a relative address. So, imagine that an attacker—say, from Company B—substituted a different DTD file into the same directory as the XML containing the following entity references:

    <!ENTITY companyname “CompanyB”>
    <!ENTITY companylocation “Pendleton, NJ”>

    In this case, the signature is validated even though different values appear in the CompanyName and CompanyLocation elements of the XML document! And Company B will receive the $1,000,000 because of it. The point is: Signing DTDs is very important when entity references are being used.

    Entity references are not a problem with XML Schemas because schemas do not have the same entity reference capability; however, a similar problem can occur with default values. It is a good idea to include a Reference to the XML Schema for the same reasons you would sign DTDs.


    SOAP Security Extensions: An Initial Stab at Web Services Security - In February 2001, Microsoft and IBM submitted a W3C Note regarding the use digital signatures in SOAP messages (see http://www.w3.org/TR/SOAP-dsig/). This precursor to WS-Security defines a standard way to put an XML Signature into the header of a SOAP message. For example, a signed SOAP message would look like Listing 4.30 using this method.

    Listing 4.30 Early Use of Digital Signatures in SOAP

    <SOAP-ENV:Envelope
     xmlns:SOAP-ENV=”…”>
     <SOAP-ENV:Header>
      <SOAP-SEC:Signature xmlns:SOAP-SEC=”…”
       SOAP-ENV:actor=”some-URI”
       SOAP-ENV:mustUnderstand=”1″>
       <ds:Signature xmlns:ds=”…”>
        <ds:SignedInfo>
         <ds:CanonicalizationMethod
          Algorithm=”…”>
         </ds:CanonicalizationMethod>
         <ds:SignatureMethod Algorithm=”…”/>
         <ds:Reference URI=”#Body”>
          <ds:Transforms>
           <ds:Transform Algorithm=”…”/>
          </ds:Transforms>
          <ds:DigestMethod Algorithm=”…”/>
            <ds:DigestValue>…=</ds:DigestValue>
         </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>…</ds:SignatureValue>
       </ds:Signature>
      </SOAP-SEC:Signature>
     </SOAP-ENV:Header>
     <SOAP-ENV:Body
      xmlns:SOAP-SEC=”…” SOAP-SEC:id=”Body”>
      <m:GetLastTradePrice xmlns:m=”some-URI”>
       <m:symbol>IBM</m:symbol>
      </m:GetLastTradePrice>
     </SOAP-ENV:Body>
    </SOAP-ENV:Envelope>

    You will not see this standard in much use today; it never went past the W3C Note stage. However, it is used in some situations, and it had a significant influence on the later WS-Security standard.


    SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

    Buy this book now.

    {mospagebreak title=Summary}

    XML Signature is the latest and greatest technology for you to use to ensure integrity and non-repudiation (to the extent possible). Its remarkable flexibility allows you to sign parts or all of XML documents as well as binary and remote objects.

    Despite the depth and size of this chapter, the medium-level concepts behind XML Signature and the way it works are not difficult to understand. An XML Signature is represented by a Signature element. The core elements of an XML Signature are the SignedInfo and SignatureValue elements. The SignedInfo element contains the CanonicalizationMethod, the SignatureMethod, and one or more Reference elements. The Reference elements contain URIs (pointers) to resources to be signed, zero or more Transform elements, a DigestMethod, and a DigestValue. Transforms are algorithms that modify the resource being referenced in some way. The SignedInfo element and all its descendents are canonicalized and signed, using the specified algorithms, with the result put into the SignatureValue element.

    In addition to SignedInfo and SignatureValue, a Signature can have two other optional elements: Object and KeyInfo. The Object element is a flexible element typically used to contain items to be signed and/or other information about the Signature. The Object element may contain a SignatureProperties element, which is a place to put properties about an XML Signature such as the time the Signature occurred. Also, an Object element could contain a Manifest, which is a set of Reference elements, formatted exactly like SignedInfo, with the only difference being the application is notified if a Reference from a Manifest fails validation; whereas if a Reference from SignedInfo fails validation, the entire signature fails. KeyInfo provides the key, or a pointer to the key, needed to validate the XML Signature.

    The Reference URI is quite flexible and can point to resources in a variety of ways. There are three types of References, also known as XML Signature types: Enveloping Signatures, in which the Signature element wraps the item being signed; Enveloped Signatures, in which the Signature element is a descendent of the resource being signed; and Detached Signatures, in which the resource being pointed to is none of the above. Detached Signatures can have Reference URIs pointing to an XML element within the current document (but not to an ancestor node), to a binary file such as a GIF image, or to all or part of an external XML document.

    We have spent extra time on helping you to understand XML Signature primarily because it is the first of the XML Security standards and is fundamental to the newer XML and Web Services Security standards. A good familiarity with XML Signature will help you understand the following standards, as well as provide you with a powerful tool for securing your Web services applications.

    In the next chapter, we look at XML Signature’s sibling standard: XML Encryption.


    Footonotes

    1. XML Signature Specification, http://www.w3.org/TR/xmldsig-core

    2. XPath, XML Path Language (XPath) Version 1.0. W3C Recommendation. J. Clark and S. DeRose. October 1999. http://www.w3.org/TR/1999/REC-xpath-19991116

    3. RFC2440: OpenPGP Message Format. J. Callas, L. Donnerhacke, H. Finney, and R. Thayer. November 1998. http://www.ietf.org/rfc/rfc2440.txt

    SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

    Buy this book now.

  • [gp-comments width="770" linklove="off" ]

    antalya escort bayan antalya escort bayan Antalya escort