Home arrow Security arrow Page 19 - Safeguarding the Identity and Integrity of XML Messages

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:
  1. Safeguarding the Identity and Integrity of XML Messages
  2. XML Signature Fundamentals
  3. XML Signature Structure
  4. Types of XML Signatures
  5. The Signature Element Schema
  6. XML Signature Processing
  7. XML Signature Validation
  8. The XML Signature Elements
  9. Canonicalization Actions from Canonical XML Version 1.0
  10. The SignatureMethod Element
  11. The Reference Element
  12. The Transform Element
  13. XPath Filtering Transform
  14. Enveloped Signature Transform
  15. XPath Filter 2.0 Transform
  16. The DigestMethod Element
  17. The Object Element
  18. The Manifest Element
  19. The KeyInfo Element
  20. Security Strategies for XML Signature
  21. Summary
By: Sams Publishing
Rating: starstarstarstarstar / 7
September 09, 2004

print this article

SEARCH DEV SHED

TOOLS YOU CAN USE

advertisement

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.



 
 
>>> More Security Articles          >>> More By Sams Publishing
 

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort
   

SECURITY ARTICLES

- Secure Your Business for Data Privacy Day
- Google Testing Security Fob Password Alterna...
- Security News Highlights Concerns
- Going to Extremes for Data Security
- Skipfish Website Vulnerability Scanner
- Critical Microsoft Visual Studio Security Pa...
- US Faces Tech Security Expert Deficit
- LAN Reconnaissance
- An Epilogue to Cryptography
- A Sequel to Cryptography
- An Introduction to Cryptography
- Security Overview
- Network Security Assessment
- Firewalls
- What’s behind the curtain? Part II

Developer Shed Affiliates

 


Dev Shed Tutorial Topics: