Please refer to the errata for this document, which may include some normative corrections.
See also translations.
Copyright ©2005 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
[2]This document specifies protocol bindings with security characteristics for the XML Key Management Specification (XKMS).
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is a W3C Recommendation. It has been reviewed by W3C Members and other interested parties and has been endorsed by the Director. It is a stable document and may be used as reference material or cited as a normative reference from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.
This document has been produced by the XKMS Working Group (WG). The English version of this specification is the only normative version. Translations of this document may be available.
If you have any comments on this document, send them to [email protected], a mailing list with a public archive. An errata list for this edition is available.
This is Part 2 of the W3C Recommendation for the XML Key Management Specification (XKMS Version 2.0). This document covers different protocol bindings with security characteristics for the XML Key Management Specification. Part 1 of this specification covers the XKMS protocols and services. For background on this work, please see the XKMS Activity Statement.
This document is based on the XKMS Version 2.0 Bindings Proposed Recommendation of 2 May 2005. Feedback received during that review resulted in minor editorial changes. Evidence of interoperation between at least two implementations of this specification are documented in the Implementation Report. Changes to this document since the Proposed Recommendation version are detailed in Appendix C.
This document was produced under the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure. The Working Group maintains a public list of patent disclosures relevant to this document; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy.
[8]This specification uses XML Schemas [XML-schema] to describe the content model.
[9]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]:
[10]"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)"
[11]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."
[14]This document uses the terms defined in Section 1.2 of part one of this specification in the manner described therein.
[15]The remainder of this document describes the XML Key Information Service Specification and XML Key Registration Service Specification.
[16]Security enhancements MAY be required to control the following risks:
[17]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.
[18]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.
[19]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.
[20]An XKMS service SHOULD support Confidentiality by means of encryption.
[21]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:
[22]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.
[23]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.
[24]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.
[25]An XKMS service SHOULD support Message Request Authentication.
[26]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.
[27]Note that Message Response Authentication is considered separately from Response Replay Protection.
[28]An XKMS service SHOULD support Request Authentication.
[29]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.
[30]An XKMS service MAY support Persistent Authentication by means of a digital signature on the message.
[31]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).
[32]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:
[33]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.
[34]An XKMS service MAY provide protection against a Request Replay.
[35]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.
[36]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.
[37]An XKMS service SHOULD support protection against a Denial of Service attack.
[38]The following table summarizes the possible security requirements that an XKMS service deployment may be subject to:
Security Issue | Requirement | Comments |
---|---|---|
Confidentiality | Some | The information provided by an XKMS service may be confidential, the fact that a party has requested particular information from an XKMS service may allow confidential information to be deduced. Many XKMS applications do not require confidentiality however. |
Request Authentication | Some | A service only needs to authenticate a request for information if either the information is confidential or some form of charge is to be made for use of the service. |
Response Authentication | Most | An XKMS service that provides only a Location service for self authenticating key information such as Digital Certificates does not require authentication. |
Persistent Authentication | Some | Although some XKMS applications have a specific requirement to support Non-Repudiation, the ability to repudiate requests and responses is acceptable in many applications. |
Message Correspondence | All | The RequestId correspondence mechanism can only be used if the Request Authentication mechanism can be relied upon. Otherwise the Digest Mechanism should be used. |
Request Replay | Some | Request replay attacks are likely to only be a concern if the service charges on a per request basis or as a type of Denial of Service attack. |
Denial of Service | Most | Any service made available on a public network is likely to be subject to a Denial of Service attack. The risk of a Denial of Service attack is generally considered to be reduced on closed networks such as internal enterprise networks. |
[39]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.
[40]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..
Security Issue | Requirement | Comments |
---|---|---|
Confidentiality of Private Key | If Server Generated Key pairs used | If a Register service supports registration of server generated key pairs or key recovery strong encryption of the private key MUST be supported. |
Registration Request Authentication | Some | XKMS Registration services SHOULD support the authentication of registration requests for initial registration of a key binding. Registration requests for secondary registration of previously issued credentials (i.e. a signed key binding or a digital certificate) MAY be permitted without authentication. |
Registration Proof Of Possession | Some | XKMS Registration services SHOULD support the verification of Proof Of Possession in the initial registration of client generated keys. |
Authentication by Revocation Code | Some | The XKMS Revocation code is self authenticating. |
[41]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.
[42]XKMS 2.0 implementations MUST support the use of SOAP 1.2. For near term compatibility with existing tools and infrastructure, SOAP 1.1 MAY be used
[43]XKMS implementers shall use SOAP document style request-response messaging with the XKMS messages defined in Part 1 carried as literal Body element content. This is equivalent to associating the Body content with a SOAP 1.2 env:encodingStyle attribute that has the value http://www.w3.org/2003/05/soap-envelope/encoding/none.
[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/2003/05/soap-envelope"> <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/2003/05/soap-envelope"> <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" encoding="utf-8"?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Body> <LocateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="I8fc9f97052a34073312b22a69b3843b6" Service="http://www.example.org/XKMS" xmlns="http://www.w3.org/2002/03/xkms#"> <RespondWith>http://www.w3.org/2002/03/xkms#KeyName</RespondWith> <RespondWith>http://www.w3.org/2002/03/xkms#KeyValue</RespondWith> <RespondWith>http://www.w3.org/2002/03/xkms#X509Cert</RespondWith> <RespondWith>http://www.w3.org/2002/03/xkms#X509Chain</RespondWith> <RespondWith>http://www.w3.org/2002/03/xkms#PGPWeb</RespondWith> <RespondWith>http://www.w3.org/2002/03/xkms#PGP</RespondWith> <QueryKeyBinding> <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage> <UseKeyWith Application="urn:ietf:rfc:2440" Identifier="[email protected]" /> <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="[email protected]" /> </QueryKeyBinding> </LocateRequest> </env:Body> </env:Envelope>
[51]LocateResponse Message
<?xml version="1.0" encoding="utf-8"?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Body> <LocateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="I8ce3809ab23500015cc27704b7eb0912" Service="http://www.example.org/XKMS" ResultMajor="http://www.w3.org/2002/03/xkms#Success" RequestId="I8fc9f97052a34073312b22a69b3843b6" xmlns="http://www.w3.org/2002/03/xkms#"> <UnverifiedKeyBinding Id="I809ca03cf85b3cb466859694dbd0627d"> <ds:KeyInfo> <ds:KeyValue> <ds:RSAKeyValue> <ds:Modulus> 3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV7twNf2T UXCxYuztUUClMIy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreyn WegpFbITXc8V6Y02QfR5O7Pn1/10ElslaF/TF8MQGqYE8= </ds:Modulus> <ds:Exponent>AQAB</ds:Exponent> </ds:RSAKeyValue> </ds:KeyValue> <ds:X509Data> <ds:X509Certificate> MIICCTCCAXagAwIBAgIQe0Sk4xr1VolGFFNMkCx07TAJBgUrDgMCHQUAMBIxEDA OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj AkMSIwIAYDVQQDExlCb2IgQmFrZXIgTz1Cb2IgQ29ycCBDPVVTMIGfMA0GCSqGS Ib3DQEBAQUAA4GNADCBiQKBgQDcUW1ZSy8RqNC3ZJ5IX5G8DFZ08+HkZKVCenxI O++q8LATo9dxFasgaZXu3A1/ZNRcLFi7O1RQKUwjLXgHRD6TV6Pad6SZgvv4hzc MMZUVVpg+jFpFjRjaVXy06t7KdZ6CkVshNdzxXpjTZB9Hk7s+fX/XQSWyVoX9MX wxAapgTwIDAQABo1YwVDANBgNVHQoEBjAEAwIGQDBDBgNVHQEEPDA6gBABpU6Rp UssqgWYs3fukLy6oRQwEjEQMA4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUq D4e60DAJBgUrDgMCHQUAA4GBAF4jP1gGDbaq3rg/Vo3JY7EDNTp0HmwLiPMLmdn B3WTIGFcjS/jZFzRCbvKPeiPTZ6kRkGgydFOuCo5HMAxIks/LtnKFd/0qYT+AOD q/rCrwSx+F+Ro2rf9tPpja9o7gANqxs6Pm7f1QSPZO57bT/6afiVm7NdaCfjgMp hb+XNyn </ds:X509Certificate> <ds:X509Certificate> MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAMBIxEDA OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWj ASMRAwDgYDVQQDEwdUZXN0IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg QCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEkeXB8oMxwbhdcizWH92zrtm1V fVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVRNK5XmKXA5sE C51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBg NVHQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQM A4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GB ABDYD4Fwx2dscu+BgYcZ+GoQQtCJkwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsi QgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/MefuTtpOpCN40wy3YwwngD tHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435 </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage> <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage> <KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage> <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="[email protected]"/> </UnverifiedKeyBinding> </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.
[53]XKMS implementers using SOAP 1.1 messaging shall use request-response messaging and carry the XKMS messages as literal 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: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: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/).
[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. Such namespace promotion is generally undesirable if the XKMS message contains a digital signature as it may impact subsequent verification.
[60]XKMS messages that will be embedded in SOAP documents SHOULD be signed using the Exclusive XML Canonicalization algorithm [XML-EXC-C14N].
[61]Use of the XKMS SOAP binding does not affect processing of the XML Signature-based elements <KeyBindingAuthentication> and <ProofOfPossession>. These are computed as described in XKMS, sections 7.1.4 and 7.1.6 respectively, and the signature validation processing described in XKMS, section 3.1.2 Element <ds:Signature>." That is, the SOAP defined nodes and namespaces do not contribute to the Signature computation.
[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.
[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.
[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/2003/05/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>
[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].
[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://schemas.xmlsoap.org/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>
[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].
[71]This specification describes two principal security bindings each of which specifies two or more specific implementation profiles.
Feature | Payload Security | Transaction Layer Security |
---|---|---|
Dependencies | Authentication defined by XKMS specification, client does not need to implement a comprehensive framework | Authentication mechanism defined by TLS which clients must implement |
Use of XML Signature | Uses XML Signature in Enveloped Mode requiring slightly more complex processing | Not required |
Support for Routing | Specification describes bi-lateral authentication only, multi-hop message routing and multi-party transactions are not supported | None |
Support for Confidentiality | None, although applications may employ TLS to establish a secure channel | Supported |
Non-Repudiation | Supported | Requires additional payload security |
Unspecified Party Authentication | Supported | Requires additional payload security |
Client Authentication | Supported | Supported through certificate client authentication or through use of payload security |
[71b]In the following table, Request/Signature means that a XKMS Request
element includes a <dsig:Signature>
element in enveloped
mode. This signature is calculated using a digital signature method.
Request/MAC has similar meaning, except that the signature is calculated
using a Message Authentication Code (MAC).
Security Consideration | Client Authentication Mode | Support | Comment |
---|---|---|---|
Client Authentication Mechanism | No authentication mechanism is used. | None | |
Authentication using payload security | Payload | Request/Signature | |
Service Authentication Mechanism | Not Applicable | Payload | Response/Signature |
Request/Response Correspondence | Authentication using payload security | Payload | Message/RequestId |
Replay Attack Protection | Any | Payload | Message/Nonce in Two-phase protocol |
Denial Of Service Protection | Any | Payload | Request/RespondWith=Represent |
Non Repudiation | Any | Payload | Message/Signature with digital signature |
[72] The following payload security features are employed:
XKMS element.attribute name | Required |
---|---|
MessageAbstractType.Service | Required |
MessageAbstractType.Signature | Required in profile where client is authenticated using payload security for both Request and Response Messages |
ResultType.RequestId | Required |
PendingRequestType.ResponseId | Required |
MessageAbstractType.Nonce | Optional, may be used to protect against Denial of Service |
MessageAbstractType.RespondWith=Represent | Optional, may be used to protect against Denial of Service |
Request.Signature with MAC | Required in profile where no mechanism is used to authenticate the client, Optional in profile where client is authenticated using payload security |
[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 client authentication modes:
Security Consideration | Client Authentication Mode | Support | Comment |
---|---|---|---|
Client Authentication Mechanism | No authentication mechanism is used | None | |
TLS certificate based client authentication is used. | TLS | Certificate based client authentication | |
Authentication using Payload security | Payload | Request/Signature | |
Service Authentication Mechanism | Not applicable | TLS | |
Request/Response Correspondence | Any | TLS | Message/RequestId |
Replay Attack Protection | Any | TLS | Message/Nonce in Two-phase protocol |
Denial Of Service Protection | Any | None | TLS has no specific countermeasures against denial of service attacks |
Non Repudiation | Any | Payload | Message/Signature with digital signature [if required] |
[75] The following payload security features are employed:
XKMS element.attribute name | Required |
---|---|
MessageAbstractType.Service | Required, but not dependent |
MessageAbstractType.Signature | Optional, may be used to support non-repudiation for both Request and Response messages |
ResultType.RequestId | Required, but not dependent |
PendingRequestType.ResponseId | Required, but not dependent |
MessageAbstractType.Nonce | Unnecessary |
MessageAbstractType.RespondWith=Represent | Unnecessary |
[76] [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119.txt.
[77] [RFC2246] T. Dierks, C. Allen., The TLS Protocol Version, 1.0. IETF RFC 2246 January 1999. http://www.ietf.org/rfc/rfc2246.txt
[78] [RFC2693] C. Ellison et. al., Simple Public Key Infrastructure Certificate Theory, IETF RFC 2693, Sept. 1999. http://www.ietf.org/rfc/rfc2693.txt
[79] [RFC3280] R. Housley et. al., Public Key Infrastructure (X.509) (PKIX) Certificate and Certificate Revocation List (CRL) Profile, IETF RFC 3280, April 2002 ,http://www.ietf.org/rfc/rfc3280.txt
[80] [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/2000/NOTE-SOAP-20000508/
[81] [SOAP1.2-1] M. Gudgin, et al. SOAP Version 1.2 Part 1: Messaging Framework, W3C Recommendation 24 June 2003. http://www.w3.org/TR/2003/REC-soap12-part1-20030624/
[82] [SOAP1.2-2] M. Gudgin, et al. SOAP Version 1.2 Part 2: Adjuncts, W3C Recommendation 24 June 2003. http://www.w3.org/TR/2003/REC-soap12-part2-20030624/
[85] [XML-SIG] D. Eastlake, J. R., D. Solo, M. Bartel, J. Boyer , B. Fox , E. Simon. XML-Signature Syntax and Processing, W3C Recommendation. http://www.w3.org/TR/xmldsig-core/
[86] [XML-SIG-XSD] XML Signature Schema available from http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd
[86a] [XML-EXC-C14N] J. Boyer, D. E. Eastlake, J. Reagle. Exclusive XML Canonicalization. W3C Recommendation 8 July 2002. http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/
[87] [XML-Enc] D. Eastlake, J. Reagle, T. Imamura, B. Dillaway, E. Simon, XML Encryption Syntax and Processing, W3C Recommendation 10 December 2002. http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/
[88] [XML-NS] T. Bray, D. Hollander, A. Layman. Namespaces in XML. W3C Recommendation. January 1999. http://www.w3.org/TR/1999/REC-xml-names-19990114
[89] [XML-Schema1] H. S. Thompson, D. Beech, M. Maloney, N. Mendelsohn. XML Schema Part 1: Structures Second Edition, W3C Recommendation 28 October 2004. http://www.w3.org/TR/xmlschema-1/
[90] [XML-Schema2] P. V. Biron, A. Malhotra, XML Schema Part 2: Datatypes Second Edition; W3C Recommendation 28 October 2004. http://www.w3.org/TR/xmlschema-2/
[91]This specification is the work of the W3C XML Key Management Working Group. 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.
[92]Participants in the Working Group are (at the time of writing, and by alphabetical order): Guillermo Alvaro Rey (Trinity College Dublin), Stephen Farrell (Trinity College Dublin, Co-Chair), José Kahan (W3C, staff contact), Berin Lautenbach (Apache Software Foundation), Tommy Lindberg (Markup Security), Roland Lockhart (Entrust, Inc.), Vamsi Motukuru (Oracle Corp.), Shivaram Mysore (Co-Chair; Editor since 13 Apr 2004), Rich Salz (DataPower Technology, Inc.), Yunhao Zhang (SQLData Systems).
[93]Previous participants were (by alphabetical order): Daniel Ash (Identrus), Blair Dillaway (Microsoft), Donald Eastlake 3rd (Motorola), Yassir Elley (Sun Microsystems), Jeremy Epstein (webMethods), Slava Galperin (Sun Microsystems), Phillip Hallam-Baker (VeriSign Inc, Editor until 13 Apr 2004), 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, Joseph Reagle (W3C, previous staff contact), Dave Remy (GeoTrust, Inc.), Peter Rostin (RSA Security Inc.), Ed Simon (XMLsec Inc.)
[94]The authors also acknowledge the extensive assistance provided in the design stage of this specification by David Solo (CitiGroup) and Barbara Fox (Microsoft), and the contributions of (by alphabetical order) Dr. Paul Boisen (NSA), Alex Deacon, Dan Guinan, Marc Hayes, Jeremy Epstein (webMethods), Andrew Layman (Microsoft), Mingliang Pei (VeriSign).
This appendix documents changes (other than very minor editorial changes) from the Proposed Recommendation of 2 May 2005 that were made to accommodate the comments. Each entry contains: