XML Key Management Specification (XKMS 2.0)
Part II: Protocol Bindings

W3C Editors Copy 31^st March 2003

This version:

http://www.w3c.org/2001/XKMS/Drafts/XKMS20030331/xkms-part-2.html  

Latest version:

http://www.w3c.org/2001/XKMS/Drafts/XKMS/xkms-part-2.html

Previous version:

http://www.w3c.org/2001/XKMS/Drafts/XKMS20030326/xkms-part-2.html 

Editors:

Phillip Hallam-Baker, VeriSign Inc.
Merlin Hughes, Baltimore Technologies

Contributors:

See the WG participants list.

[1] Copyright © 2001-2003 W3C^® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

---

Table Of Contents

XML Key Management Specification (XKMS 2.0) Part II: Protocol Bindings

W3C Editors Copy 31st March 2003

Abstract

Status of this document

Table Of Contents

1 Introduction

1.1 Editorial and Conformance Conventions

1.2 Acknowledgments

1.3 Definition of Terms

1.4 Structure of this document

2 Security Requirements

2.1 Confidentiality

2.2 Request Authentication

2.3 Response Authentication

2.4 Persistent Authentication

2.5 Message Correlation (Response Replay and Request Substitution)

2.6 Request Replay

2.7 Denial of Service

2.8 Security Requirements Summary

3 SOAP Binding

3.1 XKMS SOAP Message Binding

3.2 Namespace inclusions

3.3 Computation of XML Signature Elements in XKMS Messages

3.4 Use of SOAP Faults

3.5 SOAP over HTTP binding

4 Security Bindings

4.1 Payload Authentication Binding

4.2 Secure Socket Layer and Transaction Layer (SSL/TLS)Security Binding

Appendix A References

1 Introduction

1.1 Editorial and Conformance Conventions

[9] This specification uses XML Schemas [XML-schema] to describe the content model.

[10] The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in RFC2119 [KEYWORDS]:

[11] "they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)"

[12] Consequently, we use these capitalized keywords to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. These key words are not used (capitalized) to describe XML grammar; schema definitions unambiguously describe such requirements and we wish to reserve the prominence of these terms for the natural language descriptions of protocols and features. For instance, an XML attribute might be described as being "optional." Compliance with the XML-namespace specification [XML-NS] is described as "REQUIRED."

1.2 Acknowledgments

[13] The contributions of the following Working Group members to this specification are gratefully acknowledged in accordance with the contributor policies and the active WG roster.

• Daniel Ash, Identrus
• Blair Dillaway, Microsoft
• Donald Eastlake 3rd, Motorola
• Yassir Elley, Sun Microsystems
• Jeremy Epstein, webMethods
• Stephen Farrell, Baltimore (Co-Chair)
• Phillip Hallam-Baker, VeriSign Inc. (Editor)
• Loren Hart, VeriSign Inc.
• Mack Hicks, Bank of America
• Merlin Hughes, Baltimore
• Frederick Hirsch, Nokia Mobile Phones
• Mike Just, Treasury Board of Canada Secretariat
• Brian LaMacchia, Microsoft
• Pradeep Lamsal
• Shivaram Mysore, Sun Microsystems (Co-Chair)
• Joseph Reagle, W3C
• Dave Remy, GeoTrust, Inc.
• Peter Rostin, RSA Security Inc.
• Ed Simon, XMLsec Inc.
• Slava Galperin,  Sun Microsystems

[14] The authors also acknowledge the extensive assistance provided in the design stage of this specification by David Solo (CitiGroup), and the contributions of Jeremy Epstein, (webMethods), Andrew Layman  (Microsoft), Dr Paul Boisen (NSA),  Dan Guinan, Marc Hayes, Alex Deacon, Mingliang Pei (VeriSign).

1.3 Definition of Terms

[15] This document uses the terms defined in section 1.3 of part one of this specification in the manner described therin.

1.4 Structure of this document

[16] The remainder of this document describes the XML Key Information Service Specification and XML Key Registration Service Specification.

Section 2: Security Requirements

The security requirements of the XKMS protocol are specified.

Section 3: Payload Security Protocol

The security properties supported by the XKMS payload security features are described.

Section 4: Security Bindings

The use of XKMS payload security features is described in the context of specific security protocols.

Section 5: Security Considerations

Security considerations relevant to the implementation and deployment of the specification are discussed.

2 Security Requirements

[17] Security enhancements MAY be required to control the following risks:

• Confidentiality
• Request Authentication
• Response Authentication
• Persistent Authentication
• Response Replay
• Request Substitution
• Request Replay
• Denial of Service

[18] The security enhancements required varies according to the application. In the case of a free or un-metered service the service may not require authentication of the request. A responder that requires an authenticated request must know in that circumstance that the request corresponds to the specified response.

2.1 Confidentiality

[19] Message confidentiality protects protocol messages from disclosure to third parties. Confidentiality MAY be a requirement for an XKMS service. Deployments SHOULD consider the extent to which the content of XKMS messages reveal sensitive information. A confidentiality requirement MAY exist even if a service only provides information from public sources as the contents of a request might disclose information about the client.

[20] The use of transport or payload confidentiality protection is NOT a substitute for the encryption of private keys specified in the XKRSS Registration and Recovery services. A service that supports registration of server generated keys or Key Recovery MUST implement the use of XML Encryption with a strong cipher.

[21] An XKMS service SHOULD support Confidentiality by means of encryption.

[22] The means by which the client determines that the encryption key of the service is trustworthy is outside the scope of this specification. Possible mechanisms include:

• A root key embedded in the client application
• A trustworthy signing key exchanged using an XML based assertion mechanism such as that proposed by WS-TrustAxiom.
• A signing key obtained using some other retrieval mechanism such as PKIX or SPKI.

[23] An XKMS service MAY determine the trustworthiness of an encryption key by reference to another XKMS service provided that the chain of references is eventually grounded by a mechanism that establishes direct trust between the client and the service.

2.2 Request Authentication

[24] Request Message Authentication MAY be required. An XKMS Service MAY require request authentication in deployments where the XKMS service is restricted to a specific audience, possibly as a paid service. An XKMS Service MAY require request authentication in contexts where different levels of service are supported according to the identity of the requestor.

[25] In addition various forms of Authentication MAY be required in the XKRSS Registration protocol to confirm the credentials of the party initiating the request and their possession of the private key component of the key pair(s) being registered.

[26] An XKMS service SHOULD support Message Request Authentication.

2.3 Response Authentication

[27] Message Response Authentication MAY be required. Message Response Authentication is required in any deployment of a Validate service. A Locate service that provides only data that is self-authenticating such as X.509 or PGP certificates does not require Message Response Authentication.

[28] Note that Message Response Authentication is considered separately from Response Replay Protection.

[29] An XKMS service SHOULD support Request Authentication.

2.4 Persistent Authentication

[30] In some circumstances requests or responses or to both may require persistent authentication. That is a message sent by A and authenticated by B may be subject to forwarding and authentication by C. In addition some applications may require further measures to ensure that messages meet certain legal standards to prevent repudiation.

[31] An XKMS service MAY support Persistent Authentication by means of a digital signature on the message.

2.5 Message Correlation (Response Replay and Request Substitution)

[32] An XKMS service MUST support a means of ensuring correct message correlation. That is the requestor must be assured that the response returned was made in response to the intended request sent to the service and not a modification of that request (Request Substitution attack) or a response to an earlier request (response replay attack).

[33] In order to prevent response replay and request message substitution attacks the requestor SHOULD ensure that the response corresponds to the request. For correspondence verification to be possible authentication of the response is required. In the TLS binding the correspondence between the request and response is provided by the transport layer. For message layer security mechanisms such as payload security the mechanism required depends on whether or not the request is authenticated as follows:

Authenticated Request

If the request and the response are authenticated the correspondence of the request and response may be determined by verifying the value of RequestID in the response.

Digest Authenticated Request

If the original request was authenticated by means of an XML Signature with a message digest as the signing algorithm, the service can still ensure a strong binding of the response to the original request by means of the <RequestSignatureValue> element.

2.6 Request Replay

[34] An XKMS service may require protection against a Request replay attack. In circumstances where no accounting or other auditing is used to keep track of requests made, protection against a request replay attack may not be required.

[35] An XKMS service MAY provide protection against a Request Replay.

2.7 Denial of Service

[36] An XKMS service may require protection against a Denial of Service attack by means of protocol measures. Such measures may not be required in circumstances where an XKMS service is protected against Denial of Service by other means such as the service is managed on an isolated, tightly controlled network and does not provide service outside that network.

[37] Denial of service attacks that originate from a single identified source or set of sources may be addressed by applying velocity controls. In cases where the source of the denial of service is disguised lightweight authentication techniques such as the two-phase protocol described bellow may be used to detect requests from forged addresses.

[38] An XKMS service SHOULD support protection against a Denial of Service attack.

2.8 Security Requirements Summary

[39] The following table summarizes the possible security requirements that an XKMS service deployment may be subject to:

[40] Where the security requirements of the XKRSS protocol differ from those of XKISS they are addressed by the XKRSS protocol directly rather than relying upon the message security binding.

[41] For example the XKRSS registration functions are designed to support use in modes in which a client registration request is accepted by a Local Registration Authority and then forwarded to a Master Registration Authority. In this mode it is essential that the proof of possession of the private key being registered can be verified by both the Local Registration Authority and the Master Registration Authority, even though the authentication for the request sent to the Master Registration Authority is likely to be provided by the Local Registration Authority, rather than the original requestor. Similar considerations affect the distribution of private keys.

3 SOAP Binding

[42] This section describes a mechanism for communicating the XKMS messages defined in Part 1 of this specification using the SOAP message protocol. XKMS implementers should support the SOAP message protocol for interoperability. When doing do, they MUST use the binding described herein. Bindings for both SOAP 1.2 [SOAP1.2-1][SOAP1.2-2] and SOAP 1.1[SOAP] protocols are specified. Use of SOAP 1.2 is recommended though implementers may prefer SOAP 1.1 in the near term for compatibility with existing tools and supporting infrastructure.

3.1 XKMS SOAP Message Binding

3.1.1 SOAP 1.2 Binding

[43] XKMS implementers shall use SOAP document style request-response messaging with the XKMS messages defined in Part 1 carried as unencoded Body element content. The SOAP 1.2 RPC representation, and requisite encoding style, are not used. The potential benefits of using the RPC representation do not justify the additional effort required to define a mapping from the Part 1 messages to an appropriate encoding style.

[44] The XKMS binding shall use the SOAP Request-Response Message Exchange Pattern defined in [SOAP1.2-2] and message processing shall conform to that model. SOAP 1.2 messages carrying XKMS content shall use the UTF-8 character encoding to insure interoperability.

[45] SOAP 1.2 messages carrying XKMS content shall conform to the following structure:

[46] XKMS Request Message

<?xml version='1.0' encoding="utf-8"?>
<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"> 
 <env:Header>
  <env:Body>
     XKMS Request Message element 
</env:Body>
</env:Envelope>

[47] XKMS Response Message

<?xml version='1.0' encoding="utf-8"?>
<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"> 
 <env:Header>
  <env:Body>
     XKMS Response Message element 
</env:Body>
</env:Envelope>

[48] The XKMS SOAP message binding does not require use of SOAP Headers. Headers may be used with SOAP messages carrying XKMS content to provide additional services such as communications security or routing. The use of such Headers is beyond the scope of this specification. If used however, they must not alter the message encoding style or SOAP processing model specified herein.

[49] Sample XKMS LocateRequest and LocateResponse message communicated using SOAP 1.2 message transport are shown below:

[50] LocateRequest Message

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope">
  <env:Body>
    <LocateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
                   xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
                   Id="I94d1048aa24259465d7271cb4433dbb4"
                   Service=http://test.xmltrustcenter.org/XKMS<http://test.xm
                         ltrustcenter.org/XKMS>
                   xmlns="http://www.w3.org/2002/03/xkms#">
      <RespondWith>KeyName</RespondWith>
      <RespondWith>KeyValue</RespondWith>
      <RespondWith>X509Cert</RespondWith>
      <RespondWith>X509Chain</RespondWith>
      <RespondWith>PGPWeb</RespondWith>
      <RespondWith>PGP</RespondWith>
      <RespondWith>Multiple</RespondWith>
      <QueryKeyBinding>
        <KeyUsage>Encryption</KeyUsage>
        <UseKeyWith Application="urn:ietf:rfc:2440" 
              Identifier="bob@bobcorp.test" />
        <UseKeyWith Application="urn:ietf:rfc:2633" 
              Identifier="bob@bobcorp.test" />
      </QueryKeyBinding>
   </LocateRequest>
 </env:Body>
</env:Envelope>

[51] LocateResponse Message

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope">
  <env:Body>
    <LocateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
                  xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
                  Id="I075365c6e4d9feec5abf1d8a4504e4e8"
                  Service=http://test.xmltrustcenter.org/XKMS<http://test.xml
                        trustcenter.org/XKMS>
                  ResultMajor="Success"
                  RequestId="#I94d1048aa24259465d7271cb4433dbb4"
                  xmlns="http://www.w3.org/2002/03/xkms#">
      <KeyBinding Id="I9b2502783d8587288b55263b1332c83d">
        <KeyInfo>
          <ds:KeyValue>
            <ds:RSAKeyValue>
<ds:Modulus>
4i0BEhQ8Jc4tjwZYbvtMyYfBrIGOMx34K4Cdo2pAzoGnV679FLmGHWnQy2cSj39hf5D1mIaPyD3j/
      33TdfglTaaKqp7IPf6ei754fOuI/r1HpX7uqsw+j9LC4Z7GnG3yoY/eBJOZ8TRwMnx+Mkwm
      opXPVLvhMWRyiUOcO3SEkTE=
</ds:Modulus>
              <ds:Exponent>AQAB</ds:Exponent>
            </ds:RSAKeyValue>
          </ds:KeyValue>
          <ds:X509Data>
<ds:X509Certificate>
MIIB+zCCAWigAwIBAgIQhzf6GHdFobRCYrjlFTCekjAJBgUrDgMCHQUAMBIxEDAOBgNVBAMTB1Rlc
      3QgQ0EwHhcNMDIwNjEzMjEzMzQyWhcNMzkxMjMxMjM1OTU5WjAlMSMwIQYDVQQGExpVUyBP
      PUJvYiBDb3JwIENOPUJvYiBCYWtlcjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtw2
      qGqYbO0aKeZFb0Z3verx3Cp+KS94LiHG09D1DdgTd48FZaB5eXa4U3mLax2/Fsg/cxGZkXJ
      ur0YylS8QvRuX+9STQgiFTO277sHFfRMvtFsuQ56ovrQWH/KoGQZssMUIqO2aN2cbMQJST3
      a2HZuxqPQ1rwXxHrEoAXHZv3ysCAwEAAaNHMEUwQwYDVR0BBDwwOoAQRWvWDxzHMSR0xfgY
      CUPpNqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEHKxUcSI0WKITaXFa+Ylh5IwCQYFKw4DAh0
      FAAOBgQCieDKjvNCo7MPs 
      gUwHydkid4KnulcuBbZet87lcIA7ReH1qEK4s0p49po2UM69eWG7hfv8LW2Ga8HiEexTwLD
      FBvH2g7f09xI/vYgPw4qhJfWoZuY/HWHUzZIRSoggipndVfdvUkmsFSx1rR4FMu0mYBjq79
      OkYsmwISQlaXejUg==
</ds:X509Certificate>
<ds:X509Certificate>
MIIB9zCCAWSgAwIBAgIQcrFRxIjRYohNpcVr5iWHkjAJBgUrDgMCHQUAMBIxEDAOBgNVBAMTB1Rlc
      3QgQ0EwHhcNMDIwNjEzMjEzMzQxWhcNMzkxMjMxMjM1OTU5WjASMRAwDgYDVQQDEwdUZXN0
      IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPF33VmCmSSFufPnu0JdFaKsPHsx0
      ee+OYedhMxVh3LXMkMNC++JWDva7H+E9o+uj7dt5cwxHSePsyxPx3Vq+AbEZOsYxGxXgf4O
      uGb8ONBv3B5c8hraOg24c5hjFS6tfNzoiatLVKHeOmPnifhkBI8h8LD7dLHsHfKUrVNwIJN
      QIDAQABo1YwVDANBgNVHQoEBjAEAwIHgDBDBgNVHQEEPDA6gBBFa9YPHMcxJHTF+BgJQ+k2
      oRQwEjEQMA4GA1UEAxMHVGVzdCBDQYIQcrFRxIjRYohNpcVr5iWHkjAJBgUrDgMCHQUAA4G
      BAAynWUPRSbabAEuX0Z8kKN/C2GoEuULW73QxX6Q0PHAatRM6G9ZnzU+ce3lELgOj0Usw/x
      C9Y+2FMgj68rIas+DId5JMMj+SIZEUV1vPPTEiEQ16Gxz9piUQoFljhI22hEl8ki0hIJlFG
      nki+K9dhv/7trMrfKSSHAPIDQZuz01P
</ds:X509Certificate>
           </ds:X509Data>
         </KeyInfo>
         <KeyUsage>Signature</KeyUsage>
         <KeyUsage>Encryption</KeyUsage>
         <KeyUsage>Exchange</KeyUsage>
         <UseKeyWith Application="urn:ietf:rfc:2633" 
      Identifier="bob@bobcorp.test" />
         <Status StatusValue="Valid">
           <Reason>Signature</Reason>
           <Reason>ValidityInterval</Reason>
         </Status>
       </KeyBinding>
     </LocateResult>
   </env:Body>
</env:Envelope>

[52] The structure of conformant SOAP 1.2 messages carrying other XKMS message types should be evident based on this example.

3.1.2 SOAP 1.1 Binding

[53] XKMS implementers using SOAP 1.1 messaging shall use request-response messaging and carry the XKMS messages as unencoded content within the SOAP Body element. The SOAP 1.1 Section 5 encoding model shall not be used. SOAP 1.1 messages carrying XKMS content shall use the UTF-8 character encoding to insure interoperability.

[54] The structure of XKMS SOAP 1.1 messages shall conform to:

[55] XKMS Request Message

<?xml version='1.0' encoding="utf-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope"> 
 <env:Header>
  <env:Body>
     XKMS Request Message element 
</env:Body>
</env:Envelope>

[56] XKMS Response Message

<?xml version='1.0' encoding="utf-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope"> 
 <env:Header>
  <env:Body>
     XKMS Response Message element 
</env:Body>
</env:Envelope>

[57] As with the SOAP 1.2 binding, the SOAP 1.1 binding does not require use of SOAP Headers. Headers may be used with SOAP messages carrying XKMS content to provide additional services such as communications security or routing providing they don't impact the encoding style or SOAP processing model specified herein.

[58] SOAP 1.1 messages carrying XKMS content will are identical to those using SOAP 1.2 except for the namespace of the Envelope and Body elements. Hence, the examples shown in Section 3.1.1 are conformant once the SOAP 1.2 namespace is replaced by the SOAP 1.1 namespace (http://schemas.xmlsoap.org/soap/envelope).

3.2 Namespace inclusions

[59] In using the XKMS SOAP binding, XKMS messages are constructed as defined in Part 1 of this specification including all required namespace declarations. The top-level message element is then inserted as a child of the SOAP Body element. Promotion of XKMS namespace declarations to the parent SOAP Body (or grandparent Envelope) element is not required, but may be done at the discretion of the implementer.

[60] Insertion of an XKMS message into the SOAP message structure must not alter namespace prefixes, or use of default namespaces, within the XKMS message. Any change in these encodings will likely break an XML Signature internal to the XKMS messages due to the use of QNames and namespace prefixes. The implementer must insure that prefix values used with the SOAP namespaces http://www.w3.org/2002/06/soap-envelope (SOAP 1.2) and http://schemas.xmlsoap.org/soap/envelope (SOAP 1.1) do not conflict with prefixes used in the XKMS message.

3.3 Computation of XML Signature Elements in XKMS Messages

[61] Use of the XKMS SOAP binding does not affect processing of the XML Signature-based elements (KeyBindingAuthentication and ProofOfPossession) defined in Part 1. These are computed as described in Part 1, Section 6.0.2 and 6.0.3 respectively, and the signature validation processing described in "Part 1 - 2.7.2 Element <ds:Signature>." That is, the SOAP defined nodes and namespaces do not contribute to the Signature computation.

3.4 Use of SOAP Faults

[62] SOAP Faults shall be used by an XKMS service to communicate errors that prevent the processing of a received XKMS request message. XKMS clients should never send a SOAP Fault message to an XKMS service.

3.4.1 SOAP 1.2 Faults

[63] The following SOAP Fault messages are defined for use with the XKMS SOAP 1.2 binding. Consistent with the SOAP 1.2 specification, these Fault messages shall contain the mandatory Code and Reason element information items. Inclusion of other elements is at the discretion of the implementer.

[64] In response to an XKMS request message, the receiver shall respond with one of the following SOAP Faults if it is unable to process the message. If it is able to process the message, then the response should conform to a valid XKMS response message as described in Part 1.

1. A fault with a Value of "env:VersionMismatch" for Code shall be returned when the XKMS service finds an invalid element information item instead of the expected Envelope element information item, or the namespace, local name or both did not match the required Envelope element information item. The Reason element shall be "Unsupported SOAP version".
2. A fault with a Value of "env:MustUnderstand" for Code shall be returned if there is an immediate child element information item of the SOAP Header element information item that was either not understood or not obeyed by the faulting node when the Header contained a SOAP mustUnderstand attribute information item with a value of "true". The value for Reason shall be "Unable to process [header element name]" where the expression in brackets is replaced by the header element information item which caused the initial fault.
3. A fault with a Value of "env:Receiver" for Code shall be generated when the receiver cannot handle the message because of some temporary condition, e.g. when it is out of memory. The Reason shall be "Service temporarily unable".
4. A fault with a Value of "env:Sender" for Code and a Value of "xkms:MessageNotSupported" for Subcode shall be generated when the receiver does not support the type of request message. The Reason shall be "[XKMS message type] not supported" where the expression in brackets is replace by the element information item name corresponding to the received XKMS request message.
5. A fault with a Value of "env:Sender" for Code and a Value of "xkms:BadMessage" for Subcode shall be generated when the receiver cannot parse the received XKMS message. The Reason shall be "[XKMS message type] invalid" where the expression in brackets is replaced by the element information item name corresponding to the received XKMS request message.

[65] A sample SOAP 1.2 fault message that would be returned when the received XKMS request message isn't supported by the service is shown below:

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope">
 <env:Body>
  <env:Fault>
    <env:Code>
      <env:Value>env:Sender</env:Value>
      <env:Subcode>
        <env:Value>xkms:MessageNotSupported</env:Value>
      </env:Subcode>
    </env:Code>
    <env:Reason>LocateRequest message not supported</env:Reason>
   </env:Fault>
 </env:Body>
</env:Envelope>

3.4.2 SOAP 1.1 Faults

[66] The following SOAP Fault messages are defined for use with the XKMS SOAP 1.1 binding. Consistent with the SOAP 1.1 specification, these Fault messages shall contain the faultcode and faultstring elements. Inclusion of other elements is at the discretion of the implementer.

[67] In response to an XKMS request message, the receiver shall respond with one of the following SOAP Faults if it is unable to process the message. If it is able to process the message, then the response should conform to a valid XKMS response message as described in [XKMS1].

1. A fault with a faultcode of "env:VersionMismatch" shall be returned when the XKMS service doesn't find the expected Envelope element or the namespace, local name or both did not match the required Envelope element. The faultstring element shall contain "Unsupported SOAP version".
2. A fault with a faultcode of "env:MustUnderstand" shall be returned if there is an immediate child element of the SOAP Header element that was either not understood or not obeyed by the faulting node when the header contained a SOAP mustUnderstand attribute item with a value of "true". The faultstring shall be "Unable to process [header element name]" where the expression in brackets is replaced by the first header element information item which caused the fault.
3. A fault with a faultcode of "env:Server" shall be returned when the service cannot handle the message because of some temporary condition, e.g. when it is out of memory. The faultstring shall be "Service temporarily unable".
4. A fault with a faultcode of "env:Client" shall be returned when the receiver does not support the type of request message. The value for faultstring shall be "[XKMS message type] not supported" where the expression in brackets is replace by the element information item name corresponding to the received XKMS request message.
5. A fault with a faultcode of "env:Client" shall be returned when the receiver cannot parse the received XKMS message. The faultstring shall be "[XKMS message type] invalid" where the expression in brackets is replace by the element information item name corresponding to the received XKMS request message.

[68] A sample SOAP 1.1 fault message that would be returned when the received XKMS request message isn't supported by the service is shown below:

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope">
 <env:Body>
  <env:Fault>
    <env:faultcode>env:Client</env:faultcode>
    <env:faultstring>LocateRequest message not supported</env:faultstring>
   </env:Fault>
 </env:Body>
</env:Envelope>

3.5 SOAP over HTTP binding

[69] When the XKMS binding to SOAP 1.2 is implemented, the SOAP messages should be sent using HTTP POST consistent with the recommendations of Section 6.4.2 in [SOAP1.2-2]. Processing shall be consistent with Section 7, SOAP HTTP Binding in that specification.

[70] When the XKMS binding to SOAP 1.1 is implemented, the SOAP messages should be sent using HTTP POST consistent with the of Section 6.1 in [SOAP].

4 Security Bindings

[71] This specification describes three principal security bindings each of which specifies two or more specific implementation profiles. Each implementation profile is assigned a unique URI to facilitate negotiation of a specific security profile using some mechanism to be described as a part of the wider Web Services framework.

4.1 Payload Authentication Binding

Identifier: http://www.w3.org/2002/03/xkms#payload-I

No mechanism is used to authenticate the client

Identifier: http://www.w3.org/2002/03/xkms#payload-II

The client is authenticated using payload security

[72] The following payload security features are employed.

4.2 Secure Socket Layer and Transaction Layer (SSL/TLS)Security Binding

[73] When TLS is to be used in XKMS, XKMS responders MUST support server authenticated TLS. Note that this means that an XKMS
client need only support anonymous TLS, since to require otherwise would mean that all XKMS clients would have to be able to store root certificates for TLS usage.

All XKMS clients and responders which support TLS MUST support the TLS_RSA_WITH_3DES-EDE_CBC_SHA ciphersuite.
Other ciphersuites MAY be supported, but weak ciphersuites intended to meet export restrictions ("export grade") are NOT RECOMMENDED to be supported."

[74] The SSL/TLS binding has three variants specified by the following identifiers:

Identifier: http://www.w3.org/2002/03/xkms#tls-I

No mechanism is used to authenticate the client

Identifier: http://www.w3.org/2002/03/xkms#tls-II

TLS certificate based client authentication is used to authenticate the client

Identifier: http://www.w3.org/2002/03/xkms#tls-III

Payload security is used for client authentication

[75] The following payload security features are employed.

Appendix A References

[76] [SOAP] D. Box, D Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. Frystyk Nielsen, S Thatte, D. Winer. Simple Object Access Protocol (SOAP) 1.1, W3C Note 08 May 2000, http://www.w3.org/TR/SOAP/

[77] [SOAP1.2-1] W3C Working Draft "SOAP Version 1.2 Part 1: Messaging Framework", Marting Gudgin, et al, 26 June 2002 (Last call Working Draft)

[78] [SOAP1.2-2] W3C Working Draft "SOAP Version 1.2 Part 2: Adjuncts", Martin Gudgin, et al, 26 June 2002 (Last call Working Draft)

[79] [RFC-2246] T. Dierks, C. Allen., The TLS Protocol Version, 1.0.  IETF RFC 2246 January 1999. http://www.ietf.org/rfc/rfc2246.txt

[80] [WSDL] E. Christensen, F. Curbera, G. Meredith, S. Weerawarana, Web Services Description Language (WSDL) 1.0 September 25, 2000, http://msdn.microsoft.com/xml/general/wsdl.asp

[81] [WSTrustAxiom] P. Hallam-Baker et. al., WS-Trust Axiom, To be published

[82] [XML-SIG]  D. Eastlake, J. R., D. Solo, M. Bartel, J. Boyer , B. Fox , E. Simon. XML-Signature Syntax and Processing, World Wide Web Consortium. http://www.w3.org/TR/xmldsig-core/

[83] [XML-SIG-XSD] XML Signature Schema available from http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd

[84] [XML-Enc] Donald Eastlake, Joseph Reagle, Takeshi Imamura, Blair Dillaway, Ed Simon, XML Encryption Syntax and Processing, World Wide Web Consortium, http://www.w3.org/TR/xmlenc-core/

[85] [XML-Schema1] H. S. Thompson, D. Beech, M. Maloney, N. Mendelsohn. XML Schema Part 1: Structures, W3C Working Draft 22 September 2000, http://www.w3.org/TR/2000/WD-xmlschema-1-20000922/, latest draft at http://www.w3.org/TR/xmlschema-1/

[86] [XML-Schema2] P. V. Biron, A. Malhotra, XML Schema Part 2: Datatypes; W3C Working Draft 22 September 2000, http://www.w3.org/TR/2000/WD-xmlschema-2-20000922/, latest draft at http://www.w3.org/TR/xmlschema-2/