Safeguarding the Identity and Integrity of XML Messages - The KeyInfo Element (Page 19 of 21 )
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.
 This 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. |
Next: Security Strategies for XML Signature >>
More Security Articles
More By Sams Publishing
/ 6 
