The

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).

TABLE OF CONTENTS:

Safeguarding the Identity and Integrity of XML Messages XML Signature Fundamentals XML Signature Structure Types of XML Signatures The Signature Element Schema XML Signature Processing XML Signature Validation The XML Signature Elements Canonicalization Actions from Canonical XML Version 1.0 The SignatureMethod Element The Reference Element The Transform Element XPath Filtering Transform Enveloped Signature Transform XPath Filter 2.0 Transform The DigestMethod Element The Object Element The Manifest Element The KeyInfo Element Security Strategies for XML Signature Summary

By: Sams Publishing	Poor Best
Rating:  / 7
September 09, 2004

print this article

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.