SOAP Security Extensions

November 8, 2000

Satoshi Hada and Hiroshi Maruyama
Tokyo Research Laboratory, IBM Research
{satoshih, maruyama}@jp.ibm.com

Contents

  1. Introduction
  2. Why Message Layer Security?
    1. Receiver-Oriented Scenario
    2. Sender-Oriented Scenario
  3. Security Requirements
  4. Defining SOAP SecTags
    1. Encryption
    2. Digital Signature
    3. Authorization
    4. Notes
  5. Sample Application
  6. References

1 Introduction

SOAP [SOAP] is a simple, flexible, and extendable mechanism for exchanging structured data, primarily designed for providing an Remote Procedure Call (RPC) mechanism on top of the widely used Internet standards of XML and HTTP. It defines a very thin layer enveloping any type of message (a remote procedure invocation, for example) expressed in XML. The SOAP Envelope is also defined in XML and enables us to add a large variety of meta information to the message, such as transaction ids, message routing information, and message security. The SOAP Envelope consists of two parts: Header and Body. The Header is a generic mechanism for adding features to a SOAP message. All immediate child elements of the SOAP Header element are called header entries. The Body is a container for application data such as an RPC intended for the ultimate recipient of the message. Thus, SOAP can be considered to introduce another layer between the transport layer (e.g., HTTP) and the application layer (e.g. business data), which is a convenient place for conveying message meta information.

Table 1. SOAP communication layering
Layer Examples Comments
Application Business data (e.g., purchase order) In general, the SOAP Body is used to carry application data.
Message SOAP Transaction, message routing, security, etc.
Transport HTTP, SMTP Deals with hop-by-hop data delivery.

The SOAP Header provides a flexible mechanism for extending a SOAP message. Although the SOAP Header is the best place to add security features to messages, the SOAP specification itself does not specify such header elements. In this document, we define them, specifically, focusing on the following three issues:

  1. Encryption: How to encrypt SOAP messages.
  2. Digital Signature: How to digitally sign SOAP messages.
  3. Authorization: How to authorize senders of SOAP messages.

We define the syntax and the semantics of header entries (called SecTags) that carry data related to the above three security issues. For example, we define a header entry to carry digital signatures. In this document, the security provided by the SecTags is called the message layer security or the SOAP layer security.

Organization: In Section 2, we describe why the SOAP layer security is necessary by giving several scenarios. In Section 3, we describe general security requirements and discuss several issues in the SOAP message transmission model. Section 4 defines header entries called SecTags to carry security-related data and describes how to process them. Section 5 gives a sample application using the SecTags.

2 Why Message Layer Security?

First of all, one may ask: "Why do we need the SOAP layer security? Don't we already have transport layer security mechanisms such as SSL/TLS and IPSec? Or should applications be responsible for security?" This section describes several scenarios in which the security provided by the transport layer security is not sufficient or the SOAP layer security is useful for application developers.

  1. End-to-end Security

    SOAP can be used in combination with a variety of transport protocols such as HTTP and SMTP. Regardless of the protocol to which SOAP is bound, a SOAP message travels from the originator to the ultimate destination, potentially by passing through a set of intermediaries along the message path (Figure 1). An intermediary is an application that is capable of both receiving and forwarding SOAP messages. When an intermediary receives a SOAP message, it processes header entries intended for it and must remove them before forwarding the message. It may also insert a similar header entry intended for another intermediary. The "actor" attribute of a header entry can be used to indicate the URI of an intermediary who will process the header entry.

    Secure transport protocols such as SSL/TLS can assure the security of messages during transmission. However, since messages are received and processed by intermediaries, secure end-to-end communication is not possible if these intermediaries are not completely trusted even though the communication links between them are trusted. End-to-end security is also compromised if any one of the communication links is not secured.

  2. Application Independence

    End-to-end security ultimately needs to be achieved at the application level. This is because if there is any point between the communicating parties where messages are in plain text, it can be a potential point of attack. However, it is not an easy task to integrate cryptographic functionality into an application without introducing additional security vulnerabilities. It is true that a number of commercial cryptographic libraries are available, but usually they are extremely flexible to meet many different levels of security requirements, and using them properly may require good understanding of cryptographic technologies. A standardized, application-independent security layer will provide good protection without worrying about cryptographic details. It is thus desirable, in most cases, to have security functionality as close to the application level as possible but not built into the application itself.

  3. Transport Independence

    Consider Case II of Figure 1, in which not all of the connections are via HTTP. One of the intended uses of SOAP intermediaries is to forward messages to different networks, often using different transport protocols. Even if all the communication links are secured and the intermediaries can be trusted, security information such as the authenticity of the originator of the message needs to be translated to the next secure transport protocol along the message path, which could be tedious and complex, which may lead to security breaches. Therefore, it is important to deal with the security issues at the message layer independently of the transport layers.


    Figure 1. When intermediaries are present

  4. Security of Stored Messages

    Transport layer security is to secure data when it is traveling on communication links. It has no effect on stored data. Once a transmission is received and decrypted, transport layer security does not help much in protecting the data from illicit accesses and alterations. In situations where messages are stored and then forwarded, message layer security is necessary. Note that in real business-to-business applications messages are often stored for logging and auditing purposes. Having cryptographic protection on such persistent data may be necessary anyway, and the SOAP security extensions proposed here can be used for this purpose as well.

In the next two subsections, we describe two business-to-business scenarios where security at intermediaries makes sense.

Receiver-Oriented Scenario

In this scenario, we suppose that the ultimate destination does not want to take responsibility for security issues, but wants to guarantee that the originator is authorized and that the message is not modified in transit. For this purpose, an intermediary may process all security-related data. The originator simply asks the intermediary to forward the message to an appropriate destination. The dispatching mechanism, i.e., which message should be sent to which destination, may depend on the content of the SOAP Body. Note that the originator does not need to know the ultimate destination (the ultimate destination 1, 2, or 3). The intermediary can check, (1) whether the originator is authorized to send the message or to benefit from a specific service, and (2) whether or not the message modified in transit.

The SOAP layer security mechanism would help programmers develop such an intermediary rapidly and securely. If such a system is not available, application developers must program some security mechanism by themselves, which will result in bugs and security holes.


Figure 2. Receiver-Oriented Scenario

Sender-Oriented Scenario

This is the opposite of a receiver-oriented scenario, where the originator does not have to handle the security issues. As in the previous scenario, the originator simply asks an intermediary to process its security information and forward the message to the ultimate destination. The intermediary may encrypt or sign the SOAP message. Again, the SOAP layer security would help programmers develop such an intermediary rapidly and securely.


Figure 3. Sender-Oriented Scenario

3 Security Requirements

Our goal is to secure the entire SOAP message including the SOAP Headers and the SOAP Body.

In general, we have five security requirements for message transmission:

The last three requirements are strongly related to each other. In particular, non-repudiation implies message origin authentication, which also implies data integrity. Data integrity is different from message origin authentication in the sense that the former does not guarantee that the transmitted message is not a replay. In other words, data integrity cannot defend against replay attacks. It is important to note that there is a distinction between message origin authentication and non-repudiation. Keyed-hashing such as HMAC [HMAC], using a secret key shared in an authenticated way, is sufficient for message origin authentication, but not sufficient for non-repudiation. Non-repudiation requires a digital signature algorithm such as RSA [PKCS1] or DSA [DSS].

We describe three properties of the SOAP message transmission model and discuss related security requirements.

4 Defining SOAP SecTags

In order to satisfy the five security requirements described at the beginning of Section 3, we discuss three technologies (encryption, digital signature and authorization) in more detail from the perspective of SOAP.

Table 3 summarizes the cryptographic techniques referred to this document.

Table 3. Cryptographic Techniques Used
Requirement Cryptographic Technique
Encryption XML-Encryption [XENC]
Digital Signature W3C XML Signature [XSSP]
Authorization Attribute certificate ("push" model)

As described above, we need to put security-related data such as an XML Signature in the SOAP Header. In order to do this, we define header entries called the SecTags. All SecTags are defined within a single namespace with a URI of http://schemas.xmlsoap.org/soap/security/. The namespace prefix is SOAP-SEC.

We define three SecTags <Encryption>, <Signature> and <Authorization> to add the related security data to SOAP messages.

<schema
  xmlns="http://www.w3.org/1999/XMLSchema"
  xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/"
  targetNamespace="http://schemas.xmlsoap.org/soap/security/"
  xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
  xmlns:xenc="http://http://www.w3.org/2000/10/xmlenc"
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> 
  
  <import namespace="http://www.w3.org/2000/09/xmldsig#"/>
  <import namespace="http://schemas.xmlsoap.org/soap/envelope/"/>
  <import namespace="http://http://www.w3.org/2000/10/xmlenc"/>
  
  <element name="Encryption"> 
    <complexType>
      <sequence>
        <element ref="xenc:DecryptionInfo" minOccurs="1" maxOccurs="1"/>
      </sequence>
      <attribute ref="SOAP-ENV:actor" minOccurs="0" maxOccurs="1"/>
      <attribute ref="SOAP-ENV:mustUnderstand" minOccurs="0" maxOccurs="1"/>
    </complexType>
  </element>
  <element name="Signature"> 
    <complexType>
      <sequence>
        <element ref="ds:Signature" minOccurs="1" maxOccurs="1"/>
      </sequence>
      <attribute ref="SOAP-ENV:actor" minOccurs="0" maxOccurs="1"/>
      <attribute ref="SOAP-ENV:mustUnderstand" minOccurs="0" maxOccurs="1"/>
    </complexType>
  </element>
  <element name="Authorization"> 
    <complexType>
      <sequence>
        <any minOccurs="0" maxOccurs="1"/> 
      </sequence>
      <attribute ref="SOAP-ENV:actor" minOccurs="0" maxOccurs="1"/>
      <attribute ref="SOAP-ENV:mustUnderstand" minOccurs="0" maxOccurs="1"/>
    </complexType>
  </element>
</schema>

Below we describe how to process the SOAP SecTags and provide examples for each header entry. In the final subsection, we note some precautions that should be taken to correctly process different SecTags in the same SOAP message.

4.1 Encryption

This section gives our draft proposal based on the discussion in XML-Encryption mailing list [XENC]. Encryption may be done by the originator or by intermediaries.

The following is an example for encryption. The <xenc:EncryptedData> element is an element encrypted using XML encryption. Note that the <SOAP-SEC:Encryption> element has an <xenc:DecryptionInfo> subelement containing the secret key name, which is shared in advance.

On receiving the partially encrypted envelope, the receiver may decrypt it as follows:

  1. Search the envelope for <xenc:EncryptedData> elements. Note that the envelope may contain several <xenc:EncryptedData> elements.
  2. Each <xenc:EncryptedData> element has a "DecryptionInfoURI" attribute indicating an <xenc:DecryptionInfo> element containing information required to decrypt it, particularly, information on the key used in the encryption.
  3. Using this information, decrypt each encrypted element.

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Header>
    <SOAP-SEC:Encryption
      xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/">
      <xenc:DecryptionInfo Id="decInfo1" xmlns:xenc="http://www.w3.org/2000/10/xmlenc">
        <xenc:Method Algorithm="http://www.w3.org/2000/10/xmlenc#des-cbc-pkcs5padding"/>
        <xenc:ReferenceList>
          <xenc:Reference URI="#encData1"/>
        </xenc:ReferenceList>
        <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
          <ds:KeyName>The Shared Secret Key</ds:KeyName>
        </ds:KeyInfo>
      </xenc:DecryptionInfo>
    </SOAP-SEC:Encryption>
  </SOAP-ENV:Header>
  <SOAP-ENV:Body>
    <m:GetLastTradePrice xmlns:m="some-URI">
      <xenc:EncryptedData 
        xmlns:xenc="http://www.w3.org/2000/10/xmlenc"
        Id="encData1"
        DecryptionInfoURI="#decInfo1" 
        IV="x40tN1mAZSY=">
        0rqGM/nMhGNHY0U6ZhbkuPDEpYaqD/nwqtt0iw361RLeVGvJgn37GeNkdaVY+JizNWsqR//TDeOG=
      </xenc:EncryptedData>
    </m:GetLastTradePrice>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

4.2 Digital Signature

Theses examples show how to add a MAC or a digital signature to a SOAP message. A signer who is either an originator or an intermediary may perform the signature generation process.

Generation process:
Input 1: A private key of a signer, for digital signature generation or a secret key for MAC generation. We assume that the secret key for MAC generation is shared securely between the signer and the actor in advance. We do not specify how to share it.
Input 2: A template of a <ds:Signature> element. The template is assumed not to contain <ds:DigestValue> and <ds:SignatureValue> elements, but to contain the information required to calculate them such as <ds:SignatureMethod> and <ds:Reference> elements. The template may contain a <ds:SignatureProperty> element in the <ds:Object> element which has a nonce.
  1. Create a new <SOAP-SEC:Signature> element and add the template <ds:Signature> element to it. If necessary, the "actor" and "mustUnderstand" attributes may be set.
  2. Append the <SOAP-SEC:Signature> element to a SOAP Header element.
  3. Calculate the digest value and the signature value according to the XML Signature specification [XSSP].
The receiving actor who is either an ultimate destination or an intermediary may validate the attached signature as follows:
Validation process:
Input 1: A secret key for MAC validation. As described above, we assume that this secret key is shared securely in advance.
  1. The actor validates the <ds:Signature> element according to the specification of XML Signature [XSSP].

The following is an example for MAC (HMAC-SHA1). The <SOAP-SEC:Signature> element contains the <ds:Signature> element.

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Header>
    <SOAP-SEC:Signature
      xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/" 
      SOAP-ENV:actor="urn:validator"
      SOAP-ENV:mustUnderstand="1">
      <ds:Signature Id="MyFirstSignature" xmlns:ds="http://www.w3.org/2000/02/xmldsig#"> 
        <ds:SignedInfo> 
          <ds:CanonicalizationMethod     
            Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"> 
          </ds:CanonicalizationMethod>
          <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
          <ds:Reference URI="#Body"> 
            <ds:Transforms> 
              <ds:Transform Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/>
            </ds:Transforms> 
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 
            <ds:DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:DigestValue> 
          </ds:Reference>    
        </ds:SignedInfo> 
        <ds:SignatureValue>MC0CFFrVLtRlk=...</ds:SignatureValue>
      </ds:Signature> 
    </SOAP-SEC:Signature>
  </SOAP-ENV:Header>
  <SOAP-ENV:Body id="Body">
    <m:GetLastTradePrice xmlns:m="some-URI">
      <symbol>DIS</symbol>
    </m:GetLastTradePrice>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Here is an example in which digital signature (DSAwithSHA-1, i.e., DSS) is added. Essentially, this example is the same as the above example except that the <ds:KeyInfo> element containing the signer's public key certificate appears in the <ds:Signature> element.

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Header>
    <SOAP-SEC:Signature
      xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/" 
      SOAP-ENV:actor="urn:validator"
      SOAP-ENV:mustUnderstand="1">
      <ds:Signature Id="MyFirstSignature" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> 
        <ds:SignedInfo> 
          <ds:CanonicalizationMethod     
            Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"> 
          </ds:CanonicalizationMethod>
          <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa"/>
          <ds:Reference URI="#Body"> 
            <ds:Transforms> 
              <ds:Transform Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/>
            </ds:Transforms> 
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 
            <ds:DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:DigestValue> 
          </ds:Reference>    
        </ds:SignedInfo> 
        <ds:SignatureValue>MC0CFFrVLtRlk=...</ds:SignatureValue> 
        <ds:KeyInfo> 
          <ds:X509Data>
            The BASE64-encoded public key certificate of the signer is here.
          </ds:X509Data> 
        </ds:KeyInfo>
      </ds:Signature>
    </SOAP-SEC:Signature>
  </SOAP-ENV:Header>
  <SOAP-ENV:Body id="Body">
    <m:GetLastTradePrice xmlns:m="some-URI">
      <symbol>DIS</symbol>
    </m:GetLastTradePrice>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

4.3 Authorization

Attribute certificates may be added within the SOAP envelope by either an originator or an intermediary.

Pushing an Attribute Certificate:
Input 1: A URI of an actor who is intended to do validation. The actor is either an intermediary or an ultimate destination.
Input 2: The actor's public key.
  1. Get an attribute certificate from an independent authorization authority.
  2. Encode it using BASE64. If necessary, before encoding, encrypt it using the public key of either the intermediary or the ultimate destination, who is intended to validate the attribute certificate.
  3. Create a new <SOAP-SEC:Authorization> element and added to it an <AttributeCert> element containing the BASE64 encoded attribute certificate. If the actor is an intermediary then the <SOAP-SEC:Authorization> element must have an "actor" attribute indicating the URI of the actor.
  4. Append the <SOAP-SEC:Authorization> element to a SOAP Header element.
Validation process:
Input1: The public key of an authorization authority.
Input2: The actor's private key.
  1. If necessary, the actor uses his/her private key to retrieve the attribute certificate.
  2. Check the validity of the attribute certificate.

The following is an example for authorization.

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Header>
    <SOAP-SEC:Authorization 
      xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/" 
      SOAP-ENV:actor="a URI of an actor"
      SOAP-ENV:mustUnderstand="1">
      <AttributeCert 
        xmlns="http://schemas.xmlsoap.org/soap/security/AttributeCert">
        A BASE64 encoded attribute certificate is here.
        If necessary, it should be encrypted using the specified actor's public key.
      </AttributeCert>
     </SOAP-SEC:Authorization>
   </SOAP-ENV:Header>
   <SOAP-ENV:Body>
     <m:GetLastTradePrice xmlns:m="some-URI">
       <symbol>DIS</symbol>
     </m:GetLastTradePrice>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

4. 4 Notes

The key management for these SecTags is an important issue, but is not mentioned in this document.

The SOAP layer security does not depend on any transport layer, nor on higher any application layer. However, it is still true that more secure and practical solutions are possible by combining the SOAP layer security with some transport layer security and some application layer security.

When an originator and several intermediaries will add several SecTags to the same message, problems may appear. Below we give a few scenarios. Application designers should be careful about these problems at design time.

Consider a connection in which two intermediaries A and B forward messages in order. Assume that the originator and B shares a secret key K1 and that A and the ulitimate destination shares a secret key K2. The originator encrypts an element by K1 and sends it to A. A encrypts the encrypted element by K2 and sends it to B. In this case, the ultimate destination cannot retrieve the original element unless it knows the secret key K1.

The order of signature generation and encryption processes matters when the originator and several intermediaries will add both encryption and signature SecTags. If they are processed in an inappropriate order, the signature validation may fail. For example, the following order is inappropriate: The originator first adds a MAC intended for an intermediary and then encrypts the body using a secret key shared between the originator and the ultimate destination. In this case, the intermediary cannot validate the MAC because the body cannot be decrypted except by the ultimate destination.

Another example of failure is the case where the originator signs a header entry. The originator signs a header entry intended for an intermediary and adds the signature as a separate header entry intended for the ultimate destination. If the intermediary receives the message, processes the header entry, and remove it, the ultimate destination cannot validate the signature.

For authorization, anyone can add any number of attribute certificates regardless of any other already added SecTags. This is because the authorization SecTags have no effect on other SecTags.

5 Sample Application

In this section, we give a sample application using the signature SecTags. We will consider the following scenario: A client of Company A sends a purchase order to Shop-IBM. In this transaction, they want their respective gateways to generate (or validate) a signature.


Figure 4. Purchase Order: From Company A to IBM

  1. An originator in the Company A requests the security gateway to sign the body and forward it to Shop-IBM (the IBM Gateway). The <SignatureRequest> element indicates the id of the element which is to be signed.

    <SOAP-ENV:Envelope
        xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
     <SOAP-ENV:Header>
        <delivery>
           <send-to>IBM Corp., Shop-IBM internet shop</send-to>
           <URL>http://www.ibm.com/shop/</URL>
        </delivery>
        <SignatureRequest actor="http://company-A.com/Gateway/">
           <Reference URI="#Body"/>
        </SignatureRequest>
     </SOAP-ENV:Header>
     <SOAP-ENV:Body id="Body">
       <PurchaseOrder>
         <PurchaseLineItems>
           <Order>
             <Product>Think Pad 560</Product>
             <Quantity>100</Quantity>
           </Order>
         </PurchaseLineItems>
       </PurchaseOrder>
     </SOAP-ENV:Body>
    </SOAP-ENV:Envelope>
    

  2. The Company A Gateway, the actor specified in the <SignatureRequest> element, signs the body and send it to the gateway of IBM.

    <SOAP-ENV:Envelope
        xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
     <SOAP-ENV:Header>
        <delivery>
           <send-to>IBM Corp., Shop-IBM internet shop</send-to>
           <URL>http://www.ibm.com/Gateway/</URL>
        </delivery>
        <!-- Signature request is replaced by signature SecTag. -->
        <!-- The details are omitted.                           -->
        <SOAP-SEC:Signature actor="http://www.ibm.com/Gateway/">
          <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
              <ds:Reference URI="#Body">
            </ds:SignedInfo>
            <ds:SignatureValue>E739AK3KD3..</ds:SignatureValue>
          </ds:Signature>
        </SOAP-SEC:Signature>
     </SOAP-ENV:Header>
           
     <SOAP-ENV:Body id="Body">
       <PurchaseOrder>
         <PurchaseLineItems>
           <Order>
             <Product>Think Pad 560</Product>
             <Quantity>100</Quantity>
           </Order>
         </PurchaseLineItems>
       </PurchaseOrder>
     </SOAP-ENV:Body>
    </SOAP-ENV:Envelope>
    

  3. At the IBM gateway, the signature is verified and the certification information (e.g., originator id) is extracted and added within the SOAP message.

    <SOAP-ENV:Envelope
        xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
     <SOAP-ENV:Header>
        <delivery>
           <send-to>IBM Corp., Shop-IBM internet shop</send-to>
           <URL>http://www.ibm.com/shop/</URL>
        </delivery>
        <SignatureVerified>
           <CertificationInfo>
              <SubjectName>Company A, Inc.</SubjectName>
              <IssuedBy>Verisign Inc. Class 3 CA</IssuedBy>
              <ExpirationDate>20030503</ExpirationDate>
           </CertificateInfo>
           <CustomerInfo class="Premier-A"/>
           <CRLChecked>yes</CRLChecked>
        </SignatureVerified>
     </SOAP-ENV:Header>
           
     <SOAP-ENV:Body id="Body">
       <PurchaseOrder>
         <PurchaseLineItems>
           <Order>
             <Product>Think Pad 560</Product>
             <Quantity>100</Quantity>
           </Order>
         </PurchaseLineItems>
       </PurchaseOrder>
     </SOAP-ENV:Body>
    </SOAP-ENV:Envelope>
    

6 References

[DSS] NIST, Digital Signature Standard (DSS), FIPS PUB 186-1.
[HMAC] IETF, HMAC: Keyed-Hashing for Message Authentication, IETF RFC 2104.
[IACP] IETF, An Internet Attribute Certificate Profile for Authorization, IETF INTERNET-DRAFT.
[PKCS1] IETF, PKCS#1: RSA Cryptography Specifications Version 2.0, IETF RFC 2437.
[SHA-1] NIST, Secure Hash Standard, FIPS PUB 180-1.
[SMIME] IETF, S/MIME Version 3 Message Specification, IETF RFC 2633.
[SOAP] W3C, SOAP: Simple Object Access Protocol 1.1, W3C Note 08 May 2000.
[TLS] IETF, The TLS Protocol Version 1.0, IETF RFC 2246.
[XENC] W3C, XML Encryption ML, W3C ML.
[XSSP] IETF, XML-Signature Syntax and Processing, W3C Candidate Recommendation, 31 October 2000.