XML Key Management Specification (XKMS)

Version 2.0

W3C Working Draft 4^th August 2003

This version:

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

Latest version:

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

Previous version:

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

Editor:

Phillip Hallam-Baker VeriSign

Contributors:

See the Acknowledgments.

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

---

Table Of Contents

XML Key Management Specification (XKMS)

Version 2.0

W3C Working Draft 4th 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 Protocol Exchanges

2.1 All Messages

2.2 Request Types

2.3 Responses

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

2.9 Security Binding

3 Message Syntax

3.1 Message Base

3.2 Request Message

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.1 Registration

6.2 Reissue

6.3 Revocation

6.4 Key Recovery

6.5 Request Authentication

7 Key Registration Service Message Set

7.1 Common Elements

7.2 Register

7.3 Reissue

7.4 Revoke

7.5 Recover

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

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

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

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

[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="http://www.w3.org/2001/XMLSchema" 
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
      xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
      xmlns:xkms="http://www.w3.org/2002/03/xkms#" 
      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 message

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.1 Example

<?xml version="1.0" encoding="utf-8"?>
<MessageAbstractType Id="1noOYHt5Lx7xUuizWZLOMw==" 
      Service="http://test.xmltrustcenter.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 code NotSynchronous 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="I057aebd1d5a217aaeb5382ae2255762e" 
      Service="http://test.xmltrustcenter.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="I22921e0a971e5b77e18df10d765426f2" 
      Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success" 
      RequestId="#I057aebd1d5a217aaeb5382ae2255762e" 
      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.1 Initial 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.2 Pending 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.3 Example

2.5.3.1 Request

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

2.5.3.2 Response

<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="Iae4eddb4a79c022a61affa1d1cf5b8d1" 
      Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Pending" 
      RequestId="#Iafc99372c44971799919a28e60a839dc" 
      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="I7d16f3c478266de4585cf4a145affb15" 
      Service="http://test.xmltrustcenter.org/XKMS" 
      OriginalRequestId="#Iafc99372c44971799919a28e60a839dc" 
      xmlns="http://www.w3.org/2002/03/xkms#" />

2.5.3.5 Response

<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="I7c1b5ceef4ba6746feaf52487a74e031" 
      Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success" 
      RequestId="#I7d16f3c478266de4585cf4a145affb15" 
      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.1 Processing 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:

[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="I1c52d3b1b0bfa6ab5d0a5a95b8855405" 
      Service="http://test.xmltrustcenter.org/XKMS" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <ResponseMechanism>Represent</ResponseMechanism>
  <QueryKeyBinding />
</LocateRequest>

2.6.3.2 Response 1

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

2.6.3.3 Request 2

<?xml version="1.0" encoding="utf-8"?>
<LocateRequest Id="I87fc7ad7c245db9d9cb9fe1a8c937c85" 
      Service="http://test.xmltrustcenter.org/XKMS" 
      Nonce="l7Y8sQ7DQFaq8bcSy0/wTA==" 
      OriginalRequestId="#I1c52d3b1b0bfa6ab5d0a5a95b8855405" 
      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="I5981cc47b8fd0637db5455249f19a3de" 
      Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success" 
      RequestId="#I87fc7ad7c245db9d9cb9fe1a8c937c85" 
      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.1 Example

2.8.1.1 Request 1

<?xml version="1.0" encoding="utf-8"?>
<CompoundRequest Id="I177c3e9e8b072a0c3a1ef283e6c379d6" 
      Service="http://test.xmltrustcenter.org/XKMS" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <LocateRequest Id="I48c98378370667d484a2ebf17fef8d3e" 
        Service="http://test.xmltrustcenter.org/XKMS">
    <RespondWith>KeyValue</RespondWith>
    <QueryKeyBinding>
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <X509Data>
          <X509Certificate>MIICAjCCAW+gAwIBAgIQlzQovIEbLLhMa8K5MR/juzAJBgUrDg
                MCHQUAMBIxEDAOBgNVBAMTB1Rl
c3QgQ0EwHhcNMDIwNjEzMjEzMzQxWhcNMzkxMjMxMjM1OTU5WjAsMSowKAYDVQQGEyFVUyBPPUFs
aWNlIENvcnAgQ049QWxpY2UgQWFyZHZhcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMoy
4c9+NoNJvJUnV8pqPByGb4FOJcU0VktbGJpO2imiQx+EJsCt27z/pVUDrexTyctCWbeqR5a40JCQ
mvNmRUfg2d81HXyA+iYPl4L6nUlHbkLjrhPPtMDSd5YHjyvnCN454+Hr0paA1MJXKuw8ZMkjGYsr
4fSYpPELOH5PDJEBAgMBAAGjRzBFMEMGA1UdAQQ8MDqAEEVr1g8cxzEkdMX4GAlD6TahFDASMRAw
DgYDVQQDEwdUZXN0IENBghBysVHEiNFiiE2lxWvmJYeSMAkGBSsOAwIdBQADgYEAKp+RKhDMIVIb
ooSNcoIeV/wVew1bPVkEDOUwmhAdRXUA94uRifiFfmp9GoN08Jkurx/gF18RFB/7oLrVY+cpzRoC
ipcnAnmh0hGY8FNFmhyKU1tFhVFdFXB5QUglkmkRntNkOmcb8O87xO0XktmvNzcJDes9PMNxrVtC
hzjaFAE=</X509Certificate>
        </X509Data>
      </KeyInfo>
      <KeyUsage>Signature</KeyUsage>
    </QueryKeyBinding>
  </LocateRequest>
  <LocateRequest Id="Ia021defa6657d1ee87cb7d6d4b0e860b" 
        Service="http://test.xmltrustcenter.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>

2.8.1.2 Response 1

<?xml version="1.0" encoding="utf-8"?>
<CompoundResult Id="I126a0ffdece8a7af49e2f8bdc1922a47" 
      Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success" 
      RequestId="#I177c3e9e8b072a0c3a1ef283e6c379d6" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <LocateResult Id="I01f8a31124525004089453b949ea5190" 
        Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success" 
        RequestId="#I48c98378370667d484a2ebf17fef8d3e">
    <UnverifiedKeyBinding Id="Ic61421530ba29a9bd86d8fe1bd15e1a3">
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <KeyValue>
          <RSAKeyValue>
            <Modulus>zvbTdKsTprGAKJdgi7ulDR0eQBptLv/SJNIh3uVmPBObZFsLbqPwo5ny
                  LOkzWlEHNbShPMRp1qFr
AfF13LMmeohNYfCXTHLqH1MaMOm+BhXABHB9rUKaGoOBjQPHCBtHbfMGQYjznGTpfCdTrUgq8VNl
qM2Ph9XWMcc7qbjNHw8=</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="I98abfd54acaa007f22a6cc2f1c8b6dff" 
        Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success" 
        RequestId="#Ia021defa6657d1ee87cb7d6d4b0e860b">
    <UnverifiedKeyBinding Id="I812706fe8692ecd74eba96658c268b65">
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
        <KeyValue>
          <RSAKeyValue>
            <Modulus>4i0BEhQ8Jc4tjwZYbvtMyYfBrIGOMx34K4Cdo2pAzoGnV679FLmGHWnQ
                  y2cSj39hf5D1mIaPyD3j
/33TdfglTaaKqp7IPf6ei754fOuI/r1HpX7uqsw+j9LC4Z7GnG3yoY/eBJOZ8TRwMnx+MkwmopXP
VLvhMWRyiUOcO3SEkTE=</Modulus>
            <Exponent>AQAB</Exponent>
          </RSAKeyValue>
        </KeyValue>
        <X509Data>
          <X509Certificate>MIIB+zCCAWigAwIBAgIQhzf6GHdFobRCYrjlFTCekjAJBgUrDg
                MCHQUAMBIxEDAOBgNVBAMTB1Rl
c3QgQ0EwHhcNMDIwNjEzMjEzMzQyWhcNMzkxMjMxMjM1OTU5WjAlMSMwIQYDVQQGExpVUyBPPUJv
YiBDb3JwIENOPUJvYiBCYWtlcjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtw2qGqYbO0aK
eZFb0Z3verx3Cp+KS94LiHG09D1DdgTd48FZaB5eXa4U3mLax2/Fsg/cxGZkXJur0YylS8QvRuX+
9STQgiFTO277sHFfRMvtFsuQ56ovrQWH/KoGQZssMUIqO2aN2cbMQJST3a2HZuxqPQ1rwXxHrEoA
XHZv3ysCAwEAAaNHMEUwQwYDVR0BBDwwOoAQRWvWDxzHMSR0xfgYCUPpNqEUMBIxEDAOBgNVBAMT
B1Rlc3QgQ0GCEHKxUcSI0WKITaXFa+Ylh5IwCQYFKw4DAh0FAAOBgQCieDKjvNCo7MPsgUwHydki
d4KnulcuBbZet87lcIA7ReH1qEK4s0p49po2UM69eWG7hfv8LW2Ga8HiEexTwLDFBvH2g7f09xI/
vYgPw4qhJfWoZuY/HWHUzZIRSoggipndVfdvUkmsFSx1rR4FMu0mYBjq79OkYsmwISQlaXejUg==<
      /X509Certificate>
          <X509Certificate>MIIB9zCCAWSgAwIBAgIQcrFRxIjRYohNpcVr5iWHkjAJBgUrDg
                MCHQUAMBIxEDAOBgNVBAMTB1Rl
c3QgQ0EwHhcNMDIwNjEzMjEzMzQxWhcNMzkxMjMxMjM1OTU5WjASMRAwDgYDVQQDEwdUZXN0IENB
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPF33VmCmSSFufPnu0JdFaKsPHsx0ee+OYedhM
xVh3LXMkMNC++JWDva7H+E9o+uj7dt5cwxHSePsyxPx3Vq+AbEZOsYxGxXgf4OuGb8ONBv3B5c8h
raOg24c5hjFS6tfNzoiatLVKHeOmPnifhkBI8h8LD7dLHsHfKUrVNwIJNQIDAQABo1YwVDANBgNV
HQoEBjAEAwIHgDBDBgNVHQEEPDA6gBBFa9YPHMcxJHTF+BgJQ+k2oRQwEjEQMA4GA1UEAxMHVGVz
dCBDQYIQcrFRxIjRYohNpcVr5iWHkjAJBgUrDgMCHQUAA4GBAAynWUPRSbabAEuX0Z8kKN/C2GoE
uULW73QxX6Q0PHAatRM6G9ZnzU+ce3lELgOj0Usw/xC9Y+2FMgj68rIas+DId5JMMj+SIZEUV1vP
PTEiEQ16Gxz9piUQoFljhI22hEl8ki0hIJlFGnki+K9dhv/7trMrfKSSHAPIDQZuz01P</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>

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.

3 Message Syntax

3.1 Message 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]

Data 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 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.2 Request 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 attributes

<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 value Id 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="anyURI" 
                  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] ResponseMechanism values are specified as QNames, the following identifiers are defined:

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

   <!-- ResponseMechanism -->
   <element name="ResponseMechanism" type="QName"/>
   <!-- /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 QNames, the following identifiers are defined:

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

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:

[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 and the following attribute:

ResponseID [Optional]

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.

[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="anyURI" use="optional"/>
         </extension>
      </complexContent>
   </complexType>
   <!-- /PendingRequest -->

3.3 Response 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 nonce 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="anyURI" 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 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:

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

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 following conditions are satisfied and MUST NOT include the value otherwise:

• The <ds:Signature> element was present in the corresponding request
• The service successfully verified the <ds:Signature> element in the corresponding request, and
• The ResponseMechanism RequestSignatureValue was specified.

[125] If the <RequestSignatureValue> element is present in a response the requestor MUST reject the message if either:

• The corresponding request was not authenticated, or:
• The value ds:Signature/ds:SignatureValue in the request does not match the value RequestSignatureValue in the response.

[126] The <RequestSignatureValue> element is of ds:SignatureValueType type specified in the XML Signature specification [XML-SIG].

3.4 Compound Requests

[127] The compound request mechanism allows multiple requests and the corresponding responses to be sent in a single request message. This allows considerable processing resources to be saved as a single signature on the compound message may be used in place of multiple signatures on the individual requests or responses. There are no constraints on the type of request that may be made within a single compound request. A compound request may contain multiple instances of the same type of request, a mixture of different types of request or both.

   <!-- RequestSignatureValue -->
   <element name="RequestSignatureValue" type="ds:SignatureValueType"/>
   <!-- /RequestSignatureValue -->

3.4.1 Element <CompoundRequest>

[128] The <CompoundRequest> element is used to issue multiple requests at the same time. The <CompoundRequest> element inherits the element and attributes of AbstractRequestType together with the following elements in any order:

<LocateRequest> [AnyNumber]

An XKMS Locate Request

<ValidateRequest> [AnyNumber]

An XKMS Validate Request

<RegisterRequest> [AnyNumber]

An XKMS Register Request

<ReissueRequest> [AnyNumber]

An XKMS Reissue Request

<RecoverRequest> [AnyNumber]

An XKMS Recover Request

<RevokeRequest> [AnyNumber]

An XKMS Revoke Request

[129] The following schema defines the <CompoundRequest> element and CompoundRequestType type:

   <!-- CompoundRequest -->
   <element name="CompoundRequest" type="xkms:CompoundRequestType"/>
   <complexType name="CompoundRequestType">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <choice maxOccurs="unbounded">
               <element ref="xkms:LocateRequest"/>
               <element ref="xkms:ValidateRequest"/>
               <element ref="xkms:RegisterRequest"/>
               <element ref="xkms:ReissueRequest"/>
               <element ref="xkms:RecoverRequest"/>
               <element ref="xkms:RevokeRequest"/>
            </choice>
         </extension>
      </complexContent>
   </complexType>
   <!-- /CompoundRequest -->

3.4.2 Element <CompoundResult>

[130] The <CompoundResult> element is used to respond to a <CompoundRequest>. If the compound result has the MajorResult value Success it contains multiple responses corresponding to the multiple requests specified in the <CompoundRequest>. The <CompoundResult> element inherits the element and attributes of ResultType together with the following additional elements in any order:

<LocateResult> [AnyNumber]

An XKMS Locate Result

<ValidateResult> [AnyNumber]

An XKMS Validate Result

<RegisterResult> [AnyNumber]

An XKMS Register Result

<ReissueResult> [AnyNumber]

An XKMS Reissue Result

<RecoverResult> [AnyNumber]

An XKMS Recover Result

<RevokeResult> [AnyNumber]

An XKMS Revoke Result

[131] The following schema defines the <CompoundResult> element and CompoundResultType type:

   <!-- CompoundResult -->
   <element name="CompoundResult" type="xkms:CompoundResultType"/>
   <complexType name="CompoundResultType">
      <complexContent>
         <extension base="xkms:ResultType">
            <choice minOccurs="0" maxOccurs="unbounded">
               <element ref="xkms:LocateResult"/>
               <element ref="xkms:ValidateResult"/>
               <element ref="xkms:RegisterResult"/>
               <element ref="xkms:ReissueResult"/>
               <element ref="xkms:RecoverResult"/>
               <element ref="xkms:RevokeResult"/>
            </choice>
         </extension>
      </complexContent>
   </complexType>
   <!-- /CompoundResult -->

3.5 Status Request

3.5.1 Element <StatusRequest>

[132] The StatusRequest element is used to request that the service return the status of a pending request by means of a <StatusResult> element. The StatusRequest element inherits the element and attributes of PendingRequestType.

ResponseID [Optional]

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

[133] The following schema defines the StatusRequest element and StatusRequestType type:

   <!-- StatusRequest -->
   <element name="StatusRequest" type="xkms:StatusRequestType"/>
   <complexType name="StatusRequestType">
      <complexContent>
         <extension base="xkms:PendingRequestType"/>
      </complexContent>
   </complexType>
   <!-- /StatusRequest -->

3.5.2 Element <StatusResult>

[134] The <StatusResult> element returns the status of a pending request. The StatusResultType  inherits the element and attributes of ResultType and contains the following additional attributes:

Success [Optional]

In the case of a compound request the number of inner compound operations that completed with status Success.

Failed [Optional]

In the case of a compound request the number of inner compound operations that completed with status other than Success.

Pending [Optional]

In the case of a compound request the number of inner compound operations that are still pending.

[135] The following schema defines the StatusResult element and StatusResultType type:

   <!-- StatusResult -->
   <element name="StatusResult" type="xkms:StatusResultType"/>
   <complexType name="StatusResultType">
      <complexContent>
         <extension base="xkms:ResultType">
            <attribute name="Success" type="integer" use="optional"/>
            <attribute name="Failure" type="integer" use="optional"/>
            <attribute name="Pending" type="integer" use="optional"/>
         </extension>
      </complexContent>
   </complexType>
   <!-- /StatusResult -->

4 Key Information Service Description

[136] In the XML Signature Specification [XML-SIG], a signer may optionally include information about his public signing key ("<ds:KeyInfo>") within the signature block. This key information is designed to allow the signer to communicate "hints" to a verifier about which public key to select.

[137] Another important property of <ds:KeyInfo> is that it may or may not be cryptographically bound to the signature itself.  This allows the <ds:KeyInfo> to be substituted or supplemented without "breaking" the digital signature.

[138] For example Alice signs a document and sends it to Bob with a <ds:KeyInfo> element that specifies only the signing key data. On receiving the message Bob retrieves additional information required to validate the signature and adds this information into the <ds:KeyInfo> element when he passes the document on to Carol (see Figure 1 below).

[139]

[140] Figure 1: Substitution of the <ds:KeyInfo> element as a message is passed amongst processors