[2]This document specifies protocols for
distributing and registering public keys, suitable for use in
conjunction with the proposed standard for XML Signature
[XML-SIG] developed by the World Wide Web Consortium (W3C) and
the Internet Engineering Task Force (IETF) and an anticipated
companion standard for XML encryption. The XML Key
Management Specification (XKMS) comprises two parts -- the
XML Key Information Service Specification (X-KISS) and the XML
Key Registration Service Specification (X-KRSS).
[3]This is an editors copy and has no
official status whatsoever.
[4] This is the third draft of the
"XML Key Management Specification (XKMS)" specification
from the XML Key
Management Working Group (Activity
Statement).
[5] This version attempts to capture
the consensus resulting from the December 9th 2001 face-to-face
meeting and subsequent discussion on the list. However, it does
contain points which are still under discussion or not well
specified. The Working Group will try to use a new namespace when
changes in its syntax or processing are substantive. However,
this namespace might be reused (prior to reaching Candidate
Recommendation) by subsequent drafts in such a way as to cause
instances using the namespace to become invalid or to change in
meaning or affect the operation of existing software. Requests
for a more stringent level of namespace stability should be made
to the Working Group.
[6] Publication of this document does
not imply endorsement by the W3C membership. This is a draft
document and may be updated, replaced or obsoleted by other
documents at any time. It is inappropriate to cite a W3C Working
Draft as anything other than a "work in progress." A
list of current W3C working drafts can be found at http://www.w3.org/TR/.
[7]Please send comments to the editor (<pbaker@verisign.com>)
and cc: the working group mailing list www-xkms@w3c.org (archive)
[8]Patent disclosures relevant to this
specification may be found on the Working Group's patent disclosure
page in conformance with W3C policy.
Table Of Contents
XML Key
Management Specification (XKMS 2.0) Part II: Protocol
Bindings
W3C Editors
Copy 17th October2002
Abstract
Status of
this document
Table Of
Contents
1
Introduction
1.1 Editorial
and Conformance Conventions
1.2
Definition of Terms
1.3 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 [TBS #54, 73]
4 Abstract
Protocol
4.1 All
Messages
4.2
Synchronous Request / Response
4.3
Asynchronous Processing
4.4 Two phase
Request / Response
4.5 Two Phase
Protocol with Asynchronous Processing
5 Security
Bindings
5.1 Payload
Authentication Binding
5.2 Secure
Socket Layer and Transaction Layer (SSL/TLS)Security
Binding
6
Acknowledgments
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 Definition of
Terms
[13]The following terms are used within this
document with the particular meaning indicated below:
[14] Service
   An application that provides
computational or informational resources on request. A service
may be provided by several physical servers operating as a
unit.
[15] Web service
   A service that is accessible by means
of messages sent using standard web protocols, notations and
naming conventions
[16] Client
   An application that makes requests of
a service. The concept of 'client' is relative to
a service request; an application may have the role of client for
some requests and service for others.
1.3 Structure of this
document
[17]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
[18]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
[19]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
[20]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.
[21]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.
[22]An XKMS service SHOULD support
Confidentiality by means of encryption.
[23]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 XTAML.
- A signing key obtained using some other retrieval mechanism
such as PKIX or SPKI.
[24]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
[25]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.
[26]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.
[27]An XKMS service SHOULD support Message
Request Authentication.
2.3 Response
Authentication
[28]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.
[29]Note that Message Response Authentication
is considered separately from Response Replay Protection.
[30]An XKMS service SHOULD support Request
Authentication.
2.4 Persistent
Authentication
[31]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.
[32]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)
[33]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).
[34]An XKMS service Must provide protection
against a Request Replay or Request Substitution attack.
[35]XKMS services may employ the following
mechanisms to protect against a Request Replay or Request
Substitution attack
[36]Â
[37]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.
- Non-authenticated Request
- If the original request was not authenticated the response
can still ensure a strong binding of the response to the original
request by including a message digest function of the request in
the response.
2.6 Request
Replay
[39]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.
[40]An XKMS service MAY provide protection
against a Request Replay.
2.7 Denial of
Service
[41]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.
[42]An XKMS service SHOULD support protection
against a Denial of Service attack.
2.8 Security
Requirements Summary
[43]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. |
[44]Where the security requirements of the
XKRSS protocol are stronger than those of XKISS they are addressed
by the XKRSS protocol directly rather than relying upon the message
security binding:
| 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. |
3 SOAP Binding [TBS
#54, 73]
4 Abstract
Protocol
[45]The XKMS protocol consists of pairs of
requests and responses. The XKMS protocol binding allows for the
case in which an additional request/response round trip is required
to support cases such as pending responses and 2 phase requests for
replay attack protection.
[46]Each XKMS response message contains a MajorResult code
that determines whether the response is final or further processing
is required. The protocol is specified in the CSP formalism [CSP] as follows:
- Final = { Success,
VersionMismatch, Sender, Receiver
}
- Â
- Request →
Result.Final
- |
- Request → Result.Pending→PendingNotification→Request→Result.Final
- |
- Request →
Result.Represent→Request→Result.Final
[47]The following sections summarize the
message processing steps taken by both parties in each of the
message
4.1 All Messages
[48]The following processing steps are taken
with respect to all messages regardless of whether they are a
request or a response:
- Generation
- ID is set to a randomly generated
unique value
- Service is set to the value of the
URI to which the XKMS request is directed
Authentication Signature is generated (if required).
- Processing
- The value of Service is
verified
The Authentication Signature value is verified (if
required)
<?xml version="1.0" encoding="utf-8"?>
<MessageAbstractType Id="1noOYHt5Lx7xUuizWZLOMw=="
Service="http://test.xmltrustcenter.org/XKMS"
xmlns="http://www.w3.org/2002/03/xkms#" />
4.2 Synchronous
Request / Response
- Requestor generation of the Request Message
- Nonce and OriginalRequestIDÂ are not
present
RespondWith values xkms:Represent and/or
xkms:Asynchronous MAY be specified
- Service processing of the Request Message
- Verify that request meets service authorization
policy
Process request to completion
- Service generation of the Response Message
- RequestID is set to the value of
Id in the request message
- Nonce is not present
MajorResult is set to a Final result
value.
- Requestor processing of the Response Message
- The value of RequestID is
verified
<?xml version="1.0" encoding="utf-8"?>
<LocateRequest Id="Id43fc15f6e942666a8adc7f142684fa7"
Service="http://test.xmltrustcenter.org/XKMS"
xmlns="http://www.w3.org/2002/03/xkms#">
<QueryKeyBinding />
</LocateRequest>
<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="I2dbaacaa120b8b6aed62aadf492654d6"
Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success"
RequestId="#Id43fc15f6e942666a8adc7f142684fa7"
xmlns="http://www.w3.org/2002/03/xkms#" />
4.3 Asynchronous
Processing
[49]Asynchronous processing consists of a
sequence of two request/response pairs, an initial request which
specifies the request values and a pending request which obtains
the result of the operation.
4.3.1 Initial
Request
[50]The initial request message is processed as
follows:
- Requestor generation of the Initial Request Message
- Nonce and OriginalRequestIDÂ are not
present
RespondWith value xkms:Asynchronous MUST be specified
- Service processing of the Initial Request Message
- Schedule request for asynchronous processing
- Service generation of the Initial Response Message
- RequestID is set to the value Id in the initial request message
- Nonce is not present
- MajorResult is set to Asynchronous
- Requestor processing of the Initial Response Message
- Register request as pending completion, wait for
notification.
4.3.2 Pending
Request
[51]On notification the client requests the
return of the result values by issuing a PendingRequest message as follows:
- Requestor generation of the Pending Request Message
- The request element is PendingRequest
- OriginalRequestID is set to the value
of Id in the initial request
message
ResponseID is set to value of Id in the initial response message
- Service processing of the Pending Request Message
- Match pending request to pending response
- Service generation of the Pending Response Message
- RequestID is set to the value of
Id in the Pending request
message
- Nonce is not present
- ResponseID is set to a randomly
generated unique value
- Requestor processing of the Pending Response Message
- If MajorResult is set to a
non-final value consider it to be xkms:failure
<?xml version="1.0" encoding="utf-8"?>
<LocateRequest Id="Iadc9f357a190a6fa6ec41bbc1f487e9f"
Service="http://test.xmltrustcenter.org/XKMS"
xmlns="http://www.w3.org/2002/03/xkms#">
<RespondWith>Pending</RespondWith>
<QueryKeyBinding />
</LocateRequest>
<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="Id0b7ad7dc569e5a7da247c5d8dcb4d1e"
Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Pending"
RequestId="#Iadc9f357a190a6fa6ec41bbc1f487e9f"
xmlns="http://www.w3.org/2002/03/xkms#" />
<?xml version="1.0" encoding="utf-8"?>
<ResultAbstractType xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns="http://www.w3.org/2002/03/xkms#" />
4.3.3.4 Pending
Request
<?xml version="1.0" encoding="utf-8"?>
<PendingRequest Id="I02dab31556512d021314587a87db2fc8"
Service="http://test.xmltrustcenter.org/XKMS"
OriginalRequestId="#Iadc9f357a190a6fa6ec41bbc1f487e9f"
xmlns="http://www.w3.org/2002/03/xkms#" />
<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="Ia617e870ad6e86d84e7eb13ba012b25a"
Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success"
RequestId="#Ic183b74a6d3ec0ab495f0d83774c16b7"
xmlns="http://www.w3.org/2002/03/xkms#" />
4.4 Two phase Request
/ Response
[52]An XKMS Service MAY require the use of a
two phase Request /.Response protocol to provide protection against
Request Replay attacks and/or denial of service attacks.
[53]In the first phase the requestor presents
the request and the service responds the MajorResult value Represent
and presents a nonce.
[54]In the second phase the requestor
represents the original request together with the nonce.
[55]The service can protect against replay
attacks by ensuring that it only responds to each nonce once. This
may be achieved in a computationally efficient manner by
appropriate construction of the nonce value. The actual
construction of the nonce value is outside the scope of this
specification and may be chosen as site specific circumstances
dictate.
[56]For example the nonce may be constructed
from the current time at the service, a unique serial number and a
Message Authentication Code computer computed over the preceding
items using a secret key known only to the service:
[57] nonce = time +
serial + M ( time + serial , k
)
[58]The service may limit the time interval in
which replay attacks are possible by rejecting nonce values that
specify an unacceptable time value or an incorrect MAC value.
[59]The service may prevent replay attacks
completely by tracking the serial numbers for which responses have
already been given.
[60]The processing steps specified for the
single phase case are performed with the following exceptions:
- Requestor generation of the Phase 1 Request Message
- RespondWith value xkms:Represent MUST be
specified
- Service processing of the Phase 1 Request Message
- Service decides to exercise option to require Two Phase
Processing
- Request is NOT processed
- Service generation of the Phase 1 Response Message
- RequestID is set to the value Id in the Phase 1 request message
- Nonce value is set in accordance with
service replay protection requirements
- MajorResult is set to Represent
- Requestor processing of the Phase 1 Response Message
- Proceed to phase 2
[61]The processing steps specified for the
single phase case are performed with the following exceptions:
- Requestor generation of the Phase 2 Request Message
- OriginalRequestIDÂ set to the
value of Id in the Phase 1 request
message
Nonce value is set to the value of Nonce in the Phase 1 response message
- Service processing of the Phase 2 Request Message
- Verify value of Nonce
- Verify that request meets service authorization
policy
Process request to completion
- Service generation of the Phase 2 Response Message
- RequestID is set to the value of
Id in the Phase2 request message
- Nonce is not present
MajorResult is set to a Final result
value
- Requestor processing of the Phase 2 Response Message
- If MajorResult set to a non-final
value consider to be failure
[62]Â
<?xml version="1.0" encoding="utf-8"?>
<LocateRequest Id="I524847b1df23a4fec4ab0d6eee401aa9"
Service="http://test.xmltrustcenter.org/XKMS"
xmlns="http://www.w3.org/2002/03/xkms#">
<RespondWith>Represent</RespondWith>
<QueryKeyBinding />
</LocateRequest>
<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="Ief7f690062e2d564f123e640f63e3c22"
Service="http://test.xmltrustcenter.org/XKMS" Nonce="efC+4OXXYfSXf2phz6FxHg=="
ResultMajor="Represent" RequestId="#I524847b1df23a4fec4ab0d6eee401aa9"
xmlns="http://www.w3.org/2002/03/xkms#" />
<?xml version="1.0" encoding="utf-8"?>
<LocateRequest Id="Ic183b74a6d3ec0ab495f0d83774c16b7"
Service="http://test.xmltrustcenter.org/XKMS" Nonce="efC+4OXXYfSXf2phz6FxHg=="
OriginalRequestId="#I524847b1df23a4fec4ab0d6eee401aa9"
xmlns="http://www.w3.org/2002/03/xkms#">
<QueryKeyBinding />
</LocateRequest>
<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="I2933751847d8fce2384e20010a1f62bb"
Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success"
RequestId="#Ic183b74a6d3ec0ab495f0d83774c16b7"
xmlns="http://www.w3.org/2002/03/xkms#" />
4.5 Two Phase Protocol
with Asynchronous Processing
[63]The Two Phase Protocol may be combined with
Asynchronous Processing. In this case the operation will consist of
three round trips as follows:
- Initial Request / Phase 1
- Initial Request / Phase 2
- Pending Response
[64]Message processing is performed as
described above with the following exceptions.
- OriginalRequestIDÂ set to that
value of Id in Initial Request /
Phase 1 in both subsequent requests.
- Nonce value is set to the value of
Nonce in Phase 1 response in both
subsequent requests.
4.5.1 Compound Request
[TBS]
5 Security
Bindings
[65]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.
| Â |
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. |
5.1 Payload
Authentication Binding
[66][TBS #87 Exclusive cannonicalization]
- 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
| Security Consideration |
Variant |
Support |
XKMS element |
| Client Authentication
Mechanism |
I |
None |
 |
| Â |
II |
Payload |
Request/Signature |
| Service Authentication
Mechanism |
 |
Payload |
Response/Signature |
| Request/Response
Correspondence |
I |
Payload |
Request/MessageDigest |
| Â |
II |
Payload |
Message/RequestID |
| Replay Attack Protection |
 |
Payload |
Message/Nonce |
| Denial Of Service Protection |
 |
Payload |
Request/RespondWith=Represent |
| Non Repudiation |
 |
Payload |
Message/Signature with digital signature |
[67]The following payload security features are
employed.
| XKMS element |
Required |
| Message/Service |
Required |
| Request/Signature |
Required in profile II |
| Response/Signature |
Required |
| Message/RequestID |
Required |
| Message/ResponseID |
Required |
| Message/Nonce |
Optional, may be used to protect against
Denial of Service |
| Request/RespondWith=Represent |
Optional, may be used to protect against
Denial of Service |
| Request/MessageDigest |
Required in profile I, Optional in profile
II |
5.2 Secure Socket
Layer and Transaction Layer (SSL/TLS)Security Binding
[68][TBS #77 cipher suites]
[69]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
| Security Consideration |
Variant |
Support |
XKMS element |
| Client Authentication
Mechanism |
I |
None |
 |
| Â |
II |
TLS |
Certificate based client authentication |
| Â |
II |
Payload |
Request/Signature |
| Service Authentication
Mechanism |
 |
TLS |
 |
| Request/Response
Correspondence |
 |
TLS |
 |
| Replay Attack Protection |
 |
TLS |
 |
| Denial Of Service
Protection |
 |
None |
The TLS service is subject to a denial of
service attack [Check this] |
| Non Repudiation |
 |
Payload |
Message/Signature with digital signature [if
required] |
[70]The following payload security features are
employed.
| XKMS element |
Required |
| Message/Service |
Required but not dependent |
| Request/Signature |
Optional, may be used to support
non-repudiation |
| Response/Signature |
Optional, may be used to support
non-repudiation |
| Message/RequestID |
Required but not dependent |
| Message/ResponseID |
Required but not dependent |
| Message/Nonce |
Unnecessary |
| Request/RespondWith=Represent |
Unnecessary |
| Request/MessageHash |
Unnecessary |
6 Acknowledgments
[71] [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/
[72] [RFC-2246] T. Dierks, C. Allen., The TLS Protocol
Version, 1.0. Â IETF RFC 2246 January 1999.
[73] [WSSL]
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
[74] [XTASS] P. Hallam-Baker, XML Trust Assertion
Service Specification, To Be Published, January 2001
[75] [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/
[76] [XML-SIG-XSD] XML Signature Schema available
from
http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/xmldsig-core-schema.xsd.
[77] [XML-Enc] XML Encryption Specification, In
development.
[78] [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/
[79] [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/
[80] [WS-Security] Â Â Â TBS
