Section 12.8. Processing Model

12.8. Processing Model

The preceding section defined the architecture concepts. This section documents the model for processing messages with respect to the WS-Security standards. The processing model of WS-Security is built on top of the substrate provided by SOAP, XML Signature, and XML Encryption. Therefore, this section first looks at the processing models of these specifications.

12.8.1. XML Signature

XML Signature protects parts of an XML document from unauthorized modifications using a cryptographic technique called digital signature. The signature algorithm can be either a symmetric cryptosystem such as Triple DES and AES (Advanced Encryption Standard), or an asymmetric (public key) cryptosystem such as RSA and DSA.

The following XML fragment shows the basic syntax of XML Signature. The <ds:Signature> element can be the top-level XML element or can be embedded somewhere in a larger XML document. In WS-Security, this element is embedded in a SOAP (security) header block:

 <ds:Signature>   <ds:SignedInfo>     <ds:CanonicalizationMethod Algorithm="..."/>     <ds:SignatureMethod Algorithm="..."/>     <ds:Reference URI="...">        <ds:Transforms> ... </ds:Transforms>        <ds:DigestMethod Algorithm="..."/>        <ds:DigestValue> ... </ds:DigestValue>     </ds:Reference> +   </ds:SignedInfo>   <ds:SignatureValue> ... </ds:SignatureValue>   <ds:KeyInfo> ... </ds:KeyInfo>?   <ds:Object> ... </ds:Object>* </ds:Signature> 

The digital signature algorithm specified in the <ds:SignatureMethod> element is used to sign the <ds:SignedInfo> element, and the signature value is placed into the <ds:SignatureValue> element. The <ds:SignedInfo> element in turn contains one or more <ds:Reference> elements, which refer to the data in the message that are to be signed. Because the digest values of the referenced data are included in the <ds:SignedInfo> element, a cryptographic binding exists between the referenced data and the <ds:SignedInfo> element. That is, if the reference data changes, the digest value of the data also changes, resulting in a different value in the <ds:DigestValue> element within the <ds:SignedInfo> element.

Thanks to this indirection, XML Signature allows signing multiple parts of an XML document in a single signature operation. This is particularly useful in WS-Security, when the message body and some parts of the header blocks need to be protected from unauthorized alterations. Optionally, the key used in this operation can be specified using the optional <ds:KeyInfo> element.

Because signature algorithms work on binary data, the data to be signed must also be represented as binary data (or an octet string). This leads to some complications because an XML document is defined in InfoSet, not as an octet string. For example, the same XML document can be represented as a different octet string by just changing the character encoding from UTF-8 to ISO-8859-1.

Other characteristics of an XML document can alter its representation as an octet string while still representing the same InfoSet; for example, the order in which attributes appear on an element or the use of certain white space characters (such a newlines). Canonical XML, defined by the W3C XML Signature Working Group, is a specification that defines an octet-string representation of an XML document which assigns a unique octet string (the canonical XML representation) to each XML InfoSet. The <ds:CanonicalizationMethod> element specifies the algorithm used to derive this unique representation. In WS-Security, the recommended algorithm is W3C Exclusive Canonicalization, a variation of W3C Canonical XML with namespace handling that's more suitable for SOAP messages.

12.8.2. XML Encryption

Similar to XML Signature, XML Encryption encrypts portions of an XML document. The general syntax of XML Encryption is shown here:

<xenc:EncryptedData (Id="")? (Type="")?>   <xenc:EncryptionMethod/>?   <ds:KeyInfo>    <xenc:EncryptedKey/>?    <ds:*/>?   </ds:KeyInfo>?   <xenc:CipherData>     <xenc:CipherValue>(encrypted character data) </xenc:CipherValue>?     <xenc:CipherReference URI=""/>?   </xenc:CipherData> </xenc:EncryptedData> 

As in XML Signature, the <xenc:EncryptionMethod> element specifies the encryption algorithm, and the <ds:KeyInfo> element specifies the encryption key or its location. Because it is a bad practice to use the recipient's long-lasting key repeatedly (such as a proof of possession key for identity claims) when encrypting a large amount of data, the encryption key is generated randomly for each message. This encryption key, sometimes called a session key, is then carried in the same message but it is encrypted using the recipient's long-lasting key, or some other set of keys that both the parties know. The <xenc:EncryptedKey> element is used for this purpose.

When some part of an XML document needs to be encrypted, it can be replaced with the <xenc:EncryptedData> element, with both the key information and the encrypted data. Alternatively, the key information and the encrypted data can be put into separate places using two <enc:EncryptedData> elements. In WS-Security, the latter method is used because the key information needs to be in the header block, whereas <enc:EncryptedData> must stay in the original position of the data within the SOAP envelope.