XML Key Management Specification (XKMS 2.0)

Version 2.0

W3C Editor's Draft 30th March 2005 (Pre PR)

This version:: http://www.w3.org/2001/XKMS/Drafts/XKMS-PR-DRAFT/PR-DRAFT-xkms-part-1.html
Latest official published version:: http://www.w3.org/TR/xkms2/
Previous official published version:: http://www.w3.org/TR/2004/CR-xkms2-20040405/
Editors:: Phillip Hallam-Baker VeriSign, Shivaram H. Mysore
Contributors:: See the Acknowledgments.

Abstract

[2]This document specifies protocols for distributing and registering public keys, suitable for use in conjunction with the W3C Recommendations for XML Signature [XML-SIG] and XML Encryption [XML-Enc]. 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).

Status of this document

This is an editor's copy and has no official status whatsoever. The XHTML <del> tag is used to indicate previous text, where the <ins> tag indicates newly added (or modified) text.

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 theW3C technical reports indexat http://www.w3.org/TR/.

This is Part 1 of the W3C Candidate Recommendation for the XML Key Management Specification (XKMS Version 2.0), made available for public review by the XKMS Working Group. Part 2 of this specification covers different protocol bindings with security characteristics for XKMS. For background on this work, please see the XKMS Activity Statement.

Note that when first released on 18 April 2003, the XKMS specification consisted of two separate documents: XML Key Management Specification Version 2.0 and XML Key Management Specification Version 2.0 Bindings. In order to show their relationship, the Working Group decided to now refer to them as Part-1 and Part-2 of the XKMS Specification. This is just an Editorial modification and doesn't concern the content of those documents.

This document is based upon the XKMS Version 2.0 Candidate Recommendation of 05 April 2004 and feedback received during the candidate recommendation period (see the Disposition of Comments document). The XKMS Working Group believes that this specification addresses its Requirements and all of the Last Call issues.

The purpose of a W3C Candidate Recommendation is to gather implementation experience. The status of implementations will be tracked on the XKMS Implementation Report. The XKMS CR period will last a minimum of six months (1 October 2004) to ensure that enough time is given for providing implementation feedback. Note that the Conformance Section of this document may be improved following the experience gained during the CR period.

This document has been produced under the 24 January 2002 Current Patent Practice as amended by the W3C Patent Policy Transition Procedure. Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page. 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.

Comments on this document should be sent to public-xkms-comments@w3.org, a mailing list with a public archive. General discussion of related technology is welcome in www-xkms@w3.org (archive).

Publication as a Candidate Recommendation 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 this document as other than work in progress.

XML Key Management Specification (XKMS)

Version 2.0

W3C Working Draft 26th August 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 Versions Namespaces and Identifiers

1.5 Key Information Service Overview (Non-Normative)

1.6 Key Registration Service Overview (Non-Normative)

1.7 Structure of this document

2.4 Synchronous and Asynchronous Processing

2.5 Asynchronous Processing

2.6 Two Phase Request Protocol

2.7 Two Phase Protocol with Asynchronous Processing

2.8 Compound Requests and Responses

3.3 Response Messages

3.4 Compound Requests

3.5 Status Request

4 Key Information Service Description

4.1 XKISS Locate Service

4.2 XKISS: Validate Service

4.3 Using Locate and Validate

5 Key Information Service Message Set

5.1 Key Binding Specification

5.2 Locate Service

5.3 Validate Service

6 Key Registration Service Description

6.5 Request Authentication

7 Key Registration Service Message Set

8 Cryptographic Algorithm Specific Parameters

8.1 Use of Limited-Use Shared Secret Data

8.2 Private Key Parameters

9 Conformance

10 Security Considerations

10.1 Replay Attacks

10.2 Denial of Service

10.3 Recovery Policy

10.4 Security of Limited Use Shared Secret

10.5 Confidentiality of Opaque Client Data

10.6 Security of Not Bound Authentication Data

10.7 Signature Oracle

10.8 Privacy

10.9 Security of the Private Key

10.10 Message Length Disclosure Vulnerabilities

10.11 Check for Signature Value in a Signed SOAP Message

Appendix A Schemas

A.1 XKMS Schema

Appendix B Service Location Configuration

B.1 Domain Name Service (DNS)

Appendix C Sample Protocol Exchanges

C.1 Authentication Computation

C.2 Pass Phrase Computation

C.3 Private Key Parameters

Appendix D References

Appendix E Changes

1 Introduction

[8]This document specifies protocols for distributing and registering public keys, suitable for use in conjunction with the standard for XML Signatures [XML-SIG] defined by the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF) and companion standard for XML encryption [XML-ENC]. 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).

[9]These protocols do not require any particular underlying public key infrastructure (such as X.509) but are designed to be compatible with such infrastructures.

[10]This document defines the following service specifications:

XML Key Information Service Specification:: A protocol to support the delegation by an application to a service of the processing of key information associated with an XML signature, XML encryption, or other usage of the XML Signature [XML-SIG]<ds:KeyInfo> element.
XML Key Registration Service Specification:: A protocol to support the registration of a key pair by a key pair holder, with the intent that the key pair subsequently be usable in conjunction with the XML Key Information Service Specification or a Public Key Infrastructure (PKI) such as [X.509][PKIX].

1.1 Editorial and Conformance Conventions

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

[12]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]:

[13]"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)"

[14]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

[15]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

[16]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

[17]The following terms are used within this document with the particular meaning indicated below:

[18] Service
    An application that provides computational or informational resources on request. A service may be provided by several physical servers operating as a unit.

[19] Web service
    A service that is accessible by means of messages sent using standard web protocols, notations and naming conventions

[20] 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.4 Versions Namespaces and Identifiers

[21]No provision is made for an explicit version number in this syntax. If a future version is needed, it will use a different namespace. The XML namespace [XML-ns] URI that MUST be used by implementations of this (dated) specification is:

   http://www.w3.org/2002/03/xkms#

[22]This namespace is also used as the prefix for algorithm identifiers used by this specification. While applications MUST support XML and XML namespaces, the use of internal entities [XML] or the "xkms" XML namespace prefix and defaulting/scoping conventions are OPTIONAL; we use these facilities to provide compact and readable examples.

[23]In this document, certain namespace prefixes represent certain namespaces in the schema fragments (shown on a yellow background) as follows:

Prefix	Specification	Schema
	XML Schema	http://www.w3.org/2001/XMLSchema
ds	XML Signature	http://www.w3.org/2000/09/xmldsig#
xenc	XML Encryption	http://www.w3.org/2001/04/xmlenc#
ec	Exclusive Cannonicalization	http://www.w3.org/2001/10/xml-exc-c14n#
xkms	XKMS	http://www.w3.org/2002/03/xkms#

[24]For clarity, some examples of XML are not complete documents and namespace declarations may be omitted from XML fragments.

[25]In all examples (shown on a light blue background) and in the body of the text the default namespace refers to the xkms namespace itself. This means that namespace prefixes are omitted for all element names, type names and QNames in the xkms namespace. For example the QName xkms:Success is referred to using the local name part Success alone.

[26]These namespaces are declared in the XKMS schema as follows:

<?xml version="1.0"?>
<schema targetNamespace="http://www.w3.org/2002/03/xkms#"
      xmlns:xkms="http://www.w3.org/2002/03/xkms#"
      xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      xmlns="http://www.w3.org/2001/XMLSchema"
      elementFormDefault="qualified" attributeFormDefault="unqualified">
   <import namespace="http://www.w3.org/2000/09/xmldsig#"
         schemaLocation="xmldsig-core-schema.xsd"/>
   <import namespace="http://www.w3.org/2001/04/xmlenc#"
         schemaLocation="xenc-schema.xsd"/>
   <annotation>
      <documentation xml:lang="en">
              XML Schema for XKMS 2.0 Last Call Candidate 2003
      </documentation>
   </annotation>
   <!-- /Namespace -->

...

   <!-- End Schema -->
</schema>

[27]Internet Protocol addresses and Domain Name System names used in examples are purposely chosen to avoid confusion with assigned addresses and names. All Internet Protocol Addresses are in the reserved non-routable network 10.x.x.x. All DNS names are in the reserved domain example.com.

1.5 Key Information Service Overview (Non-Normative)

[28]X-KISS allows a client to delegate part or all of the tasks required to process XML Signature [XML-SIG]<ds:KeyInfo> elements to an XKMS service. A key objective of the protocol design is to minimize the complexity of applications using XML Signature [XML-SIG]. By becoming a client of the XKMS service, the application is relieved of the complexity and syntax of the underlying PKI used to establish trust relationships, which may be based upon a different specification such as X.509/PKIX, SPKI or PGP.

[29]By design, the XML Signature specification [XML-SIG] does not mandate use of a particular trust policy. The signer of a document is not required to include any key information but may include a <ds:KeyInfo> element that specifies the key itself, a key name, X.509 certificate, a PGP key identifier etc. Alternatively, a link may be provided to a location where the full <ds:KeyInfo> information may be found.

[30]The information provided by the signer may therefore be insufficient by itself to perform cryptographic verification and decide whether to trust the signing key, or the information may not be in a format the client can use. For example:

The key may be specified by a name only.
The local trust policy of the client may require additional information in order to trust the key.
The key may be encoded in an X.509 certificate that the client cannot parse.

[31]In the case of an encryption operation:

The client may not know the public key of the recipient.

1.6 Key Registration Service Overview (Non-Normative)

[32]X-KRSS describes a protocol for registration and subsequent management of public key information. A client of a conforming service may request that the registration service bind information to a public key. The information bound may include a name, an identifier or extended attributes defined by the implementation.

[33]The key pair to which the information is bound may be generated in advance by the client or on request generated by the service. The Registration protocol may also be used for subsequent management operations including recovery of the private key and reissue or revocation of the key binding.

[34]The protocol provides for authentication of the applicant and, in the case that the key pair is generated by the client, Proof of Possession (POP) of the private key. A means of communicating the private key to the client is provided in the case that the private key is generated by the registration service.

[35]This document specifies means of registering RSA and DSA keys and a framework for extending the protocol to support other cryptographic algorithms such as Diffie-Hellman and Elliptic Curve variants.

1.7 Structure of this document

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

Section 2: Protocol Exchanges: Features of the XKMS protocol that are common to the XKMS services are described
Section 3: Message Syntax: The common syntax elements shared by XKMS messages are described
Section 4: Key Information Service Specification Overview.: The functional behavior of the X-KISS service is described.
Section 5: Key Information Service Specification Message Set.: The semantics of the X-KISS protocol messages are defined.
Section 6: Key Registration Service Specification Overview.: The functional behavior of the X-KRSS service is described.
Section 7: Key Registration Service Specification Message Set.: The semantics of the X-KRSS protocol messages is defined.
Section 8: Cryptographic Algorithm Specific Parameters: Parameters and data formats specific to the use of particular cryptographic algorithms are defined.
Section 9: Conformance: Conformance criteria for compliant XKMS 2.0 applications are specified.
Section 10: Security Considerations: Security considerations for implementation and deployment of XKMS are described

2 Protocol Exchanges

[37]XKMS protocol exchanges consist of a sequence of either one or two request response pairs.

[38]XKMS protocol messages share a common format that may be carried within a variety of protocols. A binding to the SOAP [SOAP][XMLP] message protocol is provided in Part II: Protocol Bindings. It is recommended XKMS implementers support SOAP over HTTP for interoperability purposes. XKMS is transport protocol agnostic however and MAY be layered over any SOAP transport.

[39]Implementers MAY implement bindings to other protocols at their option.

[40]No XKMS operations are idempotent, that is all XKMS requests MAY cause a change of state.

[41] Part II of this specification describes the XKMS Security Protocol bindings.

[42]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.

[43]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

[44]The following sections describe the message protocol and the message processing steps taken by both parties in each of the messages.

2.1 All Messages

[45]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)

2.1.1Example

<?xml version="1.0" encoding="utf-8"?>
<MessageAbstractType Id="1noOYHt5Lx7xUuizWZLOMw=="
      Service="http://test.xmltrustcenter.org/XKMS""http://www.example.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#" />

2.2 Request Types

[46]The XKMS specification defines three types of request:

X-KISS Request: A Locate or Validate request as specified by the Key Information Service Specification
X-KRSS Request: A Register, Reissue, Revoke or Recover request as specified by the Key Registration Service Specification
Compound Request: A compound request consists of a set of one or more X-KISS or X-KRSS requests.

[47]The XKMS protocol supports a number of protocol options, including asynchronous processing, two-phase requests and compound requests. The client specifies the protocol options it supports in relation to a specific request through ResponseMechanism elements in the request.

[48]The means by which the service specifies protocol options which it accepts is outside the scope of this document. If the mechanism used for this purpose uses URI based identifiers for this purpose the following identifiers SHOULD be used:

Asynchronous Processing: http://www.w3.org/2002/03/xkms#Asynchronous
Two Phase Request Protocol: http://www.w3.org/2002/03/xkms#Represent
Compound Requests and Responses: http://www.w3.org/2002/03/xkms#Compound

2.3 Responses

[49]All XKMS responses contain a Result code comprised of a major and minor component. If a service applies a protocol processing option the client is informed by means of the MajorResult code value of the response.

2.4 Synchronous and Asynchronous Processing

[50]XKMS supports two processing modes, synchronous processing and asynchronous processing.

In synchronous processing the service responds to a request such that it has satisfied its obligation and will issue no more responses with respect to that request: a response code in the set Final defined above is returned.
In asynchronous processing the service will not complete the request immediately and notifies that the request is not yet satisfied and subsequent responses will be forthcoming: a response code that is not in the set Final is returned in intermediate responses.

[51]A client MAY advise a service that it will accept asynchronous processing of a request by specifying the ResponseMechanism value Pending. An XKMS service that receives a request that specifies the ResponseMechanism value Pending MAY respond either synchronously or asynchronously. If the service is to respond asynchronously it advises the client that the response value will be returned asynchronously by specifying the MajorResult code Pending.

[52]An XKMS service MUST NOT return the MajorResult code Pending unless the ResponseMechanism value Pending was specified in the corresponding request. If an XKMS service receives a request that cannot be processed synchronously and the ResponseMechanism value Pending is not specified the MajorResult code Receiver and MinorResult codeNotSynchronous are returned.

[53]Asynchronous processing MAY be used to allow administrator intervention during the processing of a request. For example an administrator might be required to verify and approve all XKRSS Registration requests before they are processed.

2.4.1 Synchronous Request / Response

[54]Processing of a synchronous Request and Response takes place as follows:

Requestor generation of the Request Message: Nonce and OriginalRequestId are not present
ResponseMechanism values Represent and/or Pending 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

2.4.2 Example

2.4.2.1 Request

<?xml version="1.0" encoding="utf-8"?>
<LocateRequest Id="I6d995b8d05a9a2ce0573d29e32ab9441"
      Service="http://test.xmltrustcenter.org/XKMS""http://www.example.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <QueryKeyBinding />
</LocateRequest>

2.4.2.2 Response

<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="I089b18dc1a520b26e2e6689dd3a5a820"
      Service="http://test.xmltrustcenter.org/XKMS"
      "http://www.example.org/XKMS"
      ResultMajor="http://www.w3.org/2002/03/xkms#Success"
      RequestId="I6d995b8d05a9a2ce0573d29e32ab9441"
      xmlns="http://www.w3.org/2002/03/xkms#" />

2.5 Asynchronous Processing

[55]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.

2.5.1Initial Request

[56]The initial request message is processed as follows:

Requestor generation of the Initial Request Message: Nonce and OriginalRequestId are not present
ResponseMechanism value Pending 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 Pending
Requestor processing of the Initial Response Message: Register request as pending completion, wait for notification.

2.5.2Pending Request

[57]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 failure

[58]The client MAY request the return of the result values before processing has been completed. In this case the service responds to the Pending Request with the MajorResult code Pending.

2.5.3Example

2.5.3.1Request

<?xml version="1.0" encoding="utf-8"?>
<LocateRequest Id="I6227979ae4073f2b3b145db7a488ce16"
      Service="http://test.xmltrustcenter.org/XKMS""http://www.example.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <ResponseMechanism>http://www.w3.org/2002/03/xkms#Pending</ResponseMechanism>
  <QueryKeyBinding />
</LocateRequest>

2.5.3.2 Response

<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="I98366e407a2a78dff79687dbdb4d974c"
      Service="http://test.xmltrustcenter.org/XKMS"
      "http://www.example.org/XKMS" 
      ResultMajor="http://www.w3.org/2002/03/xkms#Pending"
      RequestId="I6227979ae4073f2b3b145db7a488ce16"
      xmlns="http://www.w3.org/2002/03/xkms#" />

2.5.3.3 Notification

<?xml version="1.0" encoding="utf-8"?>
<Result 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#"/>

2.5.3.4 Pending Request

<?xml version="1.0" encoding="utf-8"?>
<PendingRequest Id="I6045ff8b2eb204edb538be1fa22e340a"
      Service="http://test.xmltrustcenter.org/XKMS"
      "http://www.example.org/XKMS"
      OriginalRequestId="I6227979ae4073f2b3b145db7a488ce16"
      ResponseId="I98366e407a2a78dff79687dbdb4d974c"
      xmlns="http://www.w3.org/2002/03/xkms#" />

2.5.3.5 Response

<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="I4da52fc78e0391a11257d64926cd184c"
      Service="http://test.xmltrustcenter.org/XKMS"
      "http://www.example.org/XKMS"
      ResultMajor="http://www.w3.org/2002/03/xkms#Success"
      RequestId="I6045ff8b2eb204edb538be1fa22e340a"
      xmlns="http://www.w3.org/2002/03/xkms#" />

2.6 Two Phase Request Protocol

[59]XKMS requests may employ a two phase request protocol to protect against a denial of service attack. The two phase request protocol allows the service to perform a lightweight authentication of the source of an XKMS request, specifically the service determines that the client is able to read messages sent to the purported source address. Although this mechanism provides only a weak form of authentication it prevents an attacker performing a Denial of Service attack by forcing the service to perform a resource intensive form of authentication such as the verification of a digital signature.

[60]The two-phase protocol consists of two phases as follows:

[61]In the first phase the requestor presents the request and the service responds the MajorResult value Represent and presents a nonce.

[62]In the second phase the requestor represents the original request together with the nonce.

[63]A client MAY advise a service that it supports the two phase request protocol by specifying the ResponseMechanism value Represent. An XKMS service advises the client that the use of the two phase request protocol is required by specifying the MajorResult code Represent.

[64]An XKMS service MUST NOT return the MajorResult code Represent unless the ResponseMechanism value Represent was specified in the corresponding request. If an XKMS service requires the use of the Two Phase Request protocol and the ResponseMechanism value Represent is not specified in the corresponding request the MajorResult code Sender and MinorResult codeRepresentRequiredare returned.

[65]The Two Phase request protocol bears some similarity to asynchronous request processing. Both mechanisms introduce an extra protocol round trip but each serve different purposes. The purpose of asynchronous processing is to allow a delay to be introduced between the initial request and the return of the result. In the two phase request protocol however there is no delay between the first request and the first response or between the first response and the second request. The purpose of the two phase request protocol is to allow a service to protect itself against a denial of service attack by allowing the service to perform a lightweight authentication of the source of the request.

[66]The service SHOULD verify that the nonce value specified in a second phase request was recently generated by the service. The service MAY verify that the nonce value has not been previously responded to. The actual construction of the nonce value is outside the scope of this specification and may be chosen as site specific circumstances dictate. The techniques described in the section Construction of Nonce Values describe a technique that reduces or avoids the need to maintain server state in order to meet this requirement.

2.6.1Processing Steps

[67]In the first phase of the two phase protocol the processing steps specified for the single phase case are performed with the following exceptions:

Requestor generation of the Phase 1 Request Message: ResponseMechanism value 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

[68]In the Second phase of the two phase protocol 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

2.6.2 Construction of Nonce Values

[69]Nonce values may be constructed in any manner that the service chooses. It may be useful to construct the nonce so as to permit the service to determine that they were generated by the server at a specific time in a computationally efficient manner as follows.

[70]The nonce is constructed from the current time at the service, a unique serial number and a secret key known only to the service using a Message Authentication Code as follows: ("+" indicates concatenation)

[71] nonce = time + serial + M ( time + serial , k )

[72]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.

[73]The service may prevent replay attacks completely by tracking the serial numbers for which responses have already been given, using the nonce time construction value to limit the interval over which the serial number is tracked.

[74]The nonce value may be encrypted to avoid leaking information such as the serial number value which might be of interest to an attacker.

2.6.3 Example

2.6.3.1 Request 1

<?xml version="1.0" encoding="utf-8"?>
<LocateRequest Id="Ia1d6ca7a067fdd545f1a1396d2f26779"
      Service="http://test.xmltrustcenter.org/XKMS""http://www.example.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <ResponseMechanism>http://www.w3.org/2002/03/xkms#Represent</ResponseMechanism>
  <QueryKeyBinding />
</LocateRequest>

2.6.3.2Response 1

<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="Idbc77142059a3a51c9eccd2425d77757"
      Service="http://test.xmltrustcenter.org/XKMS""http://www.example.org/XKMS"
      Nonce="Rj2BoUZM7PisPX2ytSAAWA==" 
      ResultMajor="http://www.w3.org/2002/03/xkms#Represent"
      RequestId="Ia1d6ca7a067fdd545f1a1396d2f26779"
      xmlns="http://www.w3.org/2002/03/xkms#" />

2.6.3.3 Request 2

<?xml version="1.0" encoding="utf-8"?>
<LocateRequest Id="I47804adaec32e34afeecdb51f3e0f765"
      Service="http://test.xmltrustcenter.org/XKMS""http://www.example.org/XKMS"
      Nonce="Rj2BoUZM7PisPX2ytSAAWA=="
      OriginalRequestId="Ia1d6ca7a067fdd545f1a1396d2f26779"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <QueryKeyBinding />
</LocateRequest>

2.6.3.4 Response 2

<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="I3b0111d2232507a56444c1bc85409a94"
      Service="http://test.xmltrustcenter.org/XKMS"
      "http://www.example.org/XKMS"
      ResultMajor="http://www.w3.org/2002/03/xkms#Success"
      RequestId="I47804adaec32e34afeecdb51f3e0f765"
      xmlns="http://www.w3.org/2002/03/xkms#" />

2.7 Two Phase Protocol with Asynchronous Processing

[75]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

[76]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.

2.8 Compound Requests and Responses

[77]An XKMS service MAY support processing of Compound Requests. A compound request permits multiple XKMS requests to be made at the same time. A compound request consists of an outer request and one or more inner requests. There is no ordering implicit in the inner requests. The semantics of making a set of requests as a compound request are exactly the same as if each individual request in the set had been made separately and simultaneously.

[78]The response to a compound request is a compound response. A compound response consists of an outer response and zero or more inner responses. If the ResultMajor value of the outer response is Success the compound response SHOULD contain an inner response response element corresponding to each inner request element of the compound request. If the the ResultMajor value of the outer response is not Success the response MUST NOT contain any inner responses. If a compound response has an outer ResultMajor value Success but does not contain a response corresponding to an inner request the ResultMajor value failure is assumed for that inner request.

[79]An XKMS service MAY support the use of the two phase protocol on the outer request of a compound response. The two phase protocol SHOULD NOT be used on an inner response. If an inner request specifies the ResponseMechanism value Represent the value SHOULD be ignored.

[80]An XKMS service MAY support the use of asynchronous processing in conjunction with a compound request. Asynchronous processing MAY be performed on the compound request as a whole, on individual inner requests or both.

[81]If asynchronous processing is to be performed on the compound request as a whole the outer request specifies the ResponseMechanism value Pending. If the service decides to return an asynchronous response a compound response is returned with a ResultMajor code of Pending. After the appropriate notification has taken place the client issues a PendingRequest message for the outer request to which the service replies with a compound response returning either the inner responses corresponding to the original inner requests or an error report.

[82]If asynchronous processing is performed on the individual inner requests each inner request for which an asynchronous response is to be accepted specifies the ResponseMechanism value Pending. If the service decides to return an asynchronous response to an inner request a compound response is returned with an outer ResultMajor code of Success and and inner ResultMajor code of Pending for the requests for which an asynchronous response is to be issued. A service MAY return synchronous and asynchronous responses in a single compound response.

[83]Since the semantics of a compound request are exactly the same as if each inner request were made separately a client MAY issue separate pending requests to obtain the results of the inner requests of a previous compound request. ~~Alternatively a client MAY issue a compound request containing multiple inner pending requests corresponding to requests which were originally made independently.~~

2.8.1Example

2.8.1.1Request 1

<?xml version="1.0" encoding="utf-8"?>
<CompoundRequest Id="I264f5da49b1ff367d4e7aef1f7a1df1a"
      Service="http://test.xmltrustcenter.org/XKMS""http://www.example.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <LocateRequest Id="I8c26be5f1b4dd228b43fb6eaee285faa"
        Service="http://test.xmltrustcenter.org/XKMS""http://www.example.org/XKMS">
    <RespondWith>KeyValue</RespondWith>
    <QueryKeyBinding>
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <X509Data>
          <X509Certificate>MIICEDCCAX2gAwIBAgIQimXeUAxYJbJMady9vV1bLjAJBgUrDg
                MCHQUAMBIxEDAOBgNVBAMTB1Rl
c3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5WjArMSkwJwYDVQQDEyBBbGljZSBB
YXJkdmFyayBPPUFsaWNlIENvcnAgQz1VUzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0nIs
mR+aVW2egl5MIfOKy4HuMKkk9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgGthO6U9D
0CNT5mbmhIAErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQggP
BLc1XagW20RMvokCAwEAAaNWMFQwDQYDVR0KBAYwBAMCBkAwQwYDVR0BBDwwOoAQAaVOkaVLLKoF
mLN37pC8uqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEC4MndUXjPG1TZxVKg+HutAwCQYFKw4DAh0F
AAOBgQABU91ka7IlkXCfv4Zh2Ohwgg2yObtY3+6C/BTFGrOEBJDy+DoxJ/NuBF18w3rrrR18xE6j
NKYLCQb8zUGk4QOG5Y+HT/QTTFvWkiOLXcpTuhnOhXatr42FoYpDkjx2QWK+J5Q2l/Rgjgc/0ZV8
U/kD8UuRkXp4AZh7QsiX8AcO0w==</X509Certificate>
        </X509Data>
      </KeyInfo>
      <KeyUsage>Signature</KeyUsage>
    </QueryKeyBinding>
  </LocateRequest>
  <LocateRequest Id="If8e63d729384ad35498e7b65b3dc785e"
        Service="http://test.xmltrustcenter.org/XKMS""http://www.example.org/XKMS">
    <RespondWith>KeyName</RespondWith>
    <RespondWith>KeyValue</RespondWith>
    <RespondWith>X509Cert</RespondWith>
    <RespondWith>X509Chain</RespondWith>
    <RespondWith>PGPWeb</RespondWith>
    <RespondWith>PGP</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>
</CompoundRequest>
<?xml version="1.0" encoding="utf-8"?>
<CompoundRequest Id="I264f5da49b1ff367d4e7aef1f7a1df1a"
      Service="http://test.xmltrustcenter.org/XKMS"http://www.example.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <LocateRequest Id="I8c26be5f1b4dd228b43fb6eaee285faa"
        Service="http://test.xmltrustcenter.org/XKMShttp://www.example.org/XKMS">
    <RespondWith>http://www.w3.org/2002/03/xkms#KeyValue</RespondWith>
    <QueryKeyBinding>
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <X509Data>
          <X509Certificate>
            MIICEDCCAX2gAwIBAgIQimXeUAxYJbJMady9vV1bLjAJBgUrDgMCHQUAMBIxEDA
            OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj
            ArMSkwJwYDVQQDEyBBbGljZSBBYXJkdmFyayBPPUFsaWNlIENvcnAgQz1VUzCBn
            zANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0nIsmR+aVW2egl5MIfOKy4HuMKkk
            9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgGthO6U9D0CNT5mbmhIA
            ErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQg
            gPBLc1XagW20RMvokCAwEAAaNWMFQwDQYDVR0KBAYwBAMCBkAwQwYDVR0BBDwwO
            oAQAaVOkaVLLKoFmLN37pC8uqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEC4MndUX
            jPG1TZxVKg+HutAwCQYFKw4DAh0FAAOBgQABU91ka7IlkXCfv4Zh2Ohwgg2yObt
            Y3+6C/BTFGrOEBJDy+DoxJ/NuBF18w3rrrR18xE6jNKYLCQb8zUGk4QOG5Y+HT/
            QTTFvWkiOLXcpTuhnOhXatr42FoYpDkjx2QWK+J5Q2l/Rgjgc/0ZV8U/kD8UuRk
            Xp4AZh7QsiX8AcO0w==
          </X509Certificate>
        </X509Data>
      </KeyInfo>
      <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
    </QueryKeyBinding>
  </LocateRequest>
  <LocateRequest Id="If8e63d729384ad35498e7b65b3dc785e"
        Service="http://test.xmltrustcenter.org/XKMShttp://www.example.org/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="bob@example.com" />
      <UseKeyWith Application="urn:ietf:rfc:2633"
            Identifier="bob@example.com" />
    </QueryKeyBinding>
  </LocateRequest>
</CompoundRequest>

2.8.1.2Response 1

<?xml version="1.0" encoding="utf-8"?>
<CompoundResult Id="If2d286d4a542bd92989aa606d9f1a5ca"
      Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success"
      RequestId="I264f5da49b1ff367d4e7aef1f7a1df1a"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <LocateResult Id="I69044d458e0bceef5f78c79c32fa9ddf"
        Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success"
        RequestId="I8c26be5f1b4dd228b43fb6eaee285faa">
    <UnverifiedKeyBinding Id="I8f7367375ac134872eab7acf42a8d1bd">
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <KeyValue>
          <RSAKeyValue>
            <Modulus>0nIsmR+aVW2egl5MIfOKy4HuMKkk9AZ/IQuDLVPlhzOfgngjVQCjr8uv
                  mnqtNu8HBupui8LgGthO
6U9D0CNT5mbmhIAErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVD
QggPBLc1XagW20RMvok=</Modulus>
            <Exponent>AQAB</Exponent>
          </RSAKeyValue>
        </KeyValue>
      </KeyInfo>
      <KeyUsage>Signature</KeyUsage>
      <KeyUsage>Encryption</KeyUsage>
      <KeyUsage>Exchange</KeyUsage>
      <UseKeyWith Application="urn:ietf:rfc:2633"
            Identifier="alice@alicecorp.test" />
    </UnverifiedKeyBinding>
  </LocateResult>
  <LocateResult Id="Ic3d02a8b1f63ba694a8fad11a74fb499"
        Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success"
        RequestId="If8e63d729384ad35498e7b65b3dc785e">
    <UnverifiedKeyBinding Id="I42604b6f40f46b74b5c30077100fe8e9">
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <KeyValue>
          <RSAKeyValue>
            <Modulus>3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV
                  7twNf2TUXCxYuztUUClM
Iy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreynWegpFbITXc8V6Y02QfR5O7Pn1/
10ElslaF/TF8MQGqYE8=</Modulus>
            <Exponent>AQAB</Exponent>
          </RSAKeyValue>
        </KeyValue>
        <X509Data>
          <X509Certificate>MIICCTCCAXagAwIBAgIQe0Sk4xr1VolGFFNMkCx07TAJBgUrDg
                MCHQUAMBIxEDAOBgNVBAMTB1Rl
c3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5WjAkMSIwIAYDVQQDExlCb2IgQmFr
ZXIgTz1Cb2IgQ29ycCBDPVVTMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDcUW1ZSy8RqNC3
ZJ5IX5G8DFZ08+HkZKVCenxIO++q8LATo9dxFasgaZXu3A1/ZNRcLFi7O1RQKUwjLXgHRD6TV6Pa
d6SZgvv4hzcMMZUVVpg+jFpFjRjaVXy06t7KdZ6CkVshNdzxXpjTZB9Hk7s+fX/XQSWyVoX9MXwx
AapgTwIDAQABo1YwVDANBgNVHQoEBjAEAwIGQDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6
oRQwEjEQMA4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GBAF4j
P1gGDbaq3rg/Vo3JY7EDNTp0HmwLiPMLmdnB3WTIGFcjS/jZFzRCbvKPeiPTZ6kRkGgydFOuCo5H
MAxIks/LtnKFd/0qYT+AODq/rCrwSx+F+Ro2rf9tPpja9o7gANqxs6Pm7f1QSPZO57bT/6afiVm7
NdaCfjgMphb+XNyn</X509Certificate>
          <X509Certificate>MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDg
                MCHQUAMBIxEDAOBgNVBAMTB1Rl
c3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWjASMRAwDgYDVQQDEwdUZXN0IENB
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEk
eXB8oMxwbhdcizWH92zrtm1VfVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVR
NK5XmKXA5sEC51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBgNV
HQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQMA4GA1UEAxMHVGVz
dCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GBABDYD4Fwx2dscu+BgYcZ+GoQQtCJ
kwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsiQgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/
MefuTtpOpCN40wy3YwwngDtHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435</X509Cer
      tificate>
        </X509Data>
      </KeyInfo>
      <KeyUsage>Signature</KeyUsage>
      <KeyUsage>Encryption</KeyUsage>
      <KeyUsage>Exchange</KeyUsage>
      <UseKeyWith Application="urn:ietf:rfc:2633"
            Identifier="bob@bobcorp.test" />
    </UnverifiedKeyBinding>
  </LocateResult>
</CompoundResult>
<?xml version="1.0" encoding="utf-8"?>
<CompoundResult Id="If2d286d4a542bd92989aa606d9f1a5ca"
      Service="http://test.xmltrustcenter.org/XKMShttp://www.example.org/XKMS"
      ResultMajor="http://www.w3.org/2002/03/xkms#Success"
      RequestId="I264f5da49b1ff367d4e7aef1f7a1df1a"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <LocateResult Id="I69044d458e0bceef5f78c79c32fa9ddf"
        Service="http://test.xmltrustcenter.org/XKMS"
        ResultMajor="http://www.w3.org/2002/03/xkms#Success"
        RequestId="I8c26be5f1b4dd228b43fb6eaee285faa">
    <UnverifiedKeyBinding Id="I8f7367375ac134872eab7acf42a8d1bd">
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <KeyValue>
          <RSAKeyValue>
            <Modulus>
              0nIsmR+aVW2egl5MIfOKy4HuMKkk9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgG
              thO6U9D0CNT5mbmhIAErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GD
              NiHKVDQggPBLc1XagW20RMvok=
            </Modulus>
            <Exponent>AQAB</Exponent>
          </RSAKeyValue>
        </KeyValue>
      </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="alice@example.com" />
    </UnverifiedKeyBinding>
  </LocateResult>
  <LocateResult Id="Ic3d02a8b1f63ba694a8fad11a74fb499"
        Service="http://test.xmltrustcenter.org/XKMShttp://www.example.org/XKMS"
        ResultMajor="http://www.w3.org/2002/03/xkms#Success"
        RequestId="If8e63d729384ad35498e7b65b3dc785e">
    <UnverifiedKeyBinding Id="I42604b6f40f46b74b5c30077100fe8e9">
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <KeyValue>
          <RSAKeyValue>
            <Modulus>
              3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV7twNf2T
              UXCxYuztUUClMIy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreyn
              WegpFbITXc8V6Y02QfR5O7Pn1/10ElslaF/TF8MQGqYE8=
            </Modulus>
            <Exponent>AQAB</Exponent>
          </RSAKeyValue>
        </KeyValue>
        <X509Data>
          <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
          </X509Certificate>
          <X509Certificate>
            MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAMBIxEDA
            OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWj
            ASMRAwDgYDVQQDEwdUZXN0IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg
            QCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEkeXB8oMxwbhdcizWH92zrtm1V
            fVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVRNK5XmKXA5sE
            C51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBg
            NVHQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQM
            A4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GB
            ABDYD4Fwx2dscu+BgYcZ+GoQQtCJkwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsi
            QgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/MefuTtpOpCN40wy3YwwngD
            tHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435
          </X509Certificate>
        </X509Data>
      </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="bob@example.com" />
    </UnverifiedKeyBinding>
  </LocateResult>
</CompoundResult>

2.9 Security Binding

[84]The security concerns that an XKMS service is required to address are dependent on the specific service deployment. For example a free XKMS Location service may not require controls for Request Authentication or to prevent Request Replay attacks while a paid Validate service might. The application of security enhancements is addressed in Part II which describes the application of the following security enhancements:

Confidentiality
Request Authentication
Response Authentication
Transitive Authentication
Response Replay
Request Substitution
Request Replay
Denial of Service

[85]The use of security enhancements is further discussed in the section Security Considerations below.

3Message Syntax

3.1Message Base

3.1.1 Type MessageAbstractType

[86]The MessageAbstractType abstract type is the type from which all XKMS message element types are derived. The MessageAbstractType abstract type contains the following element and attributes

<ds:Signature> [Optional]

An XML Signature [XML-SIG] in enveloped mode. The scope of the signature is the entire request message (i.e. the element derived from MessageAbstractType) and is specified using a reference to the Id attribute specified in the MessageAbstractType abstract type.

<MessageExtension> [Any Number]

An extension element derived from the MessageExtensionAbstractType.

<OpaqueClientData>[Optional]

A collection of dData specified by the client that is opaque to the service. An XKMS service SHOULD return the value of the <OpaqueClientData> element unmodified in a request in a response with status code Success.

Id [Required]

A unique identifier generated by the originator.

Service [Required]

The URI of the Web Service port to which the request is addressed

Nonce [Optional]

Cryptographically random data used to defend against replay attack.

[87]The following schema defines the MessageAbstractType abstract type:

   <!-- MessageAbstractType -->
   <complexType name="MessageAbstractType" abstract="true">
      <sequence>
         <element ref="ds:Signature" minOccurs="0"/>
         <element ref="xkms:MessageExtension" minOccurs="0"
               maxOccurs="unbounded"/>
         <element ref="xkms:OpaqueClientData" minOccurs="0"/>
      </sequence>
      <attribute name="Id" type="ID" use="required"/>
      <attribute name="Service" type="anyURI" use="required"/>
      <attribute name="Nonce" type="base64Binary" use="optional"/>
   </complexType>
   <!-- /MessageAbstractType -->

3.1.2 Element <ds:Signature>

[88]An XML Signature [XML-SIG] in enveloped mode. The scope of the signature is the entire request message (i.e. the element derrived from MessageAbstractType) and is specified using a reference to the Id attribute specified in the MessageAbstractType abstract type. The empty identifier "" MUST NOT be used.

[89]Validation of XML Signatures MUST be done independent of any ancestral XML context of the message. This may be achieved by:

Isolating the XKMS message from any 'wrapper' (eg. SOAP) before validation, or;
Specifying a canonicalization algorithm, such as Exclusive XML Canonicalization, in <SignedInfo>:<CanonicalizationMethod> to exclude ancestral XML context during the validation of the message.

[90]For interoperability purposes XKMS implementations MUST support the use of Exclusive XML Canonicalization.

[91]The <ds:Signature> element is specified in the XML Signature specification [XML-SIG].

3.1.3 Element <MessageExtension>

[92]The <MessageExtension> element is an abstract element of the abstract type MessageExtensionAbstractType. Implementations may define subclasses of the MessageExtensionAbstractType to define message extension elements that may be applied to any XKMS message.

[93]The following schema defines the MessageExtension element:

   <!-- MessageExtension -->
   <element name="MessageExtension" type="xkms:MessageExtensionAbstractType"
         abstract="true"/>
   <complexType name="MessageExtensionAbstractType" abstract="true"/>
   <!-- /MessageExtension -->

3.1.4 Element <OpaqueClientData>

[94]The <OpaqueClientData> contains data specified by the client that is opaque to the service. An XKMS service SHOULD return the value of an <OpaqueClientData> element, including its children, specified in a request unmodified in the corresponding response.

[95]A client MAY use Opaque client data in conjunction with asynchronous request processing to match a responses to the original request context. Opaque client data MAY also be used in conjunction with synchronous request processing to provide context information for purposes such as audit trail reconciliation.

[96]The following schema defines the OpaqueClientData element:

   <!-- OpaqueClientData -->
   <element name="OpaqueClientData" type="xkms:OpaqueClientDataType"/>
   <complexType name="OpaqueClientDataType">
      <sequence maxOccurs="unbounded">
         <element ref="xkms:OpaqueData" minOccurs="0"/>
      </sequence>
   </complexType>
   <element name="OpaqueData" type="base64Binary"/>
   <!-- /OpaqueClientData -->

3.2Request Message

3.2.1 Type RequestAbstractType

[97]The RequestAbstractType abstract type is the type from which all XKMS request element types are derived. The RequestAbstractType abstract type inherits the element and attributes of the MessageAbstractType abstract type and in addition contains the following elements andattributes

<ResponseMechanism> [Any Number]

Specifies the extended protocol mechanisms that the client supports in connection with this request.

<RespondWith> [Any Number]

Specifies the types of data the recipient requests to be sent in the response.

<PendingNotification> [Optional]

Specifies a means by which the service may notify the requestor of the completion of a pending response. If the <PendingNotification> element is present the value Pending MUST be specified as a <ResponseMechanism> value.

OriginalRequestId [Optional]

Specifies the valueId of the first request made in a multi-stage protocol such as the asynchronous processing mechanism or Two Phase protocol.

ResponseLimit [Optional]

Specifies the maximum number of data items the requestor can accept in the case that the schema specifies an unbounded number of elements.

[98]The following schema defines the RequestAbstractType abstract type:

   <!-- RequestAbstractType -->
   <complexType name="RequestAbstractType" abstract="true">
      <complexContent>
         <extension base="xkms:MessageAbstractType">
            <sequence>
               <element ref="xkms:ResponseMechanism" minOccurs="0"
                     maxOccurs="unbounded"/>
               <element ref="xkms:RespondWith" minOccurs="0"
                     maxOccurs="unbounded"/>
               <element ref="xkms:PendingNotification" minOccurs="0"/>
            </sequence>
            <attribute name="OriginalRequestId" type="NCName"
                  use="optional"/>
            <attribute name="ResponseLimit" type="integer" use="optional"/>
         </extension>
      </complexContent>
   </complexType>
   <!-- /RequestAbstractType -->

3.2.2 Element <ResponseMechanism>

[99]The <ResponseMechanism> element in the request specifies one or more strings included in the request that specify extended protocol mechanisms that the client supports in connection with a request.

[100] ResponseMechanismvalues are specified as anyURIs ~~QNames~~, the following identifiers are defined:

~~QName Local~~ anyURI Name	Description
http://www.w3.org/2002/03/xkms#Pending	The requestor is prepared to accept a response that uses asynchronous processing, i.e. the service MAY return the MajorResult code Pending
http://www.w3.org/2002/03/xkms#Represent	The requestor is prepared to accept a response that uses the two phase protocol, i.e. the service MAY return the MajorResult code Represent
http://www.w3.org/2002/03/xkms#RequestSignatureValue	The requestor is prepared to accept a response that carries a <RequestSignatureValue> element.

[101]The following schema defines the <ResponseMechanism> element::

   <!-- ResponseMechanism -->
   <element name="ResponseMechanism" type="QName"/>
   <!-- /ResponseMechanism -->

<!-- ResponseMechanism -->
        <simpleType name="ResponseMechanismEnum">
          <restriction base="anyURI">
            <enumeration value="http://www.w3.org/2002/03/xkms#Pending"/>
            <enumeration value="http://www.w3.org/2002/03/xkms#Represent"/>
            <enumeration value="http://www.w3.org/2002/03/xkms#RequestSignatureValue"/>
          </restriction>
        </simpleType>
        <simpleType name="ResponseMechanismOpenEnum">
          <union memberTypes="xkms:ResponseMechanismEnum anyURI"/>
        </simpleType>
<element name="ResponseMechanism" type="xkms:ResponseMechanismOpenEnum"/>
<!-- /ResponseMechanism -->

3.2.3 Element <RespondWith>

[102]The <RespondWith> element in the request specifies one or more strings included in the request that specify data elements to be provided in the <ds:Keyinfo> element of the response. Each string is a single identifier corresponding to a sub-element of the XML Signature Specification [XML-SIG]<ds:Keyinfo> element or the private key information defined in the section Cryptographic Algorithm Specific Parameters below. The XML Signature elements are described here for convenience. The normative reference is the specification [XML-SIG].

[103]The Service SHOULD return a requested data element if it is available. The Service MAY return additional data elements that were not requested. In particular, the service MAY return data elements specified in the request with the response.

[104] RespondWith values are specified as anyURIs ~~QNames~~, the following identifiers are defined:

~~QName Local~~ anyURIName(all names prefixed with URI`http://www.w3.org/2002/03/xkms#`)	<ds:Keyinfo> Element	Description
KeyName	<ds:KeyName>	Key name
KeyValue	<ds:KeyValue>	Public key parameters
X509Cert	<ds:X509Data>	X509 Certificate v3 that authenticates the specified key
X509Chain	<ds:X509Data>*	X509 Certificate v3 chain that authenticates the specified key. Note that no ordering is implied in the returned certificatesa.
X509CRL	<ds:X509Data>	X509 Certificate Revocation List v2
~~>OCSP~~	~~<ds:X509Data>~~	PKIX OCSP token that validates an X509v3 certificate that authenticates the key. A new ds:X509DataType element of type base64Binary value is expected in the response value of `<ds:X509Data>`.
RetrievalMethod	<ds:RetrievalMethod>	Retrieval Method data
PGP	<ds:PGPData>	PGP key signing data
PGPWeb	<ds:PGPData>*	Collection of PGP key signing data
SPKI	<ds:SPKIData>*	SPKI key signing
PrivateKey		Request that the encrypted private key be returned in the response. [Used in the X-KRSS protocol]

[105]For example, a client that has no X.509 processing capability might perform a Locate operation to obtain the public key parameters and name information from a <ds:Keyinfo> element that specifies only a certificate. The RespondWith element values in this case would be KeyName and KeyValue.

[106]The following schema defines the <RespondWith> element::

   <!-- RespondWith -->
   <element name="RespondWith" type="QName"/>
   <!-- /RespondWith -->

<!-- RespondWith -->
        <simpleType name="RespondWithEnum">
                <restriction base="anyURI">
                        <enumeration value="http://www.w3.org/2002/03/xkms#KeyName"/>
                        <enumeration value="http://www.w3.org/2002/03/xkms#KeyValue"/>
                        <enumeration value="http://www.w3.org/2002/03/xkms#X509Cert"/>
                        <enumeration value="http://www.w3.org/2002/03/xkms#X509Chain"/>
                        <enumeration value="http://www.w3.org/2002/03/xkms#X509CRL"/>
                        <enumeration value="http://www.w3.org/2002/03/xkms#OCSP"/> 
                        <enumeration value="http://www.w3.org/2002/03/xkms#RetrievalMethod"/>
                        <enumeration value="http://www.w3.org/2002/03/xkms#PGP"/>
                        <enumeration value="http://www.w3.org/2002/03/xkms#PGPWeb"/>
                        <enumeration value="http://www.w3.org/2002/03/xkms#SPKI"/>
                        <enumeration value="http://www.w3.org/2002/03/xkms#PrivateKey"/>
                </restriction>
        </simpleType>
        <simpleType name="RespondWithOpenEnum">
                <union memberTypes="xkms:RespondWithEnum anyURI"/>
        </simpleType>
<element name="RespondWith" type="xkms:RespondWithOpenEnum"/>
<!-- /RespondWith -->

3.2.4 Element <PendingNotification>

[107]The <PendingNotification> element is used to specify a mechanism by means of which the service can inform a requestor that a pending request has completed asynchronously.

[108]The <PendingNotification> element contains the following attributes

Mechanism [Required]

A URI that specifies the protocol by which the notification MAY be made

Identifier [Required]

A URI that specifies the address to which the notification MAY be made

[109]The following mechanisms are defined:

Protocol	~~URI~~Mechanism	Identifier	Description
SMTP	urn:ietf:rfc:822	mailto:	Notification by email. The content of the email is outside the scope of this specification
HTTP	urn:ietf:rfc:2616	http://	Notification by HTTP. The content of the request is outside the scope of this specification

[110]The following schema defines the <PendingNotification> element and PendingNotificationType type:

   <!-- PendingNotification -->
   <element name="PendingNotification" type="xkms:PendingNotificationType"/>
   <complexType name="PendingNotificationType">
      <attribute name="Mechanism" type="anyURI" use="required"/>
      <attribute name="Identifier" type="anyURI" use="required"/>
   </complexType>
   <!-- /PendingNotification -->

3.2.5 Element <PendingRequest>

[111]The PendingRequest element is used to request the result of a previously presented request for which the MajorResult code Pending was returned. The PendingRequest element inherits the element and attributes of ~~AbstractRequestType~~ RequestAbstractType and the following attribute:

ResponseId [Required]

The value of the Id attribute sent in the original response containing the MajorResult code Pending.

[112]If the value of ResponseId is unknown to the service the result Sender.UnknownResponseId is returned.

[112a]RespondWithelement MUST NOT be present inPendingRequestelement.

[113]The following schema defines the PendingRequest element and PendingRequestType type:

   <!-- PendingRequest -->
   <element name="PendingRequest" type="xkms:PendingRequestType"/>
   <complexType name="PendingRequestType">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <attribute name="ResponseId" type="NCName" use="required"/>
         </extension>
      </complexContent>
   </complexType>
   <!-- /PendingRequest -->

3.3Response Messages

3.3.1 Element <Result>

[114]The ResultType type is the type from which all XKMS response element types are derived. The ResultType type inherits the element and attributes of the MessageAbstractType abstract type and in addition contains the following attributes

<RequestSignatureValue> [Optional]

The value of the ds:SignatureValue element of the corresponding request.

ResultMajor [Required]

The most significant component of the result code

ResultMinor [Optional]

The least significant component of the result code

RequestId [Optional]

The unique identifier Id specified in the request

[115]If the MajorResult value has the value Represent the nNonce attribute MUST be present and MUST NOT be the empty string.

[116]The <Result> element is returned in response to an XKMS request if and only if the service cannot return a more specific result element that inherits from the ResultType. For example if a request is made for the status of a pending request whose identifier is unknown to the service.

[117] Security Consideration: Care must be taken when signing responses to ensure that the service does not provide a signing oracle, that is sign messages whose content is guessable by an attacker. Implementations MUST ensure that response messages contain a sufficient quantity of unpredictable data such as a pseudo-randomly chosen Id attribute. For more information see the section Security Considerations.

[118]The following schema defines the <Result> element and ResultTypetype:

   <!-- ResultType -->
   <element name="Result" type="xkms:ResultType"/>
   <complexType name="ResultType">
      <complexContent>
         <extension base="xkms:MessageAbstractType">
            <sequence>
               <element ref="xkms:RequestSignatureValue" minOccurs="0"/>
            </sequence>
            <attribute name="ResultMajor" type="QName" use="required"/>
            <attribute name="ResultMinor" type="QName" use="optional"/>
            <attribute name="RequestId" type="NCName" use="optional"/>
         </extension>
      </complexContent>
   </complexType>
   <!-- /ResultType -->

<!-- ResultType -->
<element name="Result" type="xkms:ResultType"/>
        <simpleType name="ResultMajorEnum">
                <restriction base="anyURI">
                        <enumeration value="http://www.w3.org/2002/03/xkms#Success"/>
                        <enumeration value="http://www.w3.org/2002/03/xkms#VersionMismatch"/>
                        <enumeration value="http://www.w3.org/2002/03/xkms#Sender"/>
                        <enumeration value="http://www.w3.org/2002/03/xkms#Receiver"/>
                        <enumeration value="http://www.w3.org/2002/03/xkms#Represent"/>
                        <enumeration value="http://www.w3.org/2002/03/xkms#Pending"/>
                </restriction>
        </simpleType>
        <simpleType name="ResultMajorOpenEnum">
                <union memberTypes="xkms:ResultMajorEnum anyURI"/>
        </simpleType>
        <simpleType name="ResultMinorEnum">
                <restriction base="anyURI">
                        <enumeration value="http://www.w3.org/2002/03/xkms#NoMatch"/>
                        <enumeration value="http://www.w3.org/2002/03/xkms#TooManyResponses"/>
                        <enumeration value="http://www.w3.org/2002/03/xkms#Incomplete"/>
                        <enumeration value="http://www.w3.org/2002/03/xkms#Failure"/>
                        <enumeration value="http://www.w3.org/2002/03/xkms#Refused"/>
                        <enumeration value="http://www.w3.org/2002/03/xkms#NoAuthentication"/>
                        <enumeration value="http://www.w3.org/2002/03/xkms#MessageNotSupported"/>
                        <enumeration value="http://www.w3.org/2002/03/xkms#UnknownResponseId"/>
                        <enumeration value="http://www.w3.org/2002/03/xkms#RepresentRequired"/>
                        <enumeration value="http://www.w3.org/2002/03/xkms#NotSynchronous"/>
                </restriction>
        </simpleType>
        <simpleType name="ResultMinorOpenEnum">
                <union memberTypes="xkms:ResultMinorEnum anyURI"/>
        </simpleType>
   <complexType name="ResultType">
     <complexContent>
        <extension base="xkms:MessageAbstractType">
           <sequence>
              <element ref="xkms:RequestSignatureValue" minOccurs="0"/>
           </sequence>
           <attribute name="ResultMajor" type="xkms:ResultMajorOpenEnum" use="required"/>
           <attribute name="ResultMinor" type="xkms:ResultMinorOpenEnum" use="optional"/>
           <attribute name="RequestId" type="NCName" use="optional"/>
        </extension>
     </complexContent>
   </complexType>
<!-- /ResultType -->

3.3.1.1 Result Codes

[119]Result codes consist of a major code and an optional minor code. The major and minor codes are expressed as XML anyURItypes ~~qualified names~~. This specification uses the notation ResultMajor.ResultMinor to specify a result code. For example the result code Sender.NoMatch indicates a ResultMajor code of Sender and a ResultMinor code of NoMatch.

[120]The following ResultMajor codes are defined:

~~QName Local~~ `anyURI` Name(all prefixed with`http://www.w3.org/2002/03/xkms#`)	Final	Description
Success	Final	The operation succeeded.
VersionMismatch	Final	The service does not support the protocol version specified in the request.
Sender	Final	An error occurred that was due to the message sent by the sender.
Receiver	Final	An error occurred at the receiver.
Represent	Not Final	The service has not acted on the request. In order for the request to be acted upon the request MUST be represented with the specified nonce in accordance with the two phase protocol
Pending	Not Final	The request has been accepted for processing and the service will return the result asynchronously

[121]The ResultMajor codes Success, VersionMismatch, Sender and Receiver are Final, that is the protocol has completed when the code is returned. The ResultMajor codes Represent and Pending are Not Final and indicate that further processing is necessary to receive the result.

[122]The following ResultMinor codes are defined:

~~QName Local~~`anyURI` Name (all prefixed with`http://www.w3.org/2002/03/xkms#`)	Possible Major Codes	Description
NoMatch	-	Generic Description: No match was found for the search prototype provided.
	Success	The result code Success.NoMatch indicates that the service is authoritative for the search prototype specified and that the service positively asserts that no matches exist.
	Receiver	The result code Receiver.NoMatch indicates that the service is not authoritative for the search prototype provided.
TooManyResponses	-	Generic Description:The request resulted in the number of responses that exceeded either the ResponseLimit value specified in the request or some other limit determined by the service. The service MAY either return a subset of the possible responses or none at all.
	Success	The service has returned one or more responses that represent a subset of the possible responses.
	Receiver	The service has returned no responses.
Incomplete	Success	Only part of the information requested could be provided.
Failure	-	Generic Description:The service attempted to perform the request but the operation failed for unspecified reasons.
	Sender	The reason for failure is attributed to the sender (e.g. the request failed schema validation).
	Receiver	The reason for failure is attributed to the receiver (e.g. a database lookup failed).
Refused	-	Generic Description:The operation was refused. The service did not attempt to perform the request.
	Sender	The sender failed to provide sufficient information to authenticate or authorize the request (e.g. payment not supplied)
	Receiver	The receiver is currently refusing certain requests for unspecified reasons.
NoAuthentication	Sender	The operation was refused because the necessary authentication information was incorrect or missing.
MessageNotSupported	Sender	The receiver does not implement the specified operation.
UnknownResponseId	Sender	The ResponseId for which pending status was requested is unknown to the service.
RepresentRequired	Sender	The responder requires that the sender offer the represent protocol option in order to process the request.
NotSynchronous	Receiver	The receiver does not support synchronous processing of this type of request
OptionalElementNotSupported	Receiver	The receiver has refused the operation because it does not support the OPTIONAL Element value present in the request
ProofOfPossessionRequired	Receiver	The receiver has refused the operation because it requires the sender to include the`ProofOfPossession`element in the request
TimeInstantNotSupported	Receiver	The receiver has refused the operation because it does not support the`TimeInstant`element
TimeInstantOutOfRange	Receiver	The receiver has refused the operation because the indicated time is outside the range that it responds to.

3.3.2 Element <RequestSignatureValue>

[123]The <RequestSignatureValue> element in a response contains the value of the base64 encoded value from the <ds:SignatureValue> content within the <ds:Signature> block in the corresponding request. If the response is signed this provides a cryptographic linkage between the request and the response.

[124]A service SHOULD include the <RequestSignatureValue> element in a response if the fo