W3C

XML Key Management Specification (XKMS 2.0)

Version 2.0

W3C Editor's Draft 28th December 2004 (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.

Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

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.

Table Of Contents

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

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.

[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,and type namesand QNames in the xkms namespace. For example the QName xkms:Success is referred to using the local name part Success alone.All XKMS URI reference values have the type xsd:anyURI, which is built in to the W3C XML Schema Datatypes specification [Schema2]. Unless otherwise indicated in this specification, all URI reference values used within XKMS-defined elements or attributes MUST consist of at least one non-whitespace character, and are REQUIRED to be absolute [RFC 2396]. Note that the XKMS specification makes extensive use of URI references as identifiers, such as status codes, format types, attribute and system entity names, etc. In such cases, it is essential that the values be both unique and consistent, such that the same URI is never used at different times to represent different underlying information.

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

[31]In the case of an encryption operation:

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.

[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.2Example

2.4.2.1Request

<?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.2Response

<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="I089b18dc1a520b26e2e6689dd3a5a820"
      Service="http://test.xmltrustcenter.org/XKMS""http://www.example.org/XKMS" ResultMajor="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>Pending</ResponseMechanism>
  <QueryKeyBinding />
</LocateRequest>

2.5.3.2Response

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

2.5.3.3Notification

<?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.4Pending 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.5Response

<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="I4da52fc78e0391a11257d64926cd184c"
      Service="http://test.xmltrustcenter.org/XKMS""http://www.example.org/XKMS" ResultMajor="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:

[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.3Example

2.6.3.1Request 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>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="Represent"
      RequestId="Ia1d6ca7a067fdd545f1a1396d2f26779"
      xmlns="http://www.w3.org/2002/03/xkms#" />

2.6.3.3Request 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.4Response 2

<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="I3b0111d2232507a56444c1bc85409a94"
      Service="http://test.xmltrustcenter.org/XKMS""http://www.example.org/XKMS" ResultMajor="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:

[76]Message processing is performed as described above with the following exceptions.

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:

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

[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 QNamesanyURI, the following fragment-identifiers are defined:

QName Local NameanyURI (XKMS fragment identifier) Description
Pending The requestor is prepared to accept a response that uses asynchronous processing, i.e. the service MAY return the MajorResult code Pending
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
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 QNamesanyURI, the following identifiers are defined:

QName Local NameanyURI (XKMS fragment identifier) <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 URIMechanism 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 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.

[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 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 NameanyURI (XKMS namespace fragment identifier 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 NameanyURI (XKMS namespace fragment identifier 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

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:

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

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

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

3.4Compound 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.

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 RegisterRequest
<ReissueRequest>[AnyNumber]
An XKMS ReissueRequest
<RecoverRequest>[AnyNumber]
An XKMS RecoverRequest
<RevokeRequest>[AnyNumber]
An XKMS RevokeRequest

[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 RegisterResult
<ReissueResult>[AnyNumber]
An XKMS ReissueResult
<RecoverResult>[AnyNumber]
An XKMS RecoverResult
<RevokeResult>[AnyNumber]
An XKMS RevokeResult

[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.5Status 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.

In the case of a non-compound request, the operation that completed is 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.

In the case of a non-compound request, the operation that completed is with status Failed.

Pending [Optional]
In the case of a compound request the number of inner compound operations that are still pending.

In the case of a non-compound request, the operation that completed is with status 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] Substitution of the ds:KeyInfo element as a message is passed amongst processors.

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

4.1 XKISS Locate Service

[141]The XKISS Locate service resolves a <ds:Keyinfo> element but does NOT REQUIRE the service to make an assertion concerning the validity of the binding between the data in the <ds:Keyinfo> element.

[142]The XKMS service MAY resolve the <ds:Keyinfo> element using local data or MAY relay request to other servers. For example the XKMS service might resolve a <ds:RetrievalMethod> element (Figure 2) or act as a gateway to an underlying PKI based on a non-XML syntax.

[143] Diagram shows protocol exchange between a client, a trust service and a remote server (Server A).

[144]Figure 2: Locate Service Provides Name Resolution

[145]Both the request and/or the response MAY be signed, to both authenticate the sender and protect the integrity of the data being transmitted, using an XML Signature [XML-SIG].

4.1.1 Example: Data Encryption

[146]Alice wants to send an encrypted email to Bob but does not know his encryption key. Alice can use both the S/MIME and PGP secure email formats. Alice's client uses DNS to locate the XKMS service that provides a Locate service for keys bound to the domain example.com bobcorp.test then sends an XKMS Locate request to the discovered XKMS service for a key bound to bob@example.com bob@bobcorp.test and the S/MIME or PGP protocol. The application then verifies that the certificate obtained meets its trust criteria by standard certificate validation to a trusted root.

[147]Request:

<?xml version="1.0" encoding="utf-8"?>
<LocateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I8fc9f97052a34073312b22a69b3843b6"
      Service="http://test.xmltrustcenter.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>KeyName</RespondWith>
  <RespondWith>KeyValue</RespondWith>
  <RespondWith>X509Cert</RespondWith>
  <RespondWith>X509Chain</RespondWith>
  <RespondWith>PGPWeb</RespondWith>
  <RespondWith>PGP</RespondWith>
  <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>
<?xml version="1.0" encoding="utf-8"?>
<LocateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I8fc9f97052a34073312b22a69b3843b6"
      Service="http://test.xmltrustcenter.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>http://www.w3.org/2002/03/xkms#KeyName</RespondWith>
  <RespondWith>http://www.w3.org/2002/03/xkms#KeyValue</RespondWith>
  <RespondWith>http://www.w3.org/2002/03/xkms#X509Cert</RespondWith>
  <RespondWith>http://www.w3.org/2002/03/xkms#X509Chain</RespondWith>
  <RespondWith>http://www.w3.org/2002/03/xkms#PGPWeb</RespondWith>
  <RespondWith>http://www.w3.org/2002/03/xkms#PGP</RespondWith>
  <QueryKeyBinding>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2440"
          Identifier="bob@example.com" />
    <UseKeyWith Application="urn:ietf:rfc:2633"
          Identifier="bob@example.com" />
  </QueryKeyBinding>
</LocateRequest>

[148]Response:

<?xml version="1.0" encoding="utf-8"?>
<LocateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I8ce3809ab23500015cc27704b7eb0912"
      Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success"
      RequestId="I8fc9f97052a34073312b22a69b3843b6"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <UnverifiedKeyBinding Id="I809ca03cf85b3cb466859694dbd0627d">
    <ds:KeyInfo>
      <ds:KeyValue>
        <ds:RSAKeyValue>
          <ds:Modulus>3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGm
                V7twNf2TUXCxYuztUUClM
Iy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreynWegpFbITXc8V6Y02QfR5O7Pn1/
10ElslaF/TF8MQGqYE8=</ds:Modulus>
          <ds:Exponent>AQAB</ds:Exponent>
        </ds:RSAKeyValue>
      </ds:KeyValue>
      <ds:X509Data>
        <ds:X509Certificate>MIICCTCCAXagAwIBAgIQe0Sk4xr1VolGFFNMkCx07TAJBgUrD
              gMCHQUAMBIxEDAOBgNVBAMTB1Rl
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</ds:X509Certificate>
        <ds:X509Certificate>MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrD
              gMCHQUAMBIxEDAOBgNVBAMTB1Rl
c3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWjASMRAwDgYDVQQDEwdUZXN0IENB
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEk
eXB8oMxwbhdcizWH92zrtm1VfVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVR
NK5XmKXA5sEC51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBgNV
HQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQMA4GA1UEAxMHVGVz
dCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GBABDYD4Fwx2dscu+BgYcZ+GoQQtCJ
kwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsiQgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/
MefuTtpOpCN40wy3YwwngDtHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435</ds:X509
      Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <KeyUsage>Signature</KeyUsage>
    <KeyUsage>Encryption</KeyUsage>
    <KeyUsage>Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2633"
          Identifier="bob@bobcorp.test" />
  </UnverifiedKeyBinding>
</LocateResult>
<?xml version="1.0" encoding="utf-8"?>
<LocateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I8ce3809ab23500015cc27704b7eb0912"
      Service="http://test.xmltrustcenter.org/XKMShttp://www.example.org/XKMS"
      ResultMajor="http://www.w3.org/2002/03/xkms#Success"
      RequestId="I8fc9f97052a34073312b22a69b3843b6"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <UnverifiedKeyBinding Id="I809ca03cf85b3cb466859694dbd0627d">
    <ds:KeyInfo>
      <ds:KeyValue>
        <ds:RSAKeyValue>
          <ds:Modulus>
            3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV7twNf2T
            UXCxYuztUUClMIy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreyn
            WegpFbITXc8V6Y02QfR5O7Pn1/10ElslaF/TF8MQGqYE8=
          </ds:Modulus>
          <ds:Exponent>AQAB</ds:Exponent>
        </ds:RSAKeyValue>
      </ds:KeyValue>
      <ds:X509Data>
        <ds:X509Certificate>
          MIICCTCCAXagAwIBAgIQe0Sk4xr1VolGFFNMkCx07TAJBgUrDgMCHQUAMBIxEDA
          OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj
          AkMSIwIAYDVQQDExlCb2IgQmFrZXIgTz1Cb2IgQ29ycCBDPVVTMIGfMA0GCSqGS
          Ib3DQEBAQUAA4GNADCBiQKBgQDcUW1ZSy8RqNC3ZJ5IX5G8DFZ08+HkZKVCenxI
          O++q8LATo9dxFasgaZXu3A1/ZNRcLFi7O1RQKUwjLXgHRD6TV6Pad6SZgvv4hzc
          MMZUVVpg+jFpFjRjaVXy06t7KdZ6CkVshNdzxXpjTZB9Hk7s+fX/XQSWyVoX9MX
          wxAapgTwIDAQABo1YwVDANBgNVHQoEBjAEAwIGQDBDBgNVHQEEPDA6gBABpU6Rp
          UssqgWYs3fukLy6oRQwEjEQMA4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUq
          D4e60DAJBgUrDgMCHQUAA4GBAF4jP1gGDbaq3rg/Vo3JY7EDNTp0HmwLiPMLmdn
          B3WTIGFcjS/jZFzRCbvKPeiPTZ6kRkGgydFOuCo5HMAxIks/LtnKFd/0qYT+AOD
          q/rCrwSx+F+Ro2rf9tPpja9o7gANqxs6Pm7f1QSPZO57bT/6afiVm7NdaCfjgMp
          hb+XNyn
        </ds:X509Certificate>
        <ds:X509Certificate>
          MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAMBIxEDA
          OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWj
          ASMRAwDgYDVQQDEwdUZXN0IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg
          QCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEkeXB8oMxwbhdcizWH92zrtm1V
          fVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVRNK5XmKXA5sE
          C51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBg
          NVHQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQM
          A4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GB
          ABDYD4Fwx2dscu+BgYcZ+GoQQtCJkwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsi
          QgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/MefuTtpOpCN40wy3YwwngD
          tHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435
        </ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2633"
          Identifier="bob@example.com" />
  </UnverifiedKeyBinding>
</LocateResult>

4.1.2 Example: Document Signature

[149]Bob receives the signed document from Alice which specifies Alice's X.509v3 certificate but not the key value. Bob's email client is not capable of processing X.509v3 certificates but can obtain the key parameters from the XKMS service by means of the Locate service. Bob's email client sends the <ds:Keyinfo> element to the location service requesting that the corresponding<KeyName>and<KeyValue> elements be returned.

[150]Request:

<?xml version="1.0" encoding="utf-8"?>
<LocateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I045c66f6c525a9bf3842ecd3466cd422"
      Service="http://test.xmltrustcenter.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>KeyValue</RespondWith>
  <QueryKeyBinding>
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>MIICEDCCAX2gAwIBAgIQimXeUAxYJbJMady9vV1bLjAJBgUrD
              gMCHQUAMBIxEDAOBgNVBAMTB1Rl
c3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5WjArMSkwJwYDVQQDEyBBbGljZSBB
YXJkdmFyayBPPUFsaWNlIENvcnAgQz1VUzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0nIs
mR+aVW2egl5MIfOKy4HuMKkk9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgGthO6U9D
0CNT5mbmhIAErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQggP
BLc1XagW20RMvokCAwEAAaNWMFQwDQYDVR0KBAYwBAMCBkAwQwYDVR0BBDwwOoAQAaVOkaVLLKoF
mLN37pC8uqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEC4MndUXjPG1TZxVKg+HutAwCQYFKw4DAh0F
AAOBgQABU91ka7IlkXCfv4Zh2Ohwgg2yObtY3+6C/BTFGrOEBJDy+DoxJ/NuBF18w3rrrR18xE6j
NKYLCQb8zUGk4QOG5Y+HT/QTTFvWkiOLXcpTuhnOhXatr42FoYpDkjx2QWK+J5Q2l/Rgjgc/0ZV8
U/kD8UuRkXp4AZh7QsiX8AcO0w==</ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <KeyUsage>Signature</KeyUsage>
  </QueryKeyBinding>
</LocateRequest>
<?xml version="1.0" encoding="utf-8"?>
<LocateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I045c66f6c525a9bf3842ecd3466cd422"
      Service="http://test.xmltrustcenter.org/XKMShttp://www.example.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>http://www.w3.org/2002/03/xkms#KeyValue</RespondWith>
  <QueryKeyBinding>
    <ds:KeyInfo>
      <ds:X509Data>
        <ds: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==
        </ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
  </QueryKeyBinding>
</LocateRequest>

[151]The location service extracts the X.509v3 certificate from the <ds:Keyinfo> element and returns the key values. The location service DOES NOT report the revocation status or the trustworthiness of the certificate..

[152]Response:

<?xml version="1.0" encoding="utf-8"?>
<LocateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I04cd4f17d0656413d744f55488369264"
      Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success"
      RequestId="I045c66f6c525a9bf3842ecd3466cd422"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <UnverifiedKeyBinding Id="I012f61e1d7b7b9944fe8d954bcb2d946">
    <ds:KeyInfo>
      <ds:KeyValue>
        <ds:RSAKeyValue>
          <ds:Modulus>0nIsmR+aVW2egl5MIfOKy4HuMKkk9AZ/IQuDLVPlhzOfgngjVQCjr8u
                vmnqtNu8HBupui8LgGthO
6U9D0CNT5mbmhIAErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVD
QggPBLc1XagW20RMvok=</ds:Modulus>
          <ds:Exponent>AQAB</ds:Exponent>
        </ds:RSAKeyValue>
      </ds:KeyValue>
    </ds:KeyInfo>
    <KeyUsage>Signature</KeyUsage>
    <KeyUsage>Encryption</KeyUsage>
    <KeyUsage>Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2633"
          Identifier="alice@alicecorp.test" />
  </UnverifiedKeyBinding>
</LocateResult>
<?xml version="1.0" encoding="utf-8"?>
<LocateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I04cd4f17d0656413d744f55488369264"
      Service="http://test.xmltrustcenter.org/XKMShttp://www.example.org/XKMS"
      ResultMajor="http://www.w3.org/2002/03/xkms#Success"
      RequestId="I045c66f6c525a9bf3842ecd3466cd422"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <UnverifiedKeyBinding Id="I012f61e1d7b7b9944fe8d954bcb2d946">
    <ds:KeyInfo>
      <ds:KeyValue>
        <ds:RSAKeyValue>
          <ds:Modulus>
            0nIsmR+aVW2egl5MIfOKy4HuMKkk9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8
            HBupui8LgGthO6U9D0CNT5mbmhIAErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZ
            drdcDrkNnG7SzbuJx+GDNiHKVDQggPBLc1XagW20RMvok=
          </ds:Modulus>
          <ds:Exponent>AQAB</ds:Exponent>
        </ds:RSAKeyValue>
      </ds:KeyValue>
    </ds:KeyInfo>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2633"
          Identifier="alice@example.com" />
  </UnverifiedKeyBinding>
</LocateResult>

4.2 XKISS: Validate Service

[153]The XKISS Validate Service allows all that the Locate Service does, and in addition, the client may obtain an assertion specifying the status of the binding between the public key and other data, for example a name or a set of extended attributes. Furthermore the service represents that the status of each of the data elements returned is valid and that all are bound to the same public key. The client sends to the XKMS service a prototype containing some or all of the elements for which the status of the key binding is required. If the information in the prototype is incomplete, the XKMS service MAY obtain additional data required from an underlying PKI Service. Once the validity of the key binding has been determined the XKMS service returns the status result to the client (Figure 3).

[154] Diagram shows a trust service acting as a gateway to 'PKI services'

[155] Figure 3: Validate Service Provides Key Validation

4.2.1 Example: Document Signature

[156]Bob has received Alice's message and his email client has verified the signature on the document against the public key in the certificate supplied by Alice. It is not yet known whether the certificate is considered trustworthy however. To determine this, Bob's email client sends the certificate chain to an XKMS Validate service. The service reports back that it has successfully determined that the key binding has a trusted issuer and has not been revoked.

[157]Request:

<?xml version="1.0" encoding="utf-8"?>
<ValidateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="Ie26380bfeb9d0c5bc526d5213a162d46"
      Service="http://test.xmltrustcenter.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>X509Cert</RespondWith>
  <QueryKeyBinding>
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>MIICEDCCAX2gAwIBAgIQimXeUAxYJbJMady9vV1bLjAJBgUrD
              gMCHQUAMBIxEDAOBgNVBAMTB1Rl
c3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5WjArMSkwJwYDVQQDEyBBbGljZSBB
YXJkdmFyayBPPUFsaWNlIENvcnAgQz1VUzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0nIs
mR+aVW2egl5MIfOKy4HuMKkk9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgGthO6U9D
0CNT5mbmhIAErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQggP
BLc1XagW20RMvokCAwEAAaNWMFQwDQYDVR0KBAYwBAMCBkAwQwYDVR0BBDwwOoAQAaVOkaVLLKoF
mLN37pC8uqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEC4MndUXjPG1TZxVKg+HutAwCQYFKw4DAh0F
AAOBgQABU91ka7IlkXCfv4Zh2Ohwgg2yObtY3+6C/BTFGrOEBJDy+DoxJ/NuBF18w3rrrR18xE6j
NKYLCQb8zUGk4QOG5Y+HT/QTTFvWkiOLXcpTuhnOhXatr42FoYpDkjx2QWK+J5Q2l/Rgjgc/0ZV8
U/kD8UuRkXp4AZh7QsiX8AcO0w==</ds:X509Certificate>
        <ds:X509Certificate>MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrD
              gMCHQUAMBIxEDAOBgNVBAMTB1Rl
c3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWjASMRAwDgYDVQQDEwdUZXN0IENB
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEk
eXB8oMxwbhdcizWH92zrtm1VfVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVR
NK5XmKXA5sEC51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBgNV
HQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQMA4GA1UEAxMHVGVz
dCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GBABDYD4Fwx2dscu+BgYcZ+GoQQtCJ
kwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsiQgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/
MefuTtpOpCN40wy3YwwngDtHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435</ds:X509
      Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <KeyUsage>Signature</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2633"
          Identifier="alice@alicecorp.test" />
  </QueryKeyBinding>
</ValidateRequest>
<?xml version="1.0" encoding="utf-8"?>
<ValidateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="Ie26380bfeb9d0c5bc526d5213a162d46"
      Service="http://test.xmltrustcenter.org/XKMShttp://www.example.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>http://www.w3.org/2002/03/xkms#X509Cert</RespondWith>
  <QueryKeyBinding>
    <ds:KeyInfo>
      <ds:X509Data>
        <ds: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==
        </ds:X509Certificate>
        <ds:X509Certificate>
          MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAMBIxEDA
          OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWj
          ASMRAwDgYDVQQDEwdUZXN0IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg
          QCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEkeXB8oMxwbhdcizWH92zrtm1V
          fVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVRNK5XmKXA5sE
          C51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBg
          NVHQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQM
          A4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GB
          ABDYD4Fwx2dscu+BgYcZ+GoQQtCJkwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsi
          QgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/MefuTtpOpCN40wy3YwwngD
          tHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435
        </ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2633"
          Identifier="alice@example.com" />
  </QueryKeyBinding>
</ValidateRequest>

[158]Response:

<?xml version="1.0" encoding="utf-8"?>
<ValidateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I34ef61b96f7db2250c229d37a17edfc0"
      Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success"
      RequestId="Ie26380bfeb9d0c5bc526d5213a162d46"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <KeyBinding Id="Icf608e9e8b07468fde1b7ee5449fe831">
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>MIICEDCCAX2gAwIBAgIQimXeUAxYJbJMady9vV1bLjAJBgUrD
              gMCHQUAMBIxEDAOBgNVBAMTB1Rl
c3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5WjArMSkwJwYDVQQDEyBBbGljZSBB
YXJkdmFyayBPPUFsaWNlIENvcnAgQz1VUzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0nIs
mR+aVW2egl5MIfOKy4HuMKkk9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgGthO6U9D
0CNT5mbmhIAErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQggP
BLc1XagW20RMvokCAwEAAaNWMFQwDQYDVR0KBAYwBAMCBkAwQwYDVR0BBDwwOoAQAaVOkaVLLKoF
mLN37pC8uqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEC4MndUXjPG1TZxVKg+HutAwCQYFKw4DAh0F
AAOBgQABU91ka7IlkXCfv4Zh2Ohwgg2yObtY3+6C/BTFGrOEBJDy+DoxJ/NuBF18w3rrrR18xE6j
NKYLCQb8zUGk4QOG5Y+HT/QTTFvWkiOLXcpTuhnOhXatr42FoYpDkjx2QWK+J5Q2l/Rgjgc/0ZV8
U/kD8UuRkXp4AZh7QsiX8AcO0w==</ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <KeyUsage>Signature</KeyUsage>
    <KeyUsage>Encryption</KeyUsage>
    <KeyUsage>Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2633"
          Identifier="alice@alicecorp.test" />
    <Status StatusValue="Valid">
      <ValidReason>Signature</ValidReason>
      <ValidReason>IssuerTrust</ValidReason>
      <ValidReason>RevocationStatus</ValidReason>
      <ValidReason>ValidityInterval</ValidReason>
    </Status>
  </KeyBinding>
</ValidateResult>
<?xml version="1.0" encoding="utf-8"?>
<ValidateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I34ef61b96f7db2250c229d37a17edfc0"
      Service="http://test.xmltrustcenter.org/XKMShttp://www.example.org/XKMS"
      ResultMajor="http://www.w3.org/2002/03/xkms#Success"
      RequestId="Ie26380bfeb9d0c5bc526d5213a162d46"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <KeyBinding Id="Icf608e9e8b07468fde1b7ee5449fe831">
    <ds:KeyInfo>
      <ds:X509Data>
        <ds: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==
        </ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2633"
          Identifier="alice@example.com" />
    <Status StatusValue="http://www.w3.org/2002/03/xkms#Valid">
      <ValidReason>http://www.w3.org/2002/03/xkms#Signature</ValidReason>
      <ValidReason>http://www.w3.org/2002/03/xkms#IssuerTrust</ValidReason>
      <ValidReason>http://www.w3.org/2002/03/xkms#RevocationStatus</ValidReason>
      <ValidReason>http://www.w3.org/2002/03/xkms#ValidityInterval</ValidReason>
    </Status>
  </KeyBinding>
</ValidateResult>

4.3 Using Locate and Validate

[159]The Locate and Validate operations are both used to obtain information about a public key from an XKMS Service. Locate and Validate services are both expected to attempt to provide correct information to the requestor. The Locate and Validate services differ in the extent to which the service vouches for the trustworthiness the information returned.

[160]A Location service SHOULD attempt to provide only information which is trustworthy to the best of its knowledge but does not provide any assurance that it will do so. Information obtained from a Locate service SHOULD NOT be relied upon unless it is validated. Validation may be achieved by forwarding the data to a Validate service or by performing the necessary trust path verification locally.

[161]A Validation service undertakes to only return information which has been positively validated by the XKMS Service as meeting specific validation criteria. A client MAY rely on the information returned by the service without further validation provided that the client has a means to determine that the information returned is authentic and is assured that the validation service applied the means of validation appropriate to the circumstances.

[162]No single set of validation criteria are appropriate to every circumstance. Applications involving financial transactions are likely to require the application of very specific validation criteria that ensure that certain contractual and/or regulatory policies are enforced. The Locate service provides a key discovery function that is neutral with respect to the validation criteria that the client application may apply. The Validate service provides a key discovery and validation function that produces a results which are each specific to a single set of validation criteria.

4.3.1 DNS Integration

[163]In many cases the key information which a client requires is bound to some form of address specified by an Internet protocol part of which consists of a DNS address. For example an email client may require a trustworthy key to send an encrypted email to bob@example.com. Unless an XKMS service which provides key information about keys bound to email addresses in the domain example.com is known a priori, some means of locating the correct XKMS service is required.

[164]Figure 5 shows an example of using the DNS SRV record to perform discovery of XKMS services. The email client requests a key for bob@example.com from a trusted Validate service. The Validate service then queries the DNS to locate an XKMS service providing information on keys bound to addresses in the zone example.com. The Validate service does not have an established trust relationship with the example.com XKMS service and so a Locate request is made to determine if any key information bound to bob@example.com can be located. The Validate service then validates the information received by such means as are appropriate (e.g. by verifying that a certification chain may be constructed from a root of trust) and the response returned to the email client.

[165] see caption

[166]Figure 5: Combined use of Locate and Validate service

[167]Appendix B provides further information on the use of the DNS SRV record.

5 Key Information Service Message Set

[168]The protocol consists of pairs of messages, with an application sending a request message to an XKMS service and the service responding with another message. 

5.1 Key Binding Specification

[169]A key binding asserts a binding between data elements that relate to a public key including the <ds:KeyName>, <ds:KeyValue> and <ds:X509Data> components contained in a <ds:KeyInfo> element. Furthermore, the Service represents to the client accessing the service and to that client alone that the binding between the data elements is valid under whatever trust policy the service offers to that client.

[170]XKMS specifies four elements that specify key bindings, all of which are derived from the KeyBindingAbstractType. These elements are:

UnverifiedKeyBinding
Specifies the parameters of a particular instance of a key binding but not the status.
KeyBinding
Specifies the parameters of a particular instance of a key binding
QueryKeyBinding
A template used to specify one or more key bindings using query by example.
PrototypeKeyBinding
A template used to specify the key binding parameters requested in a registration request.

[171]An XKMS service MAY provide an interface to an underlying PKI such as PKIX or PGP. This specification does not define how XKMS operations interact with the underlying PKI. The XKMS key binding MAY be bound to a data object such as a certificate or key signing in the underlying PKI such that XKMS operations on the key binding result in a corresponding change to the data structures in the underlying PKI and vice versa. If for example the XKMS service provides a mapping to an underlying PKIX/X.509 PKI the registration of a key binding would typically result in the issue of a certificate, even if the client does not ask for the certificate to be returned in the registration result. If the key binding were subsequently revoked the corresponding certificate in the underlying PKI would typically be revoked also.

5.1.1Abstract Type KeyBindingAbstractType

[172]The KeyBindingAbstractType is the abstract type from which all XKMS key binding element specifiers are derived. It contains the following elements and attribute:

Id [Optional]
Identifier of the key binding.
<ds:KeyInfo>  [Optional]
The public key information to which the key binding information is bound
<KeyUsage> [0 to 3]
The cryptographic key uses for which the key may be used
<UseKeyWith> [Any Number]
The applications with which the key may be used together with the application specific subject identifier of the key holder for that application

[173]The Id identifier is defined to provide a means by which the key binding may be signed using XML Signature. Clients MUST NOT rely on the key binding identifier being either unique or stable. In the case that an XKMS service is providing an interface to an underlying PKI, clients MUST NOT rely on the service choosing key binding identifiers that are either the same as or bear a systematic relationship to the serial numbers or other identifiers of the corresponding credentials in the underlying PKI.

[174]The following schema defines the KeyBindingAbstractType type:

   <!-- KeyBindingAbstractType-->
   <complexType name="KeyBindingAbstractType" abstract="true">
      <sequence>
         <element ref="ds:KeyInfo" minOccurs="0"/>
         <element ref="xkms:KeyUsage" minOccurs="0" maxOccurs="3"/>
         <element ref="xkms:UseKeyWith" minOccurs="0"
               maxOccurs="unbounded"/>
      </sequence>
      <attribute name="Id" type="ID" use="optional"/>
   </complexType>
   <!-- /KeyBindingAbstractType-->

5.1.2 Element <KeyUsage>

[175]The <KeyUsage> element specifies one or more intended uses of the key. If no <KeyUsage> is specified all uses are permitted. The following key usages are defined:

Encryption
The key pair may be used for encryption and decryption
Signature
The key pair may be used for signature and verification
Exchange
The key pair may be used for key exchange

[176]If a key usage is specified in a KeyBinding that the cryptographic algorithm associated with the key does not support the element MUST be ignored. If a key usage is specified in a QueryKeyBinding however the key usage forms part of the criteria the service should attempt to match.

[177]For example if a KeyBinding specifies the key usage Encryption for a Digital Signature Algorithm key the relying application should ignore the key usage element. If however a client makes a request that contains a QueryKeyBinding that specifies the key usage encryption the service should not return a Digital Signature Algorithm key.

[178]The following schema defines the <KeyUsage> element:

   <!-- KeyUsage -->
   <element name="KeyUsage" type="xkms:KeyUsageType"/>
   <simpleType name="KeyUsageType">
      <restriction base="QName">
         <enumeration value="xkms:Encryption"/>
         <enumeration value="xkms:Signature"/>
         <enumeration value="xkms:Exchange"/>
      </restriction>
   </simpleType>
   <!-- /KeyUsage -->
   <!-- KeyUsage -->
   <simpleType name="KeyUsageEnum">
      <restriction base="anyURI">
         <enumeration value="http://www.w3.org/2002/03/xkms#Encryption"/>
         <enumeration value="http://www.w3.org/2002/03/xkms#Signature"/>
         <enumeration value="http://www.w3.org/2002/03/xkms#Exchange"/>
      </restriction>
   </simpleType>

   <element name="KeyUsage" type="xkms:KeyUsageEnum"/>
   <!-- /KeyUsage -->

5.1.3 Element <UseKeyWith>

[179]The <UseKeyWith> element specifies a subject identifier and application identifier that determine a use of the key. The interpretation of <UseKeyWith> depends on the enclosing construct.

QueryKeyBinding / TemplatePrototypeKeyBinding
A key binding is requested that meets the specified criteria. If the service is unable to meet the criteria exactly 'best guess' is acceptable.
UnverifiedKeyBinding / KeyBinding
The key may be used for the purpose specified (if unverified after validation). If more than one use key with is specified then all are applicable jointly and severally

[180]The <UseKeyWith> element contains the following attributes:

Application     [Required]
A URI that specifies the application protocol with which the key may be used
Identifier     [Required]
Specifies the subject to which the key corresponds within the specified application protocol.

[181]Note that in some applications, in particular X.509 an application identifier is not guaranteed to be globally unique. In such circumstances the XKMS service is responsible for specifying rules to unambiguously interpret identifiers.

[182]The following table lists application URIs for common application protocols and the corresponding format for the identifier information:

Application Application URI Identifier Type
XKMS http://www.w3.org/2002/03/xkms# URL identifying SOAP role URI
XKMS/profile http://www.w3.org/2002/03/xkms#profile URL identifying SOAP role URI
S/MIME urn:ietf:rfc:2633 SMTP email address of subject RFC822 addr-spec
PGP urn:ietf:rfc:2440 SMTP email address of subject RFC822 addr-spec
TLS urn:ietf:rfc:2246 URI identifying certificate subject URI
TLS/HTTPS urn:ietf:rfc:2818 DNS address of http server DNS Address
TLS/SMTP urn:ietf:rfc:2487 DNS address of mail server DNS Address
IPSEC urn:ietf:rfc:2401 IP address of network resource IP Address
PKIX urn:ietf:rfc:2459 Certificate Subject Name X.509 Distinguished Name

[183] The XKMS application URI is used to specify a key binding that is used to secure an XKMS service. An XKMS service SHOULD support discovery of the supported security profiles and corresponding key bindings by means of a Locate operation that specifies the XKMS application URI and the URL of the service role. Note that as with any other Locate operation the credentials returned by this mechanism SHOULD only be considered trustworthy if validated according to the trust policy of the client.

[184] The primary use intended for <UseKeyWith> identifiers is to identify application protocols. <UseKeyWith> URI identifiers MAY be specified that represent key binding issuance and/or use policies instead of or in addition to an application protocol. In this case the <UseKeyWith> element specifies that the key binding complies with the specified policy. For example, applications handling XAdES [XAdES] compliant signatures could define their own <UseKeyWith> application values.

[185]In the case that a client follows a referral model in which raw key binding information is obtained from a Locate service then forwarded to a validate service the <UseKeyWith> elements in the query should in both cases specify the uses for which the application intends to use the key. Applications SHOULD NOT forward <UseKeyWith> elements returned in a Locate result in a subsequent Validate query.

[186]The following table describes the formatting for the specified types of identifier:

Identifier Type Example Description
RFC822 addr-spec bob@example.com The addr-spec fragment of an RFC 822 email address as used by SMTP
URI https://example.com/ A Uniform Resource Identifier
DNS Address example.com An Internet DNS address
IP Address 10.23.0.20 An IPv4 address in decimal notation
1080::8:800:200C:417A An IPv6 address in RFC 2373 notation
X.509 Distinguished Name C="UK" O="CryptoGuys Ltd." CN="Bob" An X.509 Distinguished Name

[187]The following schema defines the <UseKeyWith> element:

   <!-- UseKeyWith -->
   <element name="UseKeyWith" type="xkms:UseKeyWithType"/>
   <complexType name="UseKeyWithType">
      <attribute name="Application" type="anyURI" use="required"/>
      <attribute name="Identifier" type="string" use="required"/>
   </complexType>
   <!-- /UseKeyWith -->

5.1.4 Element <UnverifiedKeyBinding>

[188]The <UnverifiedKeyBinding> element is derived from the KeyBindingAbstractType. It describes a key binding but makes no assertion regarding the status of the key binding.

[189]The <UnverifiedKeyBinding> element extends the KeyBindingAbstractType with the following additional elements:

<ValidityInterval> [Optional]
The time interval in which the key binding relationship is asserted

[190]The following schema defines the <UnverifiedKeyBinding> element and UnverifiedKeyBindingType:

   <!-- UnverifiedKeyBinding -->
   <element name="UnverifiedKeyBinding"
         type="xkms:UnverifiedKeyBindingType"/>
   <complexType name="UnverifiedKeyBindingType">
      <complexContent>
         <extension base="xkms:KeyBindingAbstractType">
            <sequence>
               <element ref="xkms:ValidityInterval" minOccurs="0"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /UnverifiedKeyBinding -->

5.1.5 Element <ValidityInterval>

[191]The <ValidityInterval> element specifies limits on the validity of the key binding.

NotBefore     [Optional]
Time instant at which the validity interval begins
NotOnOrAfter     [Optional]
Time instant at which the validity interval has ended

[192]All dateTime values MUST fully specify the date.

[193]The NotBefore and NotOnOrAfter attributes are optional. If the NotBefore attribute is omitted the key binding is valid on any date up to but excluding the date specified in the NotOnOrAfter attribute . If the NotOnOrAfter attribute is omitted the key binding is valid from the NotBefore attribute with no expiry. If both elements attributes are omitted the key binding is valid at any time.

[194]In accordance with the XML Schema Specifications, all time instances are interpreted in Universal Coordinated Time unless they explicitly indicate a time zone.

[195]Implementations MUST NOT generate time instances that specify leap seconds.

[196]For purposes of comparison, the time interval NotBefore to NotOnOrAfter begins at the earliest time instant compatible with the specification of NotBefore and has ended at the earliest time instant compatible with the specification of NotOnOrAfter

[197]For example if the time interval specified is dayT12:03:02 to dayT12:05:12 the times 12:03:02.00 and 12:05:11.9999 are within the time interval. The time 12:05:12.0000 is outside the time interval.

[198]The following schema defines the <ValidityInterval> element:

   <!-- ValidityInterval -->
   <element name="ValidityInterval" type="xkms:ValidityIntervalType"/>
   <complexType name="ValidityIntervalType">
      <attribute name="NotBefore" type="dateTime" use="optional"/>
      <attribute name="NotOnOrAfter" type="dateTime" use="optional"/>
   </complexType>
   <!-- /ValidityInterval -->

5.1.6 Element <KeyBinding>

[199]The <KeyBinding> element is derived from the UnverifiedKeyBindingType. It specifies a particular instance of a key binding and its current status as known to the issuer of the key binding.

[200]The <KeyBinding> element extends the UnverifiedKeyBindingType with the following additional elements:

<Status> [Required]
The status of the key binding instance.

[201]The following schema defines the <KeyBinding> element and KeyBindingType:

   <!-- KeyBinding -->
   <element name="KeyBinding" type="xkms:KeyBindingType"/>
   <complexType name="KeyBindingType">
      <complexContent>
         <extension base="xkms:UnverifiedKeyBindingType">
            <sequence>
               <element ref="xkms:Status"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /KeyBinding -->

5.1.7 Element <Status>

[202]The <status> element specifies the status of a <KeyBinding> instance.

[203]The status value MAY be supplemented with codes that state the status of specific aspects of the key binding status that were validated.

[204]The <Status> element contains the following elements and attribute:

<ValidReason> [Any Number]
A status aspect that was evaluated and found to be Valid.
<IndeterminateReason> [Any Number]
A status aspect that could not be evaluated or was evaluated and returned an Indeterminate result.
<InvalidReason> [Any Number]
A status aspect that was evaluated and found to be Invalid.
StatusValue [Required]
The key binding status

[205]The enumerated type AssertionStatus is used to indicate the key binding status. The following values are defined:

Valid
The key binding is definitively valid.
Indeterminate
The status of the key binding cannot be determined.
Invalid
The key binding is definitively invalid.

[206]If reason codes are specified StatusValue attribute MUST be consistent with the reason codes specified as follows:

[207]The following schema defines the <Status> element and StatusType and AssertionType types:

   <!-- Status -->
   <element name="Status" type="xkms:StatusType"/>
   <complexType name="StatusType">
      <sequence>
         <element ref="xkms:ValidReason" minOccurs="0"
               maxOccurs="unbounded"/>
         <element ref="xkms:IndeterminateReason" minOccurs="0"
               maxOccurs="unbounded"/>
         <element ref="xkms:InvalidReason" minOccurs="0"
               maxOccurs="unbounded"/>
      </sequence>
      <attribute name="StatusValue" type="xkms:KeyBindingStatus"
            use="required"/>
      <attribute name="StatusValue" type="xkms:KeyBindingEnum" use="required"/>
   </complexType>
   <simpleType name="KeyBindingStatus">
      <restriction base="QName">
         <enumeration value="xkms:Valid"/>
         <enumeration value="xkms:Invalid"/>
         <enumeration value="xkms:Indeterminate"/>
      </restriction>
   </simpleType>
   <simpleType name="KeyBindingEnum">
      <restriction base="anyURI">
         <enumeration value="http://www.w3.org/2002/03/xkms#Valid"/>
         <enumeration value="http://www.w3.org/2002/03/xkms#Invalid"/>
         <enumeration value="http://www.w3.org/2002/03/xkms#Indeterminate"/>
      </restriction>
   </simpleType>
   <!-- /Status -->

5.1.8 Elements <ValidReason >, <InvalidReason> and<IndeterminateReason>

[208]The <ValidReason>, <InvalidReason> and<IndeterminateReason> elements are used to specify a QName that specifies areason for a particular key binding status.

[209]The status aspects are defined in the table below. For convenience the equivalent X509 processing steps are given:

Reason QName Local Name anyURI (XKMS namespace fragment identifier) Description X.509 Equivalent
Valid Invalid
IssuerTrust The issuer of the information on which the key binding is based is considered to be trustworthy by the XKMS service. Certificate path anchored by trusted root successfully constructed Certificate path could not be constructed to a trusted root
RevocationStatus The XKMS service has affirmatively verified the status of the key binding with an authoritative source Certificate status validated using CRL or OCSP Certificate status returned revoked or suspended.
ValidityInterval The requested time instant was within the validity interval of the key binding The certificate chain was valid at the requested time instant. The requested time instant was before or after the certificate chain validity interval
Signature Signature on signed data provided by the client in the <Keyinfo> element was successfully verified. Certificate Signature verified Certificate Signature verification failed

[210]The following schema defines the <ValidReason>, <InvalidReason> and<IndeterminateReason> elements:

   <!-- Reason -->
   <element name="ValidReason" type="QName"/>
   <element name="InvalidReason" type="QName"/>
   <element name="IndeterminateReason" type="QName"/>
   <!-- /Reason -->
<!-- Reason -->
        <simpleType name="ReasonEnum">
                <restriction base="anyURI">
                        <enumeration value="http://www.w3.org/2002/03/xkms#IssuerTrust"/>
                        <enumeration value="http://www.w3.org/2002/03/xkms#RevocationStatus"/>
                        <enumeration value="http://www.w3.org/2002/03/xkms#ValidityInterval"/>
                        <enumeration value="http://www.w3.org/2002/03/xkms#Signature"/>
                </restriction>
        </simpleType>
        <simpleType name="ReasonOpenEnum">
                <union memberTypes="xkms:ReasonEnum anyURI"/>
        </simpleType>
<element name="ValidReason" type="xkms:ReasonOpenEnum"/>
<element name="InvalidReason" type="xkms:ReasonOpenEnum"/>
<element name="IndeterminateReason" type="xkms:ReasonOpenEnum"/>
<!-- /Reason -->

5.1.9 Element <QueryKeyBinding>

[211]The <QueryKeyBinding> element is derived from the KeyBindingAbstractType and is used to perform a query that results in the return of one or more matching key bindings.

[212]A key binding matches the QueryKeyBinding if:

[213]The <QueryKeyBinding> element extends the KeyBindingAbstractType with the following additional elements:

<TimeInstant> [Optional]
The Time Instant for which the query is made. If no time instant is specified the default is the time the request was made.

[214]The following schema defines the <QueryKeyBinding> element and KeyBindingType:

   <!-- QueryKeyBinding -->
   <element name="QueryKeyBinding" type="xkms:QueryKeyBindingType"/>
   <complexType name="QueryKeyBindingType">
      <complexContent>
         <extension base="xkms:KeyBindingAbstractType">
            <sequence>
               <element ref="xkms:TimeInstant" minOccurs="0"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /QueryKeyBinding -->

5.1.10 Element <TimeInstant>

[215]The <TimeInstant> element specifies a specific instant in time for which a key binding query is made. The <TimeInstant> element contains the following attribute:

Time     [Required]
Time instant to which a <QueryKeyBinding> relates.

[216]All dateTime values MUST fully specify the date.

[217]The following schema defines the <TimeInstant> element:

   <!-- TimeInstant -->
   <element name="TimeInstant" type="xkms:TimeInstantType"/>
   <complexType name="TimeInstantType">
      <attribute name="Time" type="dateTime" use="required"/>
   </complexType>
   <!-- /TimeInstant -->

5.2 Locate Service

[218]The Locate service accepts as input a <QueryKeyBinding> element that specifies a key binding and returns one or more <UnverifiedKeyBinding> elements that relate to the same public key. The <UnverifiedKeyBinding> elements returned are specified by the Respond element in the request.

5.2.1Locate Request Element <LocateRequest>

[219]The request message contains a <LocateRequest> element that contains the following element.

<QueryKeyBinding> [Required]
The key binding query to be matched in the response

[220] The following schema defines the <LocateRequest> element:

   <!-- LocateRequest -->
   <element name="LocateRequest" type="xkms:LocateRequestType"/>
   <complexType name="LocateRequestType">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <sequence>
               <element ref="xkms:QueryKeyBinding"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /LocateRequest -->

5.2.2Locate Response Element <LocateResult>

[221]The response message contains a <LocateResult> element

<UnverifiedKeyBinding> [Any Number]
A sequence of <UnverifiedKeyBinding> key binding that matche the key binding query specified in the corresponding request. If no results are found the sequence is empty and the <ResultCode>NoMatch returned. In some circumstances a Locate operation MAY return multiple matching results.

[222] The following schema defines the <LocateResult> element:

   <!-- LocateResult -->
   <element name="LocateResult" type="xkms:LocateResultType"/>
   <complexType name="LocateResultType">
      <complexContent>
         <extension base="xkms:ResultType">
            <sequence>
               <element ref="xkms:UnverifiedKeyBinding" minOccurs="0"
                     maxOccurs="unbounded"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /LocateResult -->

5.3 Validate Service

[223]The Validate service allows the client to query the binding between a <ds:Keyinfo> element and other data such as an identifier. The client supplies a prototype for the key binding requested. The prototype may specify either a <ds:Keyinfo> element or one or more <UseKeyWith> elements or  both. If the validate request is successful the server returns one or more <KeyBinding> elements that meet the criteria specified in the request.

5.3.1Validate Request Element <ValidateRequest>

[224]The validate request message contains a <ValidateRequest> element:

<QueryKeyBinding>     [Required]
The key binding query to be matched in the response.

[225]The following schema defines the <ValidateRequest> element:

   <!-- ValidateRequest -->
   <element name="ValidateRequest" type="xkms:ValidateRequestType"/>
   <complexType name="ValidateRequestType">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <sequence>
               <element ref="xkms:QueryKeyBinding"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /ValidateRequest -->

5.3.2Validate Response Element <ValidateResult>

[226]The validate response message contains a <ValidateResult> element:

<Keybinding>     [Any Number]
A sequence of <KeyBinding> key bindings that match the key binding query specified in the corresponding request. If no results are found the sequence is empty and the <ResultCode>NoMatch returned. In some circumstances a Validate operation MAY return multiple matching results.

[227]The following schema defines the <ValidateResult> element and the ValidateResultType type.

   <!-- ValidateResult -->
   <element name="ValidateResult" type="xkms:ValidateResultType"/>
   <complexType name="ValidateResultType">
      <complexContent>
         <extension base="xkms:ResultType">
            <sequence>
               <element ref="xkms:KeyBinding" minOccurs="0"
                     maxOccurs="unbounded"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /ValidateResult -->

6 Key Registration Service Description

[228]The XML Key Registration Service Specification permits management of information that is bound to a public key pair. The XKRSS service specification supports the following operations:

Register
Information is bound to a public key pair through a key binding
Reissue
A previously registered key binding is reissued.
Revoke
A previously registered key binding is revoked.
Recover
The private key associated with a key binding is recovered.

[229]An XKMS service may offer all or none of these services.

[230]The Register operation does not in itself place any requirement on the registration service to communicate that information to any other party. In most applications, however, a registration service will provide key information to other Web Services such as those described in the XKMS specification or a separate underlying PKI such as PKIX.

[231]The Register operation MAY be used in a mode where client requests are accepted by an intermediary such as a Local Registration Authority (LRA) and forwarded to a Master Registration Authority (MRA). This mode of operation is entirely transparent to the client which acts as if the LRA is the only registration authority involved. The construction of the proof-of-possession of the private key and the authentication information is complete separate of the message authentication signature. This allows verification by both the LRA and any other registration authority that it is relayed to, even if the message authentication signature has been replaced by the LRA.

6.1 Registration

[232]The Register request is used to assert a binding of information to a public key pair. Generation of the public key pair MAY be performed by either the client or the Registration service.

[233]The Registration request message contains a prototype of the requested key binding. The registration service MAY require the client to provide additional information to authenticate the request. If the public key pair is generated by the client, the service MAY require the client to provide Proof of Possession of the private key.

[234]The prototype of the requested key binding may contain only partial information, a key without a name or a name without a key. In this case, the client is requesting that the registration service provide the additional information required to complete the binding. All information contained in the prototype of the requested key binding is advisory to the service and MAY be ignored or overridden at the option of the service.

[235]On receipt of a registration request, the registration service verifies the authentication and POP information provided (if any). If the registration service accepts the request a key binding is registered. This key binding MAY include some, all or none of the information provided by the prototype key binding and MAY include additional information.

[236]The registration service MAY return part or all of the registered key binding to the client.

[237] Diagram shows the data passed from the client to the server for registration

[238]Figure 5: Registration of a Key Binding

[239]The choice of generation of the key pair at the client or the service depends on the application and the type of key. In the case of a key used for signing purposes it is generally undesirable for any party apart from the key bearer to have access to the private key. Should access to the private key be lost a new key may be issued without affecting the validity of any of the signatures created using the old private key. Accordingly it is usually preferable for such keys to be generated at the client and not the server.

[240]In the case of a private key used exclusively for certain types of encryption, the loss of access to the private key may result in the loss of access to the stored data encrypted under the key. In such circumstances it is generally desirable for some form of key recovery to be employed. In such systems the key pair is typically generated at the service and delivered to the client.

[241]A key used for both signing and encryption might be generated at the client or the server depending on whether key recovery is to be supported.

6.1.1 Example: Registration of Client-Generated Key Pair

[242]Alice requests registration of an RSA key pair for her email address Alice@example.com. Alice has previously received from the XKMS service the code "024837" with which to authenticate her request. Alice selects the pass phrase "Help I have revealed my key" to authenticate herself should it be necessary to revoke the registration at a later date.

[243]The X-KRSS request message contains the following <RegisterRequest> element: Because the registration request is for a client generated key the Authentication element contains both a <ProofOfPossession> element which demonstrates that the request is authorized by the holder of the private key and a <KeyBindingAuthentication> element which demonstrates that the request was made by a person who knows the authentication code "024837".

<?xml version="1.0" encoding="utf-8"?>
<RegisterRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
   xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
   Id="I1494ac4351b7de5c174d455b7000e18f"
   Service="http://test.xmltrustcenter.org/XKMS"
   xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>X509Cert</RespondWith>
  <RespondWith>X509Chain</RespondWith>
  <PrototypeKeyBinding Id="I269e655567dbae568591c0a06957529e">
    <ds:KeyInfo>
      <ds:KeyValue>
        <ds:RSAKeyValue>
          <ds:Modulus>0nIsmR+aVW2egl5MIfOKy4HuMKkk9AZ/IQuDLVPlhzOfgngjVQ
Cjr8uvmnqtNu8HBupui8LgGthO6U9D0CNT5mbmhIAErRADUMIAFsi7LzBarUvNWTqY
NEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQggPBLc1XagW20RMvok=</ds:Modulus>
          <ds:Exponent>AQAB</ds:Exponent>
        </ds:RSAKeyValue>
      </ds:KeyValue>
    </ds:KeyInfo>
    <KeyUsage>Signature</KeyUsage>
    <KeyUsage>Encryption</KeyUsage>
    <KeyUsage>Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2459"
         Identifier="C="US" O="Alice Corp" CN="Alice Aardvark"" />
    <UseKeyWith Application="urn:ietf:rfc:2633"
         Identifier="alice@alicecorp.test" />
    <UseKeyWith Application="http://ca.example.com/cps/20030401/class3"
         Identifier="alice@alicecorp.test" />
  </PrototypeKeyBinding>
  <Authentication>
    <KeyBindingAuthentication>
      <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
        <SignedInfo>
          <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
          <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1" />
          <Reference URI="#I269e655567dbae568591c0a06957529e">
            <Transforms>
              <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
            </Transforms>
            <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
            <DigestValue>LAHkLSYROzQ+6SkZ2LwxjqDB6Jk=</DigestValue>
          </Reference>
        </SignedInfo>
        <SignatureValue>RK855+gOk3DX+Y2P6ACQICTG7nk=</SignatureValue>
      </Signature>
    </KeyBindingAuthentication>
  </Authentication>
  <ProofOfPossession>
    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
      <SignedInfo>
        <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
        <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
        <Reference URI="#I269e655567dbae568591c0a06957529e">
          <Transforms>
            <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
          </Transforms>
          <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
          <DigestValue>LAHkLSYROzQ+6SkZ2LwxjqDB6Jk=</DigestValue>
        </Reference>
      </SignedInfo>
      <SignatureValue>XyC4JuLJIkpHmFkRUFUI0zrC0cNONPb/VlbKHN6qV0AOqXSqpXY4MNh75
O6Nj/JWQiT3I9T1ISLlJEHTIwRDPfC4lm8OQTqsMad05FAkrYA4LbU6xBXNde+HwLqOHo
7Ct7jZMAQ3HHH3lzkGFsxrSHLs1Gg81/4KqtXocRav6VU=</SignatureValue>
    </Signature>
  </ProofOfPossession>
</RegisterRequest>
<?xml version="1.0" encoding="utf-8"?>
<RegisterRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
   xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
   Id="I1494ac4351b7de5c174d455b7000e18f"
   Service="http://test.xmltrustcenter.org/XKMShttp://www.example.org/XKMS"
   xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>http://www.w3.org/2002/03/xkms#X509Cert</RespondWith>
  <RespondWith>http://www.w3.org/2002/03/xkms#X509Chain</RespondWith>
  <PrototypeKeyBinding Id="I269e655567dbae568591c0a06957529e">
    <ds:KeyInfo>
      <ds:KeyValue>
        <ds:RSAKeyValue>
          <ds:Modulus>
            0nIsmR+aVW2egl5MIfOKy4HuMKkk9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8
            HBupui8LgGthO6U9D0CNT5mbmhIAErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZ
            drdcDrkNnG7SzbuJx+GDNiHKVDQggPBLc1XagW20RMvok=
          </ds:Modulus>
          <ds:Exponent>AQAB</ds:Exponent>
        </ds:RSAKeyValue>
      </ds:KeyValue>
    </ds:KeyInfo>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2459"
         Identifier='C="US" O="Alice Corp" CN="Alice Aardvark"' />
    <UseKeyWith Application="urn:ietf:rfc:2633"
         Identifier="alice@example.com" />
    <UseKeyWith Application="http://ca.example.com/cps/20030401/class3"
         Identifier="alice@example.com" />
    <RevocationCodeIdentifier>
      5AEAai06hFJEkuqyDyqNh8k/u3M=
    </RevocationCodeIdentifier>
  </PrototypeKeyBinding>
  <Authentication>
    <KeyBindingAuthentication>
      <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
        <SignedInfo>
          <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
          <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1" />
          <Reference URI="#I269e655567dbae568591c0a06957529e">
            <Transforms>
              <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
            </Transforms>
            <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
            <DigestValue>WCbpkifxJ1zIJ+V6/knZgxRhR34=</DigestValue>
          </Reference>
        </SignedInfo>
        <SignatureValue>iJSKM+98hj5ae+btC2WjwBYP+/k=</SignatureValue>
      </Signature>
    </KeyBindingAuthentication>
  </Authentication>
  <ProofOfPossession>
    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
      <SignedInfo>
        <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
        <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
        <Reference URI="#I269e655567dbae568591c0a06957529e">
          <Transforms>
            <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
          </Transforms>
          <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
          <DigestValue>WCbpkifxJ1zIJ+V6/knZgxRhR34=</DigestValue>
        </Reference>
      </SignedInfo>
      <SignatureValue>
        DcPw742vN120QNrCjCKw0jiCX3pUvbMeRkYjktZkn4nbgo1b7leXU0sJgXM2CY/
        oQugaRsgz18+qUzM0UX+jr1t1wtCMci5fjzVKZB63oZyKZ9+CJLcBCbirsgJAId
        +Pq9w4WiwKDf2AytsdXHlN5V1byQIkpfR1CypvBzQa1b4=
      </SignatureValue>
    </Signature>
  </ProofOfPossession>
</RegisterRequest>

[246]The service accepts the registration and returns the following response:

<?xml version="1.0" encoding="utf-8"?>
<RegisterResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I92ed24772e43843b3d23020ad9ec9754"
      Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success"
      RequestId="I405683d6514a46852417bae2ed94c117"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <KeyBinding Id="Ia26450ebe93f62b3b3ab137fc6a61c36">
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>MIICEDCCAX2gAwIBAgIQimXeUAxYJbJMady9vV1bLjAJBgUrD
              gMCHQUAMBIxEDAOBgNVBAMTB1Rl
c3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5WjArMSkwJwYDVQQDEyBBbGljZSBB
YXJkdmFyayBPPUFsaWNlIENvcnAgQz1VUzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0nIs
mR+aVW2egl5MIfOKy4HuMKkk9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgGthO6U9D
0CNT5mbmhIAErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQggP
BLc1XagW20RMvokCAwEAAaNWMFQwDQYDVR0KBAYwBAMCBkAwQwYDVR0BBDwwOoAQAaVOkaVLLKoF
mLN37pC8uqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEC4MndUXjPG1TZxVKg+HutAwCQYFKw4DAh0F
AAOBgQABU91ka7IlkXCfv4Zh2Ohwgg2yObtY3+6C/BTFGrOEBJDy+DoxJ/NuBF18w3rrrR18xE6j
NKYLCQb8zUGk4QOG5Y+HT/QTTFvWkiOLXcpTuhnOhXatr42FoYpDkjx2QWK+J5Q2l/Rgjgc/0ZV8
U/kD8UuRkXp4AZh7QsiX8AcO0w==</ds:X509Certificate>
        <ds:X509Certificate>MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrD
              gMCHQUAMBIxEDAOBgNVBAMTB1Rl
c3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWjASMRAwDgYDVQQDEwdUZXN0IENB
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEk
eXB8oMxwbhdcizWH92zrtm1VfVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVR
NK5XmKXA5sEC51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBgNV
HQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQMA4GA1UEAxMHVGVz
dCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GBABDYD4Fwx2dscu+BgYcZ+GoQQtCJ
kwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsiQgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/
MefuTtpOpCN40wy3YwwngDtHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435</ds:X509
      Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <KeyUsage>Signature</KeyUsage>
    <KeyUsage>Encryption</KeyUsage>
    <KeyUsage>Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2459" Identifier="C=&quot;US&quot;
          O=&quot;Alice Corp&quot; CN=&quot;Alice Aardvark&quot;" />
    <UseKeyWith Application="urn:ietf:rfc:2633"
          Identifier="alice@alicecorp.test" />
    <UseKeyWith Application="http://ca.example.com/cps/20030401/class3"
          Identifier="alice@alicecorp.test" />
    <Status StatusValue="Valid">
      <ValidReason>Signature</ValidReason>
      <ValidReason>IssuerTrust</ValidReason>
      <ValidReason>RevocationStatus</ValidReason>
      <ValidReason>ValidityInterval</ValidReason>
    </Status>
  </KeyBinding>
</RegisterResult>
<?xml version="1.0" encoding="utf-8"?>
<RegisterResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I92ed24772e43843b3d23020ad9ec9754"
      Service="http://test.xmltrustcenter.org/XKMShttp://www.example.org/XKMS"
      ResultMajor="http://www.w3.org/2002/03/xkms#Success"
      RequestId="I1494ac4351b7de5c174d455b7000e18f"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <KeyBinding Id="Ia26450ebe93f62b3b3ab137fc6a61c36">
    <ds:KeyInfo>
      <ds:X509Data>
        <ds: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==
        </ds:X509Certificate>
        <ds:X509Certificate>
          MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAMBIxEDA
          OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWj
          ASMRAwDgYDVQQDEwdUZXN0IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg
          QCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEkeXB8oMxwbhdcizWH92zrtm1V
          fVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVRNK5XmKXA5sE
          C51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBg
          NVHQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQM
          A4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GB
          ABDYD4Fwx2dscu+BgYcZ+GoQQtCJkwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsi
          QgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/MefuTtpOpCN40wy3YwwngD
          tHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435
        </ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2459" Identifier="C="US"
          O="Alice Corp" CN="Alice Aardvark"" />
    <UseKeyWith Application="urn:ietf:rfc:2633"
          Identifier="alice@example.com" />
    <UseKeyWith Application="http://ca.example.com/cps/20030401/class3"
          Identifier="alice@example.com" />
    <Status StatusValue="http://www.w3.org/2002/03/xkms#Valid">
      <ValidReason>http://www.w3.org/2002/03/xkms#Signature</ValidReason>
      <ValidReason>http://www.w3.org/2002/03/xkms#IssuerTrust</ValidReason>
      <ValidReason>http://www.w3.org/2002/03/xkms#RevocationStatus</ValidReason>
      <ValidReason>http://www.w3.org/2002/03/xkms#ValidityInterval</ValidReason>
    </Status>
  </KeyBinding>
</RegisterResult>

6.1.2 Example: Registration of Service-Generated Key Pair

[247]The request for registration of a service generated key pair omits the public key data and requests that private key data be returned with the response.

[248]Bob requests a server generated key pair after receiving the authentication code 3n9cj-jk4jk-s04jf-20934-jsr09-jwik4 through some out-of-band mechanism.  The request specifies only Encryption and Exchange key uses as the key is to be escrowed for possible later recovery and the security policy of the issuer does not allow escrow of signature keys. 

[249]The server generates a public-private key pair in response to the request, generates appropriate certifications, and returns the result to the client.  The result includes the private key value encrypted using a key derived from the authentication code value as described in Section 8.1; see also Appendix C. 1.3.; The client can decrypt the private key by computing the decryption key from the authentication code value in the same manner as the service. 

[250]To avoid leaking the private key value to unauthorized entities it is critical that the service and client protect the authentication code value from disclosure.  The service should not reuse authentication code values nor should the key derived from an authentication code be used to encrypt more than a single private key communication.

[251]The calculation of the authentication data and encryption of the private key for this example is shown in Appendix C.

[252]The response includes both the public key data and the encrypted private key:

<?xml version="1.0" encoding="utf-8"?>
<RegisterResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I2eb0b29bf38eeecfc5f099c8ca149f98"
      Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success"
      RequestId="I4e442fc461a83f320d7a3afb4f2454a9"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <KeyBinding Id="Ia500663f4e4e578447407a38b9049c8b">
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>MIICCTCCAXagAwIBAgIQe0Sk4xr1VolGFFNMkCx07TAJBgUrD
              gMCHQUAMBIxEDAOBgNVBAMTB1Rl
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</ds:X509Certificate>
        <ds:X509Certificate>MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrD
              gMCHQUAMBIxEDAOBgNVBAMTB1Rl
c3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWjASMRAwDgYDVQQDEwdUZXN0IENB
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEk
eXB8oMxwbhdcizWH92zrtm1VfVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVR
NK5XmKXA5sEC51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBgNV
HQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQMA4GA1UEAxMHVGVz
dCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GBABDYD4Fwx2dscu+BgYcZ+GoQQtCJ
kwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsiQgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/
MefuTtpOpCN40wy3YwwngDtHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435</ds:X509
      Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <KeyUsage>Encryption</KeyUsage>
    <KeyUsage>Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2459" Identifier="C=&quot;UK&quot;
          O=&quot;Bob Corp&quot; CN=&quot;Bob Baker&quot;" />
    <UseKeyWith Application="urn:ietf:rfc:2633"
          Identifier="bob@bobcorp.test" />
    <Status StatusValue="Valid">
      <ValidReason>Signature</ValidReason>
      <ValidReason>IssuerTrust</ValidReason>
      <ValidReason>RevocationStatus</ValidReason>
      <ValidReason>ValidityInterval</ValidReason>
    </Status>
  </KeyBinding>
  <PrivateKey>
    <xenc:EncryptedData>
      <xenc:EncryptionMethod
            Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
      <xenc:CipherData>
        <xenc:CipherValue>Hnp23IfB9Vpt5f4A6392Lqk3+h+Y999rJhpiexi+xXEWokE1ntr
              0Z4q4u36hRy0PPmAUSs8JbFdE
U+G+zxvH4CLbr8wL4MMWvidEZJhMbEyQE3Z8FmQmbysboFGUpqx1327fTAqhCRW1MHtMiWk1O78k
WI5dfaMYCJ+dXEF4Jcu3JQ59K8k1ZIfkn/Q/3oyhS6MnoRNrlatdkd0xrKlJ/wXrnx09r0FTBqTz
2FjAboG5ockHg43CEBJc7giPESBN1MnTeaL70ko1XHvFpx1pA6J5o+vUjv3Jt34PD0BLoC+T1j68
pYhHgVX2z0Nc0DLYm0BGuvdjjZBXEcBztYO29xhrEj6Xhs56t+qfB9b5tyGhGZlNvmGwEN4gEcda
DneFFbhEco2cM7rfmGwVE7HYoa7akzWaDixUZ0S/7BcekZwWYAxbmJaKsaeiyEJO7Fz2M3Ie+Eq0
XItbtlWeIRJJz8qgMMIcgydMRfyEiMjsbzjBj4Sur5tIG5KLbCYavupknTIHOfzIPOYZcDhRJ8+P
/bg/PBRRchE+Z/0FV6/VMF64KDgBpy6FQQeNiA4gTYDLmpKTJtap9vbKQxwUFrLwZhOSufVOwx0z
ZXoJ2uHEr0qVybdJt9hKV8gNKXEGkk1K1enDZHJzmu8XpWdPcIj1De7iOOeXKUN0iZb4Bth/Wqs/
K5SQHl9HCH2hpsiuu3u3wPn18pH7GKEtD2DHkXtrgx86QPwwcHAkON/cktOQAcnjrfvRRsuPmTmi
VGR6/XJ7gLmOUmUFTJAuZ39J0igttbEKEzTaq+RJ/6ZyfxTlZ8V78q6xadh27nSVHwSvpM0EdBJL
U+lED0dV7wuUFIkwAaJDbuj2bOFOcsAuaAfWTp+E+PdFNPkBjHlML82jk+9UMyKFwUdPYd6fExEu
k4DmjanW+IvymmPWfkFWcTS4gQF/2RxEmnPMVz1+sumYmIBucyYyYYthZph/94uaBaT3LzNXk08s
II7j3ICqZLCxL0QGbPwzOmEHWeumcPP6xND04lqc43+1KYf/IykI1zjbqNdGIsKAbGgkm+4jme+a
S8eaOGTEe4Topf/r2Krd8XdCf4n1E3pzhaKG7vE2UID6GVDek9KyS9ib54/5kcFzXgBJYhOM4Sx5
TJBJsCKbCB15XRJhevlMW7MT0SmThbLG0aQfw8i1eEZsYzhQQtY4Uy6HwnBmTZQN88fSGpqL9jgv
Ec79Vswmu+9QDrvH1zceN4uQ9FpMxywOBX1d4t8cr6outVy5kXZNRqy9s9HYUCGynu1QuO7dg9Ch
IV6yxxJCs1S2P9uOp5p/FeDagUNss9ciIqRCt+aWUp2s+0fpST6gNp3xrCw0/OAqi3jR4akHvpJD
4pzALT2U6TZrqP7BTCZT28JdPJTli3Oo5b472nxFGd49JoPWxbc=</xenc:CipherValue>
      </xenc:CipherData>
    </xenc:EncryptedData>
  </PrivateKey>
</RegisterResult>
<?xml version="1.0" encoding="utf-8"?>
<RegisterResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I2eb0b29bf38eeecfc5f099c8ca149f98"
      Service="http://test.xmltrustcenter.org/XKMShttp://www.example.org/XKMS"
      ResultMajor="http://www.w3.org/2002/03/xkms#Success"
      RequestId="I4e442fc461a83f320d7a3afb4f2454a9"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <KeyBinding Id="Ia500663f4e4e578447407a38b9049c8b">
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>
          MIICCTCCAXagAwIBAgIQe0Sk4xr1VolGFFNMkCx07TAJBgUrDgMCHQUAMBIxEDA
          OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj
          AkMSIwIAYDVQQDExlCb2IgQmFrZXIgTz1Cb2IgQ29ycCBDPVVTMIGfMA0GCSqGS
          Ib3DQEBAQUAA4GNADCBiQKBgQDcUW1ZSy8RqNC3ZJ5IX5G8DFZ08+HkZKVCenxI
          O++q8LATo9dxFasgaZXu3A1/ZNRcLFi7O1RQKUwjLXgHRD6TV6Pad6SZgvv4hzc
          MMZUVVpg+jFpFjRjaVXy06t7KdZ6CkVshNdzxXpjTZB9Hk7s+fX/XQSWyVoX9MX
          wxAapgTwIDAQABo1YwVDANBgNVHQoEBjAEAwIGQDBDBgNVHQEEPDA6gBABpU6Rp
          UssqgWYs3fukLy6oRQwEjEQMA4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUq
          D4e60DAJBgUrDgMCHQUAA4GBAF4jP1gGDbaq3rg/Vo3JY7EDNTp0HmwLiPMLmdn
          B3WTIGFcjS/jZFzRCbvKPeiPTZ6kRkGgydFOuCo5HMAxIks/LtnKFd/0qYT+AOD
          q/rCrwSx+F+Ro2rf9tPpja9o7gANqxs6Pm7f1QSPZO57bT/6afiVm7NdaCfjgMp
          hb+XNyn
        </ds:X509Certificate>
        <ds:X509Certificate>
          MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAMBIxEDA
          OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWj
          ASMRAwDgYDVQQDEwdUZXN0IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg
          QCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEkeXB8oMxwbhdcizWH92zrtm1V
          fVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVRNK5XmKXA5sE
          C51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBg
          NVHQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQM
          A4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GB
          ABDYD4Fwx2dscu+BgYcZ+GoQQtCJkwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsi
          QgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/MefuTtpOpCN40wy3YwwngD
          tHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435
        </ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2459" Identifier="C="UK"
          O="Bob Corp" CN="Bob Baker"" />
    <UseKeyWith Application="urn:ietf:rfc:2633"
          Identifier="bob@example.com" />
    <Status StatusValue="http://www.w3.org/2002/03/xkms#Valid">
      <ValidReason>http://www.w3.org/2002/03/xkms#Signature</ValidReason>
      <ValidReason>http://www.w3.org/2002/03/xkms#IssuerTrust</ValidReason>
      <ValidReason>http://www.w3.org/2002/03/xkms#RevocationStatus</ValidReason>
      <ValidReason>http://www.w3.org/2002/03/xkms#ValidityInterval</ValidReason>
    </Status>
  </KeyBinding>
  <PrivateKey>
    <xenc:EncryptedData>
      <xenc:EncryptionMethod
            Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
      <xenc:CipherData>
        <xenc:CipherValue>
          RkJLNT/68R4/vq35DIvQkf59O2azcRagKlQ1HessbhsGb/sWMzpNcnBmiGU9s9u
          VUBQz1BPwWw73LJ7F8rbnCGorC73Jv+BssH0GSdwdRnm0nn/0smMc3Kc1QlS2GX
          zfm8a1B1DZxWlMgei8506jURU/BeAUH7zR2QG7mCjteAB/n6B4SdqGzmKPvIZXp
          6Wz9QCGaoB1GVkmYa1Btoe9DkfN91BblvSmE64DIqAuATwQjKNm56lDmGnY0H49
          fGGIpyZJfIsyKPbLTu8WOPNoyw8OmPeEpJLg18lBHKXcSUzglp4xH+L+henXNz8
          meHbW8DjllP/NX6KSek1sJ+mcOW9t6aSmBj4Q7HeFxhgGr1n7letNJN3TAT/ISx
          JevmWLg4nPRXavU03MUfn42f5nSk1MF0O+75DVVHPQJD3t08PB/HC+vuxsqzaSr
          o3DgN2vy4btehJ7EbVufwIOnS1R7TvxenpnSrfT3lI9UA6sVly1Rn7En8LxfUPJ
          1MNHS4a3rBI137LE/ocrvO9mUusGLWJoFyNBaYByv0YcQXvq5Wv0DfaErV4C7vu
          NnuH5Vyb2KInKe0hyI50Kz4RpfTPkk58kJWBwmeHIPfT3yGXZH15B/uGk4Au62h
          Bd4o0qUD+Okj+wfNlyNpq0HPe9jTaafpaxaEh/jWf7fZxTvo7Fo/pQpeHsekkDw
          0NH1kMSoWKlZRiyVv/kk9zNsa3Jh76XX8kwiGuWEQi174xhysB+T4p6MpPxmdaW
          yxKEft7MeYTQ1+OfMR8bYWAzUmXxvWDp7LuLaJkEL2AcZN4m4fj9Ws0ihuc5LnC
          /NAax71QlSc8RRGIdEhGuSHQo7WURvjrXWzVgCNgq+M8/MMLvitXlEdWaZyNUPA
          AbeSzFb7vF+5Hm27m1O6N1vrr9b2mQCRvzYtDNc8mbKQFBUy+yc3Z038eY3fcrz
          YQf6iapww76Bbxb2ojTpWzbSFhjT+RNCYWWjKFHxqp3ipOjFOHnGg1T+eounhqA
          U01EoWJIqxm8AxF0UCma/jFdKuflvnhWymVsM68O8A0yiWOtbstl2xOGzVJx5FP
          WVxz3x+X+hGhEwupPso1cHfntFnm8K+vB+M5YpcfOQAKMDIqJ4GtGgMwa6Yr0CD
          UdxE0m20n8KVtR9+uwLPQFKLNQnZAJttjICJ6uGPOT/UFHdDlBwhcG5L9pJbsnk
          8TyEPjGSuHEJxmYU1wPtCIumR8gL77++6W/VWJhUvczU6Yk8r28D1GaJEYpaNae
          hv6bxz6//g+p5qoECY7PsdAr5TSKN5w0ocdXPw3KYkeR7LTroeiLvjGM0/NQicz
          SAadjoXOSLLSuHc7+HqqGLoFMoUU7sln4l/q/1Zc3dDyjeEWKbGeZwWRCHoVKpz
          +VtWNyvud5YC/Y5mUZx2Xwd0FT6geop/Tp5ML7HopMw2SmKNGFtvk7jMDaCS0RD
          wERu/lC+oLLWjzZP0cMvDjxKKKn1ug5i8aXQe9Zbfe9kt7IQpQjOkvTPLXtoznO
          tGuwtpHqFfwp+iQGY8/aW8JUNqrINB361k120//zntSFRWd8+DmTRB2VG/ul3l/
          RrmLk2ZU6gMO8EcuZHTNqSJ3QS2ax3gpRjQ5mdkg02VCTn6NINA4rfIvLINX22G
          mc9qLiDp2HlUf7yg==
        </xenc:CipherValue>
      </xenc:CipherData>
    </xenc:EncryptedData>
  </PrivateKey>
</RegisterResult>

6.2 Reissue

[253]A Registration service MAY permit clients to reissue previously issued key bindings. A reissue request is similar to the initial registration of a key.

[254]The principal reason a client would make a Reissue request is to cause the registration service to generate new credentials in the underlying PKI, e.g. X.509 Certificates.

6.2.1 Example: Reissue

[255]Alice requests reissue of her previously issued RSA key pair for her email address.

[256]The X-KRSS request message contains the following <ReissueRequest> element:

<?xml version="1.0" encoding="utf-8"?>
<ReissueRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I3a682dfb94cc8e9b3b648026783a8094"
      Service="http://test.xmltrustcenter.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>X509Cert</RespondWith>
  <RespondWith>X509Chain</RespondWith>
  <ReissueKeyBinding Id="I518fc89b03369bccec3d1ee9d985c436">
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>MIICEDCCAX2gAwIBAgIQimXeUAxYJbJMady9vV1bLjAJBgUrD
              gMCHQUAMBIxEDAOBgNVBAMTB1Rl
c3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5WjArMSkwJwYDVQQDEyBBbGljZSBB
YXJkdmFyayBPPUFsaWNlIENvcnAgQz1VUzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0nIs
mR+aVW2egl5MIfOKy4HuMKkk9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgGthO6U9D
0CNT5mbmhIAErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQggP
BLc1XagW20RMvokCAwEAAaNWMFQwDQYDVR0KBAYwBAMCBkAwQwYDVR0BBDwwOoAQAaVOkaVLLKoF
mLN37pC8uqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEC4MndUXjPG1TZxVKg+HutAwCQYFKw4DAh0F
AAOBgQABU91ka7IlkXCfv4Zh2Ohwgg2yObtY3+6C/BTFGrOEBJDy+DoxJ/NuBF18w3rrrR18xE6j
NKYLCQb8zUGk4QOG5Y+HT/QTTFvWkiOLXcpTuhnOhXatr42FoYpDkjx2QWK+J5Q2l/Rgjgc/0ZV8
U/kD8UuRkXp4AZh7QsiX8AcO0w==</ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <Status StatusValue="Valid" />
  </ReissueKeyBinding>
  <Authentication>
    <KeyBindingAuthentication>
      <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
        <SignedInfo>
          <CanonicalizationMethod
                Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
          <SignatureMethod
                Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1" />
          <Reference URI="#I518fc89b03369bccec3d1ee9d985c436">
            <Transforms>
              <Transform
                    Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
                <ec:InclusiveNamespaces PrefixList="ds xenc #default"
                      xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" />
              </Transform>
            </Transforms>
            <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
                  />
            <DigestValue>OWkEq0XQbJdF0dkWL92g8h+MiMc=</DigestValue>
          </Reference>
        </SignedInfo>
        <SignatureValue>gWLlIlAHxUlK9+kOoA9uKBbDovg=</SignatureValue>
      </Signature>
    </KeyBindingAuthentication>
  </Authentication>
  <ProofOfPossession>
    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
      <SignedInfo>
        <CanonicalizationMethod
              Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
        <SignatureMethod
              Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
        <Reference URI="#I518fc89b03369bccec3d1ee9d985c436">
          <Transforms>
            <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
              <ec:InclusiveNamespaces PrefixList="ds xenc #default"
                    xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" />
            </Transform>
          </Transforms>
          <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
                />
          <DigestValue>G7f1KNtaCkZg+q4djq2AboFkQAo=</DigestValue>
        </Reference>
      </SignedInfo>
      <SignatureValue>nxOg/dUXElTrHgSiOcr39nCXYimzTS52Fm+vjIB3Hf9RtaGReUcpCP6
            pTUX2KJ/Na69o9GzWfxjh65DISpJj9qDlKIs4c2yldg/jbzT7ifek+8aZDXz7t6Rw
            /834PLINRqkT7kRoQqPEcFt+5t8/H2FG/eBV0hko1FarPXEaWYs=</SignatureVa
            lue>
    </Signature>
  </ProofOfPossession>
</ReissueRequest>
<?xml version="1.0" encoding="utf-8"?>
<ReissueRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I3a682dfb94cc8e9b3b648026783a8094"
      Service="http://test.xmltrustcenter.org/XKMShttp://www.example.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>http://www.w3.org/2002/03/xkms#X509Cert</RespondWith>
  <RespondWith>http://www.w3.org/2002/03/xkms#X509Chain</RespondWith>
  <ReissueKeyBinding Id="I518fc89b03369bccec3d1ee9d985c436">
    <ds:KeyInfo>
      <ds:X509Data>
        <ds: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==
        </ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <Status StatusValue="http://www.w3.org/2002/03/xkms#Valid" />
  </ReissueKeyBinding>
  <Authentication>
    <KeyBindingAuthentication>
      <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
        <SignedInfo>
          <CanonicalizationMethod
                Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
          <SignatureMethod
                Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1" />
          <Reference URI="#I518fc89b03369bccec3d1ee9d985c436">
            <Transforms>
              <Transform
                    Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
                <ec:InclusiveNamespaces PrefixList="ds xenc #default"
                      xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" />
              </Transform>
            </Transforms>
            <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
            <DigestValue>qnhsUF9RMxxGydG/5KdJjWhtBFE=</DigestValue>
          </Reference>
        </SignedInfo>
        <SignatureValue>+gKw3b0qi9BaIqmN1gIyvj1UxRs=</SignatureValue>
      </Signature>
    </KeyBindingAuthentication>
  </Authentication>
  <ProofOfPossession>
    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
      <SignedInfo>
        <CanonicalizationMethod
              Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
        <SignatureMethod
              Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
        <Reference URI="#I518fc89b03369bccec3d1ee9d985c436">
          <Transforms>
            <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
              <ec:InclusiveNamespaces PrefixList="ds xenc #default"
                    xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" />
            </Transform>
          </Transforms>
          <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
                />
          <DigestValue>qnhsUF9RMxxGydG/5KdJjWhtBFE=</DigestValue>
        </Reference>
      </SignedInfo>
      <SignatureValue>
sP/RWAA7fnv86ZgwOlfxTwN05akxyf65rCw7rwXNkJmx0fxUNFJ+qKDqmIh2KyvFyBut6FredSXj
t3iDIXUKMmjA2/VPGEX8yyd71DbRqf9dXb2FzkvkKrCbYumlavbrChpEwiMUqk2rd5tjkFAZjYRA
tuURoFfmoOYY/M+mNUU=
      </SignatureValue>
    </Signature>
  </ProofOfPossession>
</ReissueRequest>

[257]The service accepts the registration and returns the following response:

<?xml version="1.0" encoding="utf-8"?>
<ReissueResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I4f0f13b32e4f43f0c1b390b5186fa997"
      Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success"
      RequestId="I3a682dfb94cc8e9b3b648026783a8094"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <KeyBinding Id="I9a894fff4149d2351c24241886e3900e">
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>MIICEDCCAX2gAwIBAgIQimXeUAxYJbJMady9vV1bLjAJBgUrD
              gMCHQUAMBIxEDAOBgNVBAMTB1Rl
c3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5WjArMSkwJwYDVQQDEyBBbGljZSBB
YXJkdmFyayBPPUFsaWNlIENvcnAgQz1VUzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0nIs
mR+aVW2egl5MIfOKy4HuMKkk9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgGthO6U9D
0CNT5mbmhIAErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQggP
BLc1XagW20RMvokCAwEAAaNWMFQwDQYDVR0KBAYwBAMCBkAwQwYDVR0BBDwwOoAQAaVOkaVLLKoF
mLN37pC8uqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEC4MndUXjPG1TZxVKg+HutAwCQYFKw4DAh0F
AAOBgQABU91ka7IlkXCfv4Zh2Ohwgg2yObtY3+6C/BTFGrOEBJDy+DoxJ/NuBF18w3rrrR18xE6j
NKYLCQb8zUGk4QOG5Y+HT/QTTFvWkiOLXcpTuhnOhXatr42FoYpDkjx2QWK+J5Q2l/Rgjgc/0ZV8
U/kD8UuRkXp4AZh7QsiX8AcO0w==</ds:X509Certificate>
        <ds:X509Certificate>MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrD
              gMCHQUAMBIxEDAOBgNVBAMTB1Rl
c3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWjASMRAwDgYDVQQDEwdUZXN0IENB
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEk
eXB8oMxwbhdcizWH92zrtm1VfVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVR
NK5XmKXA5sEC51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBgNV
HQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQMA4GA1UEAxMHVGVz
dCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GBABDYD4Fwx2dscu+BgYcZ+GoQQtCJ
kwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsiQgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/
MefuTtpOpCN40wy3YwwngDtHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435</ds:X509
      Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <KeyUsage>Signature</KeyUsage>
    <KeyUsage>Encryption</KeyUsage>
    <KeyUsage>Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2633"
          Identifier="alice@alicecorp.test" />
    <Status StatusValue="Valid">
      <ValidReason>Signature</ValidReason>
      <ValidReason>IssuerTrust</ValidReason>
      <ValidReason>RevocationStatus</ValidReason>
      <ValidReason>ValidityInterval</ValidReason>
    </Status>
  </KeyBinding>
</ReissueResult>
<?xml version="1.0" encoding="utf-8"?>
<ReissueResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I4f0f13b32e4f43f0c1b390b5186fa997"
      Service="http://test.xmltrustcenter.org/XKMShttp://www.example.org/XKMS"
      ResultMajor="http://www.w3.org/2002/03/xkms#Success"
      RequestId="I3a682dfb94cc8e9b3b648026783a8094"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <KeyBinding Id="I9a894fff4149d2351c24241886e3900e">
    <ds:KeyInfo>
      <ds:X509Data>
        <ds: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==
        </ds:X509Certificate>
        <ds:X509Certificate>
          MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAMBIxEDA
          OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWj
          ASMRAwDgYDVQQDEwdUZXN0IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg
          QCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEkeXB8oMxwbhdcizWH92zrtm1V
          fVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVRNK5XmKXA5sE
          C51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBg
          NVHQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQM
          A4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GB
          ABDYD4Fwx2dscu+BgYcZ+GoQQtCJkwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsi
          QgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/MefuTtpOpCN40wy3YwwngD
          tHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435
        </ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>
    <KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2633"
          Identifier="alice@example.com" />
    <Status StatusValue="http://www.w3.org/2002/03/xkms#Valid">
      <ValidReason>http://www.w3.org/2002/03/xkms#Signature</ValidReason>
      <ValidReason>http://www.w3.org/2002/03/xkms#IssuerTrust</ValidReason>
      <ValidReason>http://www.w3.org/2002/03/xkms#RevocationStatus</ValidReason>
      <ValidReason>http://www.w3.org/2002/03/xkms#ValidityInterval</ValidReason>
    </Status>
  </KeyBinding>
</ReissueResult>

6.3 Revocation

[258]A Registration service MAY permit clients to revoke previously issued key bindings. A revocation request need only contain sufficient information to identify the key binding to be revoked and the authority for the revocation request.

[259]If an XKMS key binding is bound to a data object in an underlying PKI the revocation of the key binding SHOULD result in the revocation of the underlying data object. For example if the XKMS key binding is bound to an X.509 certificate the revocation of the key binding SHOULD result in revocation of the underlying certificate.

6.3.1 Example: Revocation

[260]For some reason Alice requests the registration service revoke the binding for her public key. Alice authenticates herself using the pass phrase value established during registration.

[261]The request message is:

<?xml version="1.0" encoding="utf-8"?>
<RevokeRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I2aa2c2f37195c9c4364c55f15df68091"
      Service="http://test.xmltrustcenter.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RevokeKeyBinding Id="Ie91dfbf1c948d5cf142099676968caf1">
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>MIICEDCCAX2gAwIBAgIQimXeUAxYJbJMady9vV1bLjAJBgUrD
              gMCHQUAMBIxEDAOBgNVBAMTB1Rl
c3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5WjArMSkwJwYDVQQDEyBBbGljZSBB
YXJkdmFyayBPPUFsaWNlIENvcnAgQz1VUzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0nIs
mR+aVW2egl5MIfOKy4HuMKkk9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgGthO6U9D
0CNT5mbmhIAErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQggP
BLc1XagW20RMvokCAwEAAaNWMFQwDQYDVR0KBAYwBAMCBkAwQwYDVR0BBDwwOoAQAaVOkaVLLKoF
mLN37pC8uqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEC4MndUXjPG1TZxVKg+HutAwCQYFKw4DAh0F
AAOBgQABU91ka7IlkXCfv4Zh2Ohwgg2yObtY3+6C/BTFGrOEBJDy+DoxJ/NuBF18w3rrrR18xE6j
NKYLCQb8zUGk4QOG5Y+HT/QTTFvWkiOLXcpTuhnOhXatr42FoYpDkjx2QWK+J5Q2l/Rgjgc/0ZV8
U/kD8UuRkXp4AZh7QsiX8AcO0w==</ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <Status StatusValue="Indeterminate" />
  </RevokeKeyBinding>
  <RevocationCode>PHx8li2SUhrJv2e1DyeWbGbD6rs=</RevocationCode>
</RevokeRequest>
<?xml version="1.0" encoding="utf-8"?>
<RevokeRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I2aa2c2f37195c9c4364c55f15df68091"
      Service="http://test.xmltrustcenter.org/XKMShttp://www.example.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RevokeKeyBinding Id="Ie91dfbf1c948d5cf142099676968caf1">
    <ds:KeyInfo>
      <ds:X509Data>
        <ds: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==
        </ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <Status StatusValue="http://www.w3.org/2002/03/xkms#Indeterminate" />
  </RevokeKeyBinding>
  <RevocationCode>PHx8li2SUhrJv2e1DyeWbGbD6rs=</RevocationCode>
</RevokeRequest>

[262]The service responds that the key binding has been revoked:

<?xml version="1.0" encoding="utf-8"?>
<RevokeResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I252433a097631dca9a2775493f39c7d7"
      Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success"
      RequestId="I2aa2c2f37195c9c4364c55f15df68091"
      xmlns="http://www.w3.org/2002/03/xkms#" />
<?xml version="1.0" encoding="utf-8"?>
<RevokeResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I252433a097631dca9a2775493f39c7d7"
      Service="http://test.xmltrustcenter.org/XKMShttp://www.example.org/XKMS"
      ResultMajor="http://www.w3.org/2002/03/xkms#Success"
      RequestId="I2aa2c2f37195c9c4364c55f15df68091"
      xmlns="http://www.w3.org/2002/03/xkms#" />

6.4 Key Recovery

[263]A Registration service MAY support key recovery. For key recovery to be possible the private key to be recovered MUST have been previously escrowed with the recovery service, for example by means of the XKRSS registration of a server generated key. A key recovery request is similar to the initial registration of a key except that since the registration service might not have a record of the key binding to be recovered the result code NotFound MAY be returned.

[264]The key recovery service is likely to require time to respond to the recovery request. Clients supporting key recovery SHOULD support asynchronous processing.

[265]The security policy of the issuer MAY consider the key recovery process itself as an actual or potential compromise of the recovered key and thus require the revocation of all associated key bindings, particularly if the key recovery was requested by a third party such as the supervisor of the key holder.

6.4.1 Example: Key Recovery

[266]Bob has forgotten the private key which he obtained in the earlier registration example. He first contacts the administrator of the key recovery service using an out-of-band authentication procedure determined by site policy. The key recovery administrator issues to Bob (using an out of band method) the key recovery authorization code "A8YUT VUHHU C9H29 8Y43U H9J3I 23". In this case the code is read over the telephone and so it would be inconvenient to be required to specify spacing between the code blocks or capitalization.

[267]The request parameters for the key recovery are:

<?xml version="1.0" encoding="utf-8"?>
<RecoverRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I66f40510c322d281602ce76b9eb04d7d"
      Service="http://test.xmltrustcenter.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>PrivateKey</RespondWith>
  <RecoverKeyBinding Id="I29cb8ac8a2ad878f7be44edfe53ea77a">
    <ds:KeyInfo>
      <ds:KeyValue>
        <ds:RSAKeyValue>
          <ds:Modulus>3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGm
                V7twNf2TUXCxYuztUUClM
Iy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreynWegpFbITXc8V6Y02QfR5O7Pn1/
10ElslaF/TF8MQGqYE8=</ds:Modulus>
          <ds:Exponent>AQAB</ds:Exponent>
        </ds:RSAKeyValue>
      </ds:KeyValue>
    </ds:KeyInfo>
    <Status StatusValue="Indeterminate" />
  </RecoverKeyBinding>
  <Authentication>
    <KeyBindingAuthentication>
      <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
        <SignedInfo>
          <CanonicalizationMethod
                Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
          <SignatureMethod
                Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1" />
          <Reference URI="#I29cb8ac8a2ad878f7be44edfe53ea77a">
            <Transforms>
              <Transform
                    Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
                <ec:InclusiveNamespaces PrefixList="ds xenc #default"
                      xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" />
              </Transform>
            </Transforms>
            <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
                  />
            <DigestValue>tNA4xmGf0tqRs5yq0P+rJjHMgIw=</DigestValue>
          </Reference>
        </SignedInfo>
        <SignatureValue>XgTJuf7kj02SzJMLJfG6cu/mtwU=</SignatureValue>
      </Signature>
    </KeyBindingAuthentication>
  </Authentication>
</RecoverRequest>
<?xml version="1.0" encoding="utf-8"?>
<RecoverRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="I66f40510c322d281602ce76b9eb04d7d"
      Service="http://test.xmltrustcenter.org/XKMShttp://www.example.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>http://www.w3.org/2002/03/xkms#PrivateKey</RespondWith>
  <RecoverKeyBinding Id="I29cb8ac8a2ad878f7be44edfe53ea77a">
    <ds:KeyInfo>
      <ds:KeyValue>
        <ds:RSAKeyValue>
          <ds:Modulus>
            3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV7twNf2T
            UXCxYuztUUClMIy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreyn
            WegpFbITXc8V6Y02QfR5O7Pn1/10ElslaF/TF8MQGqYE8=
          </ds:Modulus>
          <ds:Exponent>AQAB</ds:Exponent>
        </ds:RSAKeyValue>
      </ds:KeyValue>
    </ds:KeyInfo>
    <Status StatusValue="http://www.w3.org/2002/03/xkms#Indeterminate" />
  </RecoverKeyBinding>
  <Authentication>
    <KeyBindingAuthentication>
      <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
        <SignedInfo>
          <CanonicalizationMethod
                Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
          <SignatureMethod
                Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1" />
          <Reference URI="#I29cb8ac8a2ad878f7be44edfe53ea77a">
            <Transforms>
              <Transform
                    Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
                <ec:InclusiveNamespaces PrefixList="ds xenc #default"
                      xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" />
              </Transform>
            </Transforms>
            <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
            <DigestValue>GfV3xa/OL6EQAoo5sFL/nHQJCeo=</DigestValue>
          </Reference>
        </SignedInfo>
        <SignatureValue>jG40xPdcouZSgYjRr47gRv+oEc0=</SignatureValue>
      </Signature>
    </KeyBindingAuthentication>
  </Authentication>
</RecoverRequest>

[268]The policy of this particular registration service is to revoke a private key whenever key recovery is performed. A registration service might adopt a revoke on recover policy for a number of reasons which include concern that the recovery process might be considered to have compromised the key in some way.  The service returns the revoked key binding and the private key parameters:

<?xml version="1.0" encoding="utf-8"?>
<RecoverResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="Iacd24dbd4b3c79660f4d26aca7aaaea2"
      Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success"
      RequestId="I66f40510c322d281602ce76b9eb04d7d"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <KeyBinding Id="I29cb8ac8a2ad878f7be44edfe53ea77a">
    <ds:KeyInfo>
      <ds:KeyValue>
        <ds:RSAKeyValue>
          <ds:Modulus>3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGm
                V7twNf2TUXCxYuztUUClM
Iy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreynWegpFbITXc8V6Y02QfR5O7Pn1/
10ElslaF/TF8MQGqYE8=</ds:Modulus>
          <ds:Exponent>AQAB</ds:Exponent>
        </ds:RSAKeyValue>
      </ds:KeyValue>
    </ds:KeyInfo>
    <Status StatusValue="Invalid">
      <InvalidReason>Signature</InvalidReason>
      <InvalidReason>IssuerTrust</InvalidReason>
      <InvalidReason>RevocationStatus</InvalidReason>
      <InvalidReason>ValidityInterval</InvalidReason>
    </Status>
  </KeyBinding>
  <PrivateKey>
    <xenc:EncryptedData>
      <xenc:EncryptionMethod
            Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
      <xenc:CipherData>
        <xenc:CipherValue>hcq+ZmNCyjbotxsLUwR7EyKqwxw2hvoLVJDBiE2ToHAG9x3d5G5
              byhD0CvAumVUY1FIPurlEsU7Y
F0rgjo0BmycWyccDz8n9r8BYEkdZ0vM5YCmrw1NMCwlXVROHeXvToyq1PPAbcC4Ub9Gds6z2ZxrH
zjyVMSDdBE5xJHMXQrD5uLxDmXYV5I1bsd9oMjd7St+QR+/PiAS1yv113VIK0MvLaXm4qO2wY9gY
Nd6iH1NCivuUm+RcwiP6xc+ReDBkbJNU+KnoPXp19je/aNkLz1WwvblaC1Yn+difiYTMx7tQdwkE
N9foW4Q/fdFfdtO8qqpUmry6kYB2t5VYWRERq9KYXZzVJfBYsQJ9DrLsmr9EI67/Jgzp5eb/3yEZ
3Wd2Gr4hPWpqFQmlN4ibhxKwTRbZmxOc1jJpv3YCpUArAgna4kX/9NB70KreCoA+YlOtDLeXC4OT
RfWpoYLwa3Q4CHTTgnC+PsbreidkzFLU4urmHb4HZa0bldhM6ltb2RxJb1L3RldyXsfSAeZuZNlu
lN689hMLHuRAqlk6z+D+QdbiUBxULtdz514CT2aiE+Be/UD01DHZ1DWVBJokprKL93Y1H53c7f2p
8ajRvP38TyzjzLA93JzOe6fsgjkvcr3ptWzoL6BzGjoMvo3SABqhRF+SUJOAbLKV8zu/KwsOI9gr
bWkCpu56Z35QHk/jhHBoV0DjbBAX1/UY643yjBPuOMG05ENA6qjCSxRXKIfANZRlFL+R4+5//0Sx
oo81rcUKMAbHpy5nP9J5B38kKvZDCKNmbaDxmeZvxvnsJ6zzExddPHvSYlHJSjD58SwoxwRiHEqw
pvjjdTLtZghIVpR6ESBDT6MSVoJ9UhIKoK074ZB0LfeYoMd8KqKIpjyHkryfCTo121YE8TNeMIgT
K0Ck5y2uzPvgeomG6Uz/q3W592dKWbnSo1wCW1+RGjeHe2aGQSTHFdi7TxADPYT4HOu0M7zhzoSS
mxuhAMm2ysgCzFKWhPpWItIPigAmQjFGtnHXSK3bA2hHn3EUZtymbY7xqwdy1fbXWUIuJwXTPoIM
PX7IS3oI6GiIN9xBgo5Cgea3OMG8HQHHeyf4rBGgUrhbBHIa4LiZpkMK3In5FN4vmPfuzhEyRXLV
oGahAzSNq9OAwl1kGLWsklIdNkE8RKpDEy3gPSZKUIIjxSPeFzKAJa/RO9raDB2nidwAUjosHdKe
srnfhU/MVyq2JDjEcUI3Gb7c0TzRMZLw7yv97R/lFnpD9qZwATDErxXEN9IMuCgtcW7Lzjag8Dnb
AKJLAj5tNQAv3ro5FaqQPn2VKEqU7rhGE8KSTECG9Z6cfaZsZ+EQxVxTE6YjgTP1/PUSOsCG9ZFZ
BtnD8GqoLSiSa40Cgofw+7czIEpRTxNNwL3nX0sfnMlPHOSN9o8=</xenc:CipherValue>
      </xenc:CipherData>
    </xenc:EncryptedData>
  </PrivateKey>
</RecoverResult>
<?xml version="1.0" encoding="utf-8"?>
<RecoverResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
      Id="Iacd24dbd4b3c79660f4d26aca7aaaea2"
      Service="http://test.xmltrustcenter.org/XKMShttp://www.example.org/XKMS"
      ResultMajor="http://www.w3.org/2002/03/xkms#Success"
      RequestId="I66f40510c322d281602ce76b9eb04d7d"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <KeyBinding Id="I29cb8ac8a2ad878f7be44edfe53ea77a">
    <ds:KeyInfo>
      <ds:KeyValue>
        <ds:RSAKeyValue>
          <ds:Modulus>
            3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV7twNf2T
            UXCxYuztUUClMIy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreyn
            WegpFbITXc8V6Y02QfR5O7Pn1/10ElslaF/TF8MQGqYE8=
          </ds:Modulus>
          <ds:Exponent>AQAB</ds:Exponent>
        </ds:RSAKeyValue>
      </ds:KeyValue>
    </ds:KeyInfo>
    <Status StatusValue="http://www.w3.org/2002/03/xkms#Invalid">
      <InvalidReason>http://www.w3.org/2002/03/xkms#Signature</InvalidReason>
      <InvalidReason>http://www.w3.org/2002/03/xkms#IssuerTrust</InvalidReason>
      <InvalidReason>http://www.w3.org/2002/03/xkms#RevocationStatus</InvalidReason>
      <InvalidReason>http://www.w3.org/2002/03/xkms#ValidityInterval</InvalidReason>
    </Status>
  </KeyBinding>
  <PrivateKey>
    <xenc:EncryptedData>
      <xenc:EncryptionMethod
            Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
      <xenc:CipherData>
        <xenc:CipherValue>
          5/ZsmI7kU8z+5JiagYfDRy35+QxqnKMd8eDbkz9pDqxrNd3nAVftcOQSdSmJ7JD
          73d37sI69K9bUzeBslInkkFPNXEZLe2lmDwFrQf+N2x2C3MNDZaWGjxhC3dJ16Y
          AlkcbvDmA+7hPaAUNu8PYgtKd2viwxvWOfSsz95fTAiQdzsOAZLh3/Vpk9uNn9/
          fLmwuNYVWWLcrbdl/dVTFwILs2VQabcOEef8pQDRewU2CSpGPLO3YUzgpn/jiAr
          ye/6Z0bmNVDC05zlF/1Yizl0PKJoeBAW3yXv+3fnaERc77PgSZCrRl0DZuFZF/F
          6erHd4YUp1gdDa/MtBdivr6QwQLfaBwHM+7W6AEq0bqQ/wr/852qE0Tat0Wd3wq
          F6jdAZmVizw0eHhBP//GJvbNR/Kkkq7FsS4DZLGQUaSqcn3/lyCVymuskLKyG/g
          UgLXUvwGKN7DrqbsBq3n6Gd3BuWmtfrYX04+34AY2s7uLZg5xTsClVbpbXwEi9C
          70OATITTjpKxghRcXMvRcexjovi/eCE/+jafCMdC9W2ib6XhCBvRbKACqu/kArt
          IAFLElf6XDhHtcLteeQCTqK4EP/B5KAo4kCmlY3Xw3lZnUORztRvrPCmpGhmWSz
          a4TkicMvWaC2+MRoVuWfrfoj9Z1/+8jpW0dz3lxvVvOTqp0l97YE5zCChr31A9W
          Qprkx+RDNv78AIOripxErHUT9HNq8epES7n2Kz1xkEz3GBhPdV+h2FxiQ/pJ+vG
          5LD9h3CFCfOZ5u7F3QcYPftMy42UeSaXC+3S41Ijr1FNKVQy58eL4evHFhpd6Br
          Qdit3ZOZZ8zuOCL9BzLIDS13iuzsGi6GjKXgrUUO/L2I8EKziVwIitOPYTj0yBX
          EUcRtWGhq5fgkbjwelXUDAy+b3VwdOC75S428m6O6qmPz3w50La1zeoDPLfw5At
          yy8n+A9SBwrPVcu21YlEB2QQ4i33IlqvSPLebXecFPtO/xYycZox/JAeN+i9y6v
          XB7K82ve5SXsB1aPEJwpy5ErcXl20UP0sMzGblBsNb+yDN4bkWhCTEdBqGNfnuJ
          PtyC9RPhrLxQovCpx9VWZ9DUs+oyz0ObiCzfOr/fst00deloM/t9AbymwEH0FUF
          pPwA/+kKwjKi4dr5UlwpM2v5cUPjpWVpV6kfhFQRRAk02vakcZ9UPoiWaorLYBy
          tGRoI2cYWrPXaMqjq499PKE/J8oXDyu6yDQbMs0jXakD+hhZiviFBYfrYi5JdTt
          vEyENNeGgJmoj7n+jhFFVv2bVFNA4Bqu27vuFTDajmUEO22z+8cYSJ6XZjYi+UN
          UI8bJkszJL75naBejDGvZ55RYGPlwCgiQTMgKCD+46r5WwHZXPx8w9CDuUN/xSz
          7jiuxucf7jZAbbD+MQp+W7xAAJEKjtsczZxtLp67DFoGrH9oTOgcesz42DUxB6t
          vkYVb5VKtibkRzXR/iXOq0NuatYJ3/0OnYf8y6JHKHCU/yNKCvRRWpZ1E9pv1HE
          1HjHROURUoS/6+IHayHKA769cmHgb0UEcd5pSysI4vrvBHQDCArEVimH+zMgAe0
          BhOPycrCQ4GPZGnR5jTWbJVOBVABDY89uNrPLfS9t8C6z3HN9t9so/qYTQaI2NI
          7I/AAMtuyfneiBSA==
        </xenc:CipherValue>
      </xenc:CipherData>
    </xenc:EncryptedData>
  </PrivateKey>
</RecoverResult>

[269]The decrypted private key parameters are:

<?xml version="1.0" encoding="utf-8"?>
<RSAKeyValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:xsd="http://www.w3.org/2001/XMLSchema"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <Modulus>3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV7twNf2TUXC
        xYuztUUClM
Iy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreynWegpFbITXc8V6Y02QfR5O7Pn1/
10ElslaF/TF8MQGqYE8=</Modulus>
  <Exponent>AQAB</Exponent>
  <P>8dnXAObQvcKL0Rr/A+5Ufp1yJgLpH+uohFcJV2kUDCzv5VWKcN+LTq2mciKlnFbAQXKa5dNP
        Ox4q
i3An/4NSMQ==</P>
  <Q>6TUX4d9+enb/aLHtck39x7cPQWlKkNFFJAqXaaRScDhjf4d8b009uW/pu3O2BdIJPY8M/QnU
        RlqX
GLqGGl26fw==</Q>
  <DP>LVEcMFcPlf72I+BjGGF4A6GM2gKBnDGUCfglD/Pohb+F0/sLTcsVV1DCd3B2h6zZqWnIDHh
        jyDgG
0MnbNM1ugQ==</DP>
  <DQ>0DWm7PMtaQl1X3P8G2Gmgvjdlfj7qfAtWtBZ/ufG8oplyyab4oOD6FwSwlm82dV8iol9fy2
        XaHjZ
Dir6L/Ae4Q==</DQ>
  <InverseQ>sD2Vl/CCVTDbhhLwdfc4IQDBOh8xpBUV7PPM5LFGjiLetlfwaYi7Bp2ol8WF1MX88
        iCV2E3xOPCN
fbMhvEB5dA==</InverseQ>
  <D>REUnMUhO6ZX6NxoCwkJ7El5wXAVGtlNJsnPqFygbeEjlBvD6TZx9TqnpP/8IX7WK6JUFWd9k
        nQJv
CWeJjhbjnImSS/3xc+v+m4glnnebZbaghvfunbI++fQaNAFRVT1hLvEGknqC/7zsrUM04ogU7hP+
XgdFTJ1QYGfGHl5c0IE=</D>
</RSAKeyValue>
<?xml version="1.0" encoding="utf-8"?>
<RSAKeyPair xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:xsd="http://www.w3.org/2001/XMLSchema"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <Modulus>
    3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV7twNf2TUXCxYuztUU
    ClMIy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreynWegpFbITXc8V6Y02QfR5
    O7Pn1/10ElslaF/TF8MQGqYE8=
  </Modulus>
  <Exponent>AQAB</Exponent>
  <P>
    8dnXAObQvcKL0Rr/A+5Ufp1yJgLpH+uohFcJV2kUDCzv5VWKcN+LTq2mciKlnFbAQXKa5dNPO
    x4qi3An/4NSMQ==
  </P>
  <Q>
    6TUX4d9+enb/aLHtck39x7cPQWlKkNFFJAqXaaRScDhjf4d8b009uW/pu3O2BdIJPY8M/QnUR
    lqXGLqGGl26fw==
  </Q>
  <DP>
    LVEcMFcPlf72I+BjGGF4A6GM2gKBnDGUCfglD/Pohb+F0/sLTcsVV1DCd3B2h6zZqWnIDHhjy
    DgG0MnbNM1ugQ==
  </DP>
  <DQ>
    0DWm7PMtaQl1X3P8G2Gmgvjdlfj7qfAtWtBZ/ufG8oplyyab4oOD6FwSwlm82dV8iol9fy2Xa
    HjZDir6L/Ae4Q==
  </DQ>
  <InverseQ>
    sD2Vl/CCVTDbhhLwdfc4IQDBOh8xpBUV7PPM5LFGjiLetlfwaYi7Bp2ol8WF1MX88iCV2E3xO
    PCNfbMhvEB5dA==
  </InverseQ>
  <D>
    REUnMUhO6ZX6NxoCwkJ7El5wXAVGtlNJsnPqFygbeEjlBvD6TZx9TqnpP/8IX7WK6JUFWd9kn
    QJvCWeJjhbjnImSS/3xc+v+m4glnnebZbaghvfunbI++fQaNAFRVT1hLvEGknqC/7zsrUM04o
    gU7hP+XgdFTJ1QYGfGHl5c0IE=
  </D>
</RSAKeyPair>

6.5 Request Authentication

[270]X-KRSS specifies a mechanism for authenticating requests that is independent of any authentication mechanism provided by the message security binding. By its nature the X-KRSS protocol is required to support requests from parties who have yet to register their credentials or who have impaired credentials which are to be revoked.

[271]An X-KRSS Service SHOULD ensure that all requests are authentic and authorized.

[272] Authenticity: The request message originated from the specified party.

[273] Integrity: The request message has not been modified.

[274] Possession: If a public key is specified in a registration request, proof that the request is authorized by a party that has access to the corresponding private key.

[275]Registration services set their own authentication policy. This specification defines an authentication mechanism that employs a shared secret established out of band between the client and the registration service.

[276]Services SHOULD require that clients demonstrate Proof of Possession of the private key components of a public key if a request is made to register a valid key binding bound to that public key.

[277]Services SHOULD accept Proof of Possession of the private key component of a public key to effect revocation of any key binding bound to that key.

7 Key Registration Service Message Set

[278]The protocol operations consist of a remote procedure call that consists of a single request message sent by the client to the registration service followed by a single response message sent by the server to the client. 

[279]A response message MAY contain multiple key bindings if the operation resulted in the creation or a change in the status of multiple key bindings. For example a Register operation might cause two independent key bindings with different policy identifiers and validity intervals to be established in two independent underlying PKIs. Revocation of one such key binding might cause the revocation of other associated key bindings.

7.1 Common Elements

7.1.1 Element <PrototypeKeyBinding>

[280]The <PrototypeKeyBinding> element is derived from the KeyBindingAbstractType. It is used to specify the values of elements that a client requests be present in the keybinding resulting from a registration request.

[281]All fields in a <PrototypeKeyBinding> element are advisory and MAY be ignored by the service. For example a client might request registration under the policy identifier http://example.com/policy/high-security corresponding to a high assurance issuance policy but the returned key binding might specify the policy identifier http://example.com/policy/low-security corresponding to a low assurance issuance policy instead.

[282]The <PrototypeKeyBinding> element extends the KeyBindingAbstractType with the following additional elements:

<ValidityInterval> [Optional]
The suggested time interval for which the key binding relationship is valid.
<RevocationCodeIdentifier> [Optional]
Specifies a value to be used to validate a RevocationCode value in a subsequent Revocation request

[283]The following schema defines the <PrototypeKeyBinding>element and PrototypeKeyBindingType:

   <!-- PrototypeKeyBinding -->
   <element name="PrototypeKeyBinding" type="xkms:PrototypeKeyBindingType"/>
   <complexType name="PrototypeKeyBindingType">
      <complexContent>
         <extension base="xkms:KeyBindingAbstractType">
            <sequence>
               <element ref="xkms:ValidityInterval" minOccurs="0"/>
               <element ref="xkms:RevocationCodeIdentifier" minOccurs="0"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /PrototypeKeyBinding -->

7.1.2 Element <RevocationCodeIdentifier>

[284]The <RevocationCodeIdentifier> element contains a MAC output value encoded as a base64 string.

[285]The default MAC algorithm used is HMAC-SHA1. Other MAC algorithms MAY be used provided that the client is advised that the service accepts such algorithms by means of an out of band mechanism such as a Web Service description or policy mechanism.

[286]On initial registration the <RevocationCodeIdentifier> value is obtained by first performing the MAC calculation on the pass phrase value, then performing a second MAC calculation on the result.

[287]To prove knowledge of the pass phrase in a subsequent revocation request the <RevocationCode> value is obtained by performing the MAC calculation on the pass phrase value.

[288]The double MAC calculation ensures that the <RevocationCode> value may be sent as plaintext without the risk of disclosing a value which might have been used by the end-user as a password in another context. A second advantage of employing the double MAC calculation is that it ensures XKMS service does not place arbitrary constraints on the length of or character set in which the pass phrase is encoded.

[289]Details of the MAC output value calculation are provided in the section Cryptographic Algorithm Specific Parameters below.

[290]The following schema defines the <RevocationCodeIdentifier> element and the RevocationCodeIdentifierTypetype:

   <!-- RevocationCodeIdentifier -->
   <element name="RevocationCodeIdentifier"
         type="xkms:RevocationCodeIdentifierType"/>
   <simpleType name="RevocationCodeIdentifierType">
      <restriction base="base64Binary"/>
   </simpleType>
   <!-- /RevocationCodeIdentifier -->

7.1.3 Element <Authentication>

[291]The <Authentication> element is used to authenticate the key binding element within an XKRSS request. This may be a  <PrototypeKeyBinding>, <ReissueKeyBinding>, <RevokeKeyBinding> or <RecoverKeyBinding> element depending on the type of request.

<KeyBindingAuthentication>     [Optional]
Authentication of the key binding by means of a signature using a previously established key.
<NotBoundAuthentication>    [Optional]
Plaintext data used to authenticate the registration request that is not bound to the key binding.

[292]The following schema defines the <Authentication> element:

   <!-- Authentication -->
   <element name="Authentication" type="xkms:AuthenticationType"/>
   <complexType name="AuthenticationType">
      <sequence>
         <element ref="xkms:KeyBindingAuthentication" minOccurs="0"/>
         <element ref="xkms:NotBoundAuthentication" minOccurs="0"/>
      </sequence>
   </complexType>
   <!-- /Authentication -->

7.1.4 Element <KeyBindingAuthentication>

[293]The <KeyBindingAuthentication> element: contains a XML Signature [XML-SIG] element that is used to authenticate the request using a previously established key.

<ds:Signature>     [Required]
An XML Signature [XML-SIG] element that contains a signature over the <KeyBinding> or <PrototypeKeyBinding> element.

[294]The XML signature [XML-SIG] is generated as a detached signature using the Id attribute specified in KeyBindingAbstractType to specify the signature scope.

[295]The following schema defines the <KeyBindingAuthentication> element:

   <!-- KeyBindingAuthentication -->
   <element name="KeyBindingAuthentication"
         type="xkms:KeyBindingAuthenticationType"/>
   <complexType name="KeyBindingAuthenticationType">
      <sequence>
         <element ref="ds:Signature"/>
      </sequence>
   </complexType>
   <!-- /KeyBindingAuthentication -->

7.1.5 Element <NotBoundAuthentication>

[296]The <NotBoundAuthentication> contains a plaintext limited use shared secret that is used to authenticate the request.

Protocol    [Required]
A URI specifying the authentication protocol used
Value [Required]
The plaintext limited use shared secret data encoded in base64 format.

[297]The specification of protocol URIs is outside the scope of this document.

[298]This element is provided to support applications in which the authentication scheme requires the server to have plaintext access to the authentication data. The authentication data is not securely bound to the request and thus the element MUST NOT be employed except in circumstances where the message or transport protocol provides adequate protection of both confidentiality and integrity.

[299]The following schema defines the <NotBoundAuthentication> element:

   <!-- NotBoundAuthentication -->
   <element name="NotBoundAuthentication"
         type="xkms:NotBoundAuthenticationType"/>
   <complexType name="NotBoundAuthenticationType">
      <attribute name="Protocol" type="anyURI" use="required"/>
      <attribute name="Value" type="base64Binary" use="required"/>
   </complexType>
   <!-- /NotBoundAuthentication -->

7.1.6 Element <ProofOfPossession>

[300]The <ProofOfPossession> element contains a XML Signature [XML-SIG] element. The signature scope is the <PrototypeKeyBinding> using the public key that is to be registered. The private key component of the public key contained within the <PrototypeKeyBinding> is used to generate the signature.

<ds:Signature>     [Required]
An XML Signature [XML-SIG] element that contains a detached signature over the <PrototypeKeyBinding> element. The signing key is the key identified by the ds:KeyInfo element within the <PrototypeKeyBinding> element.

[301]The XML signature [XML-SIG] is generated as a detached signature using the Id attribute specified in KeyBindingAbstractType to specify the signature scope.

[302]The following schema defines the <ProofOfPossession> element:

   <!-- ProofOfPossession -->
   <element name="ProofOfPossession" type="xkms:ProofOfPossessionType"/>
   <complexType name="ProofOfPossessionType">
      <sequence>
         <element ref="ds:Signature"/>
      </sequence>
   </complexType>
   <!-- /ProofOfPossession -->

7.1.7 Element <PrivateKey>

[303] The <PrivateKey> element contains the encrypted private key parameters returned by the service in a response to a registration request with server generated keys or a response to a successful recovery request.

<xenc:EncryptedData>     [Required]
The encrypted private key data

[304]The following schema defines the <PrivateKey> element:

   <!-- PrivateKey -->
   <element name="PrivateKey" type="xkms:PrivateKeyType"/>
   <complexType name="PrivateKeyType">
      <sequence>
         <element ref="xenc:EncryptedData"/>
      </sequence>
   </complexType>
   <!-- /PrivateKey -->

7.1.8 Element <RevocationCode>

[305] The <RevocationCode> element contains a MAC output value encoded as a base64 string.

[306]The default MAC algorithm used is HMAC-SHA1. Other MAC algorithms MAY be used provided that the client is advised that the service accepts such algorithms by means of an out of band mechanism such as a Web Service description or policy mechanism.

[307]On initial registration the <RevocationCodeIdentifier> value is obtained by first performing the MAC calculation on the pass phrase value, then performing a second MAC calculation on the result.

[308]To prove knowledge of the pass phrase in a subsequent revocation request the <RevocationCode> value is obtained by performing the MAC calculation on the pass phrase value.

[309] Details of the MAC output value calculation are provided in the section Cryptographic Algorithm Specific Parameters below.

[310]The following schema defines the <RevocationCode> element and the RevocationCodeType:

   <!-- RevocationCode -->
   <element name="RevocationCode" type="xkms:RevocationCodeType"/>
   <simpleType name="RevocationCodeType">
      <restriction base="base64Binary"/>
   </simpleType>
   <!-- /RevocationCode -->

7.2 Register

7.2.1Register Request Element <RegisterRequest>

[311]The register request message contains a <RegisterRequest> element that contains the following elements:

<PrototypeKeyBinding>     [Required]
Specifies elements that the client requests be registered.
<Authentication>     [Required]
Information that authenticates the request.
<ProofOfPossesion>     [Optional]
Proof of possession of the private key component of the key binding.

[312]The following schema defines the <RegisterRequest> element:

   <!-- RegisterRequest -->
   <element name="RegisterRequest" type="xkms:RegisterRequestType"/>
   <complexType name="RegisterRequestType">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <sequence>
               <element ref="xkms:PrototypeKeyBinding"/>
               <element ref="xkms:Authentication"/>
               <element ref="xkms:ProofOfPossession" minOccurs="0"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /RegisterRequest -->

7.2.2Register Response Element <RegisterResult>

[313]The register response message contains a <RegisterResult> element that contains the following elements:

<KeyBinding>     [Any number]
If present specifies the key binding that was registered by the service
<PrivateKey>     [Optional]
The values of the private key parameters of a private key generated by the registration service

[314]The following schema defines the <RegisterResult> element:

   <!-- RegisterResult -->
   <element name="RegisterResult" type="xkms:RegisterResultType"/>
   <complexType name="RegisterResultType">
      <complexContent>
         <extension base="xkms:ResultType">
            <sequence>
               <element ref="xkms:KeyBinding" minOccurs="0"
                     maxOccurs="unbounded"/>
               <element ref="xkms:PrivateKey" minOccurs="0"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /RegisterResult -->

7.3 Reissue

7.3.1Reissue Request Element <ReissueRequest>

[315]The reissue request message contains a <ReissueRequest> element that contains the following elements:

<ReissueKeyBinding>     [Required]
Identifies the key binding to be reissued
<Authentication>     [Required]
Information that authenticates the request.
<ProofOfPossesion>     [Optional]
Proof of possession of the private key component of the key binding.

[316]The following schema defines the <ReissueRequest> and <ReissueKeyBinding> elements:

   <!-- ReissueRequest -->
   <element name="ReissueRequest" type="xkms:ReissueRequestType"/>
   <complexType name="ReissueRequestType">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <sequence>
               <element ref="xkms:ReissueKeyBinding"/>
               <element ref="xkms:Authentication"/>
               <element ref="xkms:ProofOfPossession" minOccurs="0"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <element name="ReissueKeyBinding" type="xkms:KeyBindingType"/>
   <!-- /ReissueRequest -->

7.3.2Reissue Response Element <ReissueResult>

[317]The reissue response message contains a <ReissueResult> element that contains the following element:

<KeyBinding>   [Any Number]
If present specifies the key binding(s) that were reissued by the service

[318] The following schema defines the <ReissueResult> element:

   <!-- ReissueResult -->
   <element name="ReissueResult" type="xkms:ReissueResultType"/>
   <complexType name="ReissueResultType">
      <complexContent>
         <extension base="xkms:ResultType">
            <sequence>
               <element ref="xkms:KeyBinding" minOccurs="0"
                     maxOccurs="unbounded"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /ReissueResult -->

7.4 Revoke

7.4.1Revoke Request Element <RevokeRequest>

[319]The revoke request message contains a <RevokeRequest> element that contains the following elements:

<RevokeKeyBinding>    [Required]
Identifies the key binding to be revoked.
<Authentication>     [Choice]
Information that authenticates the request.
<RevocationCode>[Choice]
The revocation code value that generates the revocation code identifier value specified during registration
 

[320]The following schema defines the <RevokeRequest> and <RevokeKeyBinding> elements:

   <!-- RevokeRequest -->
   <element name="RevokeRequest" type="xkms:RevokeRequestType"/>
   <complexType name="RevokeRequestType">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <sequence>
               <element ref="xkms:RevokeKeyBinding"/>
               <choice>
                  <element ref="xkms:Authentication"/>
                  <element ref="xkms:RevocationCode"/>
               </choice>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <element name="RevokeKeyBinding" type="xkms:KeyBindingType"/>
   <!-- /RevokeRequest -->

7.4.2Revoke Response Element <RevokeResult>

[321]The request message contains a <RevokeResult> element that contains the following element:

<KeyBinding>    [Any Number]
If present specifies the key binding that was revoked by the service

[322]The following schema defines the <RevokeResult>:

   <!-- RevokeResult -->
   <element name="RevokeResult" type="xkms:RevokeResultType"/>
   <complexType name="RevokeResultType">
      <complexContent>
         <extension base="xkms:ResultType">
            <sequence>
               <element ref="xkms:KeyBinding" minOccurs="0"
                     maxOccurs="unbounded"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /RevokeResult -->

7.5 Recover

7.5.1Recover Request Element <RecoverRequest>

[323]The recover request message contains a <RecoverRequest> element that contains the following elements:

<RecoverKeyBinding>    [Required]
Identifies the key binding to be recovered.
<Authentication>     [Required]
Information that authenticates the request.

[324]The following schema defines the <RecoverRequest> and <RecoverKeyBinding> elements:

   <!-- RecoverRequest -->
   <element name="RecoverRequest" type="xkms:RecoverRequestType"/>
   <complexType name="RecoverRequestType">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <sequence>
               <element ref="xkms:RecoverKeyBinding"/>
               <element ref="xkms:Authentication"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <element name="RecoverKeyBinding" type="xkms:KeyBindingType"/>
   <!-- /RecoverRequest -->

7.5.2Recover Response Element <RecoverResult>

[325]The request message contains a <RecoverResult> element that contains the following elements:

<KeyBinding>     [Any Number]
May be present to advertise a change to the status of the key binding made as a result of the key recovery.
<PrivateKey>    [Optional]
The values of the private key parameters of the recovered private key

[326]The following schema defines the <RecoverResult> element:

   <!-- RecoverResult -->
   <element name="RecoverResult" type="xkms:RecoverResultType"/>
   <complexType name="RecoverResultType">
      <complexContent>
         <extension base="xkms:ResultType">
            <sequence>
               <element ref="xkms:KeyBinding" minOccurs="0"
                     maxOccurs="unbounded"/>
               <element ref="xkms:PrivateKey" minOccurs="0"/>
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /RecoverResult -->

8 Cryptographic Algorithm Specific Parameters

8.1 Use of Limited-Use Shared Secret Data

[327]It is frequently necessary or desirable to use a limited use shared secret for authentication (i.e. a one time use PIN or pass phrase) to authenticate registration request messages. In particular a private key cannot be used for authentication until the corresponding public key has been registered.

[328]In addition it is desirable that private key parameters generated or recovered by the registration service be returned encrypted. It is convenient to use symmetric data for this purpose.

[329]Since human users are the most demanding in terms of interface requirements the handling of symmetric key data is designed for the needs of clients supporting human users directly. Symmetric keying data is typically issued to a human user in the form of a text string which may in some circumstances be read over a telephone line. The authentication data itself MAY be randomly generated and represent an underlying numeric value, or MAY be a password or phrase. In either case it is most convenient to present the value to the human user as a string of characters in a character set the particular user understands.

[330]Applications MUST ensure that the limited use shared secret data contains sufficient entropy to prevent dictionary attacks. For more details see the  more detailed comment in the security considerations section of this document.

[331]Keying material is derived from the shared string using a MAC function.

[332]The default MAC algorithm used is HMAC-SHA1. Other MAC algorithms MAY be used provided that the client is advised that the service accepts such algorithms by means of an out of band mechanism such as a Web Service description or policy mechanism.

[333]Different MAC keying values are used according to the use of the symmetric key derived as follows:

Value Application
0x1 Authentication
0x2 Encoding of RevocationCodeIdentifier - Pass 1
0x3 Encoding of RevocationCodeIdentifier - Pass 2
0x4 Encryption of PrivateKey data

[334]If the output of the MAC function provides more keying material than is required for a cryptographic operation (i.e. encryption, MAC), the lowest significant bits are used.

[335]If the output of the MAC function provides less keying material than is required additional keying material is obtained as follows:

[336]block0 = MAC (converted, key)

[337]blockn+1 = MAC (converted, key XOR blockn)

[338]output = block0 + block1 ...  blockn

[339]i.e. the first MAC output value is used to supply the least significant bits of keying material. A second MAC output value is then obtained by applying the MAC function to the converted string again, this time the MAC keying value is obtained by XOR-ing the first output with the previous keying value. This process may be repeated as many times as necessary to produce a sufficient amount of keying material.

8.2 Private Key Parameters

[340]The <PrivateKey> element may contain the private key parameters for any public key encryption algorithm. The parameters for the RSA algorithm are specified below.

[341]This specification does not specify private key parameters for the DSA signature algorithm since the algorithm only supports signature modes and so the application of server generated keys and key recovery is of limited value.

8.2.1 Element <RSAKeyPair>

[342]The <RSAKeyPair> element specifies the public and private parameters of an RSA key pair. The contents of the RSAKeyPair element are specified in [PKCS1]. The RSAKeyPair> element contains the following parameters:

<Modulus> (Required)
The modulus
<Exponent> (Required)
The public exponent
<P> (Required)
The first factor, a positive integer
<Q> (Required)
The second factor, a positive integer
<DP> (Required)
The first factor's CRT exponent, a positive integer
<DQ> (Required)
The second factor's CRT exponent, a positive integer
<InverseQ> (Required)
The (first) CRT coefficient, a positive integer
<D> (Required)
The private exponent

[343] The following schema defines the <RSAKeyPair> element:

   <!-- RSAKeyPair -->
   <element name="RSAKeyPairRSAKeyValue" type="xkms:RSAKeyPairValueType"/>
   <complexType name="RSAKeyValuePairType">
      <sequence>
         <element ref="xkms:Modulus"/>
         <element ref="xkms:Exponent"/>
         <element ref="xkms:P"/>
         <element ref="xkms:Q"/>
         <element ref="xkms:DP"/>
         <element ref="xkms:DQ"/>
         <element ref="xkms:InverseQ"/>
         <element ref="xkms:D"/>
      </sequence>
   </complexType>
   <element name="Modulus" type="ds:CryptoBinary"/>
   <element name="Exponent" type="ds:CryptoBinary"/>
   <element name="P" type="ds:CryptoBinary"/>
   <element name="Q" type="ds:CryptoBinary"/>
   <element name="DP" type="ds:CryptoBinary"/>
   <element name="DQ" type="ds:CryptoBinary"/>
   <element name="InverseQ" type="ds:CryptoBinary"/>
   <element name="D" type="ds:CryptoBinary"/>
   <!-- /RSAKeyPair -->

9 Conformance

[344]The section describes features and operations that XKMS applications whose support is either required or recommended to ensure interoperability of XKMS services.

[345]As such the conformance requirements fall on message recipients rather than message senders, although a sender SHOULD NOT send a message unless it is known that it will be accepted by the recipient.

[346]The following table specifies the conformance requirements of XKMS as REQUIRED,. RECOMMENDED or OPTIONAL as follows:

[350]Some features as specified as REQUIRED* or RECOMMENDED*. This signifies that the condition holds if another feature is supported. For example an XKMS Locate service is not required to support XML Signature. If however XML Signature is supported the use of Exclusive Canonicalization MUST be supported.

[351]One feature is specified as RECOMMENDED +. This signifies that even though this feature can only be used at the request of the client it is strongly recommended that the client request use of this feature since a service is likely to require it for the response to be successful.

[352]Where a service supports a feature that is advertised as OPTIONAL it is recommended that the service advertise this feature by means of a Web Service description mechanism. For example an XKMS service that supports the use of a transport encoding other than HTTP SHOULD advertise that fact.

[353]Implementers should note that these requirements may change in future versions of the XKMS specification. For example it is likely that future versions of the XKMS specification will make the then current version of the SOAP specification a requirement.

Feature Operations Requirement Level Comments
Operation Support Locate RECOMMENDED Services SHOULD support retrieval of their own credential by means of the Locate operation with the XKMS protocol URI.
All One Operation REQUIRED A conforming XKMS service MUST support at least one XKMS operation, that is there MUST be at least one possible input that results in the result Success.
Compound OPTIONAL See note for Status operation support.
Status RECOMMENDED* Services SHOULD support status operations if asynchronous processing and compound requests are also supported
Operation Response All REQUIRED A conforming XKMS service MUST accept any valid XKMS request sent to it and be capable of responding to the request with a correctly formatted XKMS result. If a service does not support an operation it MUST respond to all requests for a particular operation with the result Sender.MessageNotSupported.
Response Mechanisms
Feature Operations Requirement Level Comments
Synchronous Response All REQUIRED A conforming XKMS service MUST be capable of returning an immediate response to any XKMS request.
Asynchronous Response

[354]

 Register, Reissue, Recover RECOMMENDED+ Processing of certain XKRSS operations may require manual intervention by an operator in certain circumstances. It is therefore recommended that clients support the use of asynchronous processing with these operations unless it is known that all requests will be serviced immediately.
Compound RECOMMENDED Services that support Compound Operations SHOULD support compound requests
Locate, Validate,
Revoke		 OPTIONAL Services MAY support Asynchronous responses be supported on these operations
Pending,
Status		 PROHIBITED A client MAY offer asynchronous processing of Pending and Status operations however a service MUST NOT return a pending response.
Two-Phase Request All RECOMMENDED+ Clients SHOULD support use of the two phase request protocol. The additional complexity of implementing the two phase protocol is not high and allows a service to provide a response even in cases where it is under a denial of service attack.
Protocol Encapsulation
Feature Operations Requirement Level Comments
HTTP Transport All REQUIRED Services MUST support the use of HTTP transport
SOAP 1.2 Transport All REQUIRED Services MUST support the use of SOAP 1.2 encapsulation
SOAP 1.1 Transport All RECOMMENDED Services MAY support the use of SOAP 1.1 encapsulation
Security Enhancements
Feature Operations Requirement Level Comments
No Security Locate REQUIRED  
[Others] RECOMMENDED  
Payload Authentication I All RECOMMENDED  
Payload Authentication II All RECOMMENDED  
TLS Binding I All RECOMMENDED  
TLS Binding II All RECOMMENDED  
TLS Binding III All RECOMMENDED  
Exclusive Canonicalization All REQUIRED* If XML Signature is used, Exclusive Canonicalization MUST be supported.

10 Security Considerations

[355]Implementations SHOULD consider the following security issues.

10.1 Replay Attacks

[356]Implementations SHOULD ensure that replay of a previous XKMS response is not possible.

[357]The precise mechanism by which replay attacks are prevented is left to the implementation. For example generic mechanism built into the object exchange protocol if specified MAY be used.

[358]A generally applicable means of preventing a replay attack is to place a token in each message that demonstrates to the recipient that the message is 'fresh', for example:

10.2 Denial of Service

[359]XKMS Services SHOULD take measures to prevent or mitigate denial of service attacks. In particular XKMS Services SHOULD NOT perform an unlimited number of resource intensive operations unless the request comes from an authenticated source. Potentially resource intensive operations include:

10.3 Recovery Policy

[360]Key recovery policy is left as an implementation decision.

[361]Depending on the implementation and application, a key recovery operation might involve an unacceptable loss of confidence in the security of a private key component. This may lead to the possibility of repudiation of a signed document or of accountability in the case of an encrypted document.

[362]Services SHOULD carefully assess the extent to which a recovery operation compromises a private key and apply sufficient controls such as the revocation of the underlying key binding as appropriate.

10.4 Security of Limited Use Shared Secret

[363]If a limited use shared secret is used care must be taken to ensure that the secret has sufficient entropy that the probability of guessing by an attacker is tolerably low. Particular care must be taken if a limited use shared secret is used to encrypt a service generated private key since the transported private key might be subject to a dictionary attack. Applications SHOULD enforce the following minimum entropy values for the shared secret:

Registration of Client Generated Key
The shared secret SHOULD contain a minimum of 32 bits of entropy if the service implements measures to prevent guessing of the shared secret and a minimum of 128 bits of entropy otherwise.
Registration of Service Generated Key
The shared secret SHOULD have a minimum of 128 bits of entropy

10.5 Confidentiality of Opaque Client Data

[364]Clients SHOULD NOT send confidential or privacy sensitive data to an XKMS Service as Opaque Data unless it is encrypted such that it is not disclosed to the service.

[365]Examples of confidential data include internal program indices such as pointers which might permit a malicious party with access to an XKMS service or its audit logs to perform an attack based on knowledge of the internal state of the client.

10.6 Security of Not Bound Authentication Data

[366]If a service supports the use of authentication using the <NotBoundAuthentication> element, controls MUST be employed to ensure the confidentiality of the authentication data and to ensure that the <NotBoundAuthentication> is bound to the request.

[367]This MAY be a message level or transport level protocol that protects both encryption and integrity such as TLS [RFC-2246]. Note that merely encrypting the shared secretdoes not provide adequate securitysince the <PassPhraseAuth>element is not cryptographically bound to the message.

10.7 Signature Oracle

[368]XKMS services that provide signed responses SHOULD ensure that the requestor cannot solicit a predicted response, thus providing a signing oracle. Such a signing oracle might provide a direct compromise for the key under a different protocol or allow a weakness in the signature or digest algorithm employed to be exploited.

[369]Response messages should include at least as much randomly chosen data as the output of the digest algorithm used to create the signature. For example a message signed using RSA and SHA-1 should contain at least 160 bits of random data.

10.8 Privacy

[370]An XKMS service MAY solicit data which is subject to privacy concerns. In certain circumstances management of such data MAY be subject to government regulation, corporate policies or contractual obligations. Deployments SHOULD consider whether the information they collect is subject to such concerns and if necessary deploy a privacy notification mechanism such as P3P [P3P].

10.9 Security of the Private Key

[371]Implementations MUST ensure that in cases where a private key is generated by the service, the information used to encrypt the private key data is adequately protected. In particular if an authentication pass phrase exchanged out of band is used to encrypt the private key the implementation MUST ensure that the out of band communication mechanism adequately protects the confidentiality of the pass phrase.

[372]It is recommended that implementations make use of TLS or an in-band key exchange mechanism to protect the private key in the case that the authentication pass phrase is disclosed.

[372a]Implementations supporting encryption of Private Key Data MUST support Shared Secret. Use of Shared Secret is detailed in section 8.1.

10.10 Message Length Disclosure Vulnerabilities

[373]In certain circumstances the length of an encrypted response MAY reveal information that is useful to an attacker. For example a short message might indicate that a request was refused. Deployments SHOULD consider whether such disclosures might result in compromise of confidential information.

10.11 Check for Signature Value in a Signed SOAP Message

[373a] The Implementation of XKMS MUST check for signature value reference in the to-be-signed data when using Signed SOAP message. Also, Implemenations MUST ensure that all bytes in the XKMS messages ex. from <locate> .... </locate> must be included in hashing and resulting signature value of the message.

Appendix A Schemas

A.1 XKMS Schema

The collected schema is available here

Appendix B Service Location Configuration

[374]In many instances it is desirable to advertise the existence of an XKMS service in some form of discovery protocol. This appendix describes specific means of advertising the existence of XKMS services in the Internet Domain Name Service (DNS).

B.1 Domain Name Service (DNS)

[375]The provision of an XKMS service that provides information on key information bound to DNS addresses in a specified DNS zone MAY be advertised by means of the DNS SRV record [RFC 2782]. An SRV record contains the following data fields:

[376]_Service._Protocol.NameTTLClassSRVPriorityWeightPortTarget

Service
The symbolic name of the desired service, as defined in Assigned Numbers [STD 2] or locally.  An underscore (_) is prepended to the service identifier to avoid collisions with DNS labels that occur in nature.
Protocol
The symbolic name of the desired protocol, with an underscore (_) prepended to prevent collisions with DNS labels that occur in nature.
Name
The domain this RR refers to. The SRV RR is unique in that the name one searches for is not this name.
TTL
Standard DNS meaning [RFC 1035].
Class
Standard DNS meaning [RFC 1035]. SRV records occur in the IN Class.
Priority
The priority of this target host. A client MUST attempt to contact the target host with the lowest-numbered priority it can reach; target hosts with the same priority SHOULD be tried in an order defined by the weight field.
Weight
A server selection mechanism. The weight field specifies a relative weight for entries with the same priority. Larger weights SHOULD be given a proportionately higher probability of being selected. The range of this number is 0-65535.
Port
The port on this target host of this service. The range is 0-65535. This is a 16 bit unsigned integer in network byte order. This is often as specified in Assigned Numbers but need not be.
Target
The domain name of the target host. There MUST be one or more address records for this name, the name MUST NOT be an alias (in the sense of RFC 1034 or RFC 2181). Implementors are urged, but not required, to return the address record(s) in the Additional Data section. Unless and until permitted by future standards action, name compression is not to be used for this field.

[377]The following service values are defined:

_XKMS_XKISS_SOAP_HTTP
An XKMS service supporting the XKISS protocol in the SOAP binding using HTTP as the application layer transport. The Protocol value for this service is TCP.
_XKMS_XKRSS_SOAP_HTTP
An XKMS service supporting the XKRSS protocol in the SOAP binding using HTTP as the application layer transport. The Protocol value for this service is TCP.

[378]The publication of an SRV record in a DNS zone that advertises an XKMS service is an affirmative statement by the operator of the zone that the XKMS service indicated MAY be queried for information concerning key information bound to protocol addresses within that zone. The publication of an SRV record does not imply any undertaking on the part of the part of the publisher to ensure that the information provided by the XKMS service is accurate or trustworthy. Relying parties MUST therefore establish the trustworthiness of any information they may receive from an XKMS service discovered by means of an SRV record by other means, for example by forwarding the data to an XKMS Validate service.

B.1.1 Examples

[379]The following SRV record advertises an XKMS XKISS service on port 80 of border-xkms.example.com:

[380]_XKMS_XKISS_SOAP_HTTP._TCP.example.com - IN 0 1 80 border-xkms.example.com

[381]The following SRV record advertises three XKMS XKISS services, main1, main2 and backup. Clients should direct requests to main1 and main2 with equal priority. The service backup should only be accessed if neither main1 or main2 is available:

[382]_XKMS_XKISS_SOAP_HTTP._TCP.example.com - IN 0 50 80 main1.example.com
_XKMS_XKISS_SOAP_HTTP._TCP.example.com - IN 0 50 80 main2.example.com
_XKMS_XKISS_SOAP_HTTP._TCP.example.com - IN 1 1 80 backup.example.com

Appendix C Sample Protocol Exchanges

[383]For clarity the examples in the running text omit certain details such as the message authentication signatures and SOAP binding information. This section provides theses messages in full to facilitate interoperability testing.

C.1 Authentication Computation

[384]The calculation of the authentication values used in the examples.

C.1.1 Alice Registration Authentication Key

Authentication Data
024837
Converted Authentication Data
[30][32][34][38][33][37]
Key = HMAC-SHA1 (Converted Authentication Data, 0x1)
[d6][cc][34][cb][83][fa][e2][99] [3a][39][3a][a8][e7][de][9a][06] [c7][fa][2c][92]

C.1.2 Bob Registration Authentication Key

Authentication Data
 3N9CJ-JK4JK-S04JF-W0934-JSR09-JWIK4
Converted Authentication Data
 [33][6e][39][63][6a][6b][34][6a] [6b][73][30][34][6a][66][77][30] [39][33][34][6a][73][72][30][39] [6a][77][69][6b][34] [33][6e][39][63][6a][6a][6b][34] [6a][6b][73][30][34][6a][66][77] [30][39][33][34][6a][73][72][30] [39][6a][77][69][6b][34]
Key = HMAC-SHA1 (Converted Authentication Data, 0x1)
 [2d][7d][34][d5][ba][69][6b][f3] [ea][c7][9f][fe][6d][b5][e7][e7] [99][46][a0][e3] [92][33][7c][7c][3e][8d][3b][7a] [cf][11][59][89][36][64][56][69] [95][4f][8f][d7]

C.1.3 Bob Registration Private Key Encryption

Authentication Data
3N9CJ-K4JKS-04JWF-0934J-SR09JW-IK4
Converted Authentication Data
[33][6e][39][63][6a][6b][34][6a] [6b][73][30][34][6a][66][77][30] [39][33][34][6a][73][72][30][39] [6a][77][69][6b][34] [33][6e][39][63][6a][6b][34][6a] [6b][73][30][34][6a][77][66][30] [39][33][34][6a][73][72][30][39] [6a][77][69][6b][34]
First Block = HMAC-SHA1 (Converted Authentication Data, 0x4)
[82][6d][b2][12][44][89][22][a0] [ef][83][da][23][d6][f1][ec][9a] [03][03][5a][3e] [78][f1][e7][b1][b3][fd][0c][bc] [96][04][e7][01][4f][33][78][d3] [0b][c8][5f][bd]
Key = First Block XOR 0x4
[86][6d][b2][12][44][89][22][a0] [ef][83][da][23][d6][f1][ec][9a] [03][03][5a][3e] [7c][f1][e7][b1][b3][fd][0c][bc] [96][04][e7][01][4f][33][78][d3] [0b][c8][5f][bd]
Second Block = HMAC-SHA1 (Converted Authentication Data, Key)
[6c][15][9b][39][ab][df][15][d4] [7a][c6][1c][02][64][66][0d][ea] [c5][62][4c][b3] [1e][7f][e1][b0][ab][d0][f8][09] [2e][28][f3][9d][14][a8][d0][83] [2e][ab][ea][22]
Final Private Secret Key
[82][6d][b2][12][44][89][22][a0] [ef][83][da][23][d6][f1][ec][9a] [03][03][5a][3e][6c][15][9b][39] [78][f1][e7][b1][b3][fd][0c][bc] [96][04][e7][01][4f][33][78][d3] [0b][c8][5f][bd][1e][7f][e1][b0]

[385]The private secret key is used to encrypt Bob's private key as follows:

Initialization Vector
[1e][7a][76][dc][87][c1][f5][5a]
PlainText
<?xml version="1.0" encoding="utf-16"?>
<RSAKeyPair xmlns="http://www.w3.org/2002/03/xkms#"> ...
Plain Text
[3c][3f][78][6d][6c][20][76][65] [72][73][69][6f][6e][3d][22][31] [2e][30][22][20][65][6e][63][6f] [64][69][6e][67][3d][22][75][74] [66][2d][31][36][22][3f][3e][0d] [0a][3c][52][53][41][4b][65][79] [50][61][69][72][20][78][6d][6c] [6e][73][3d][22][68][74][74][70] [3a][2f][2f][77][77][77][2e][77] [33][2e][6f][72][67][2f][32][30] [30][32][2f][30][33][2f][78][6b] ...
[69][72][3e][05][05][05][05][05]
Cipher Text (with pre-pended Initialization Vector)
[1e][7a][76][dc][87][c1][f5][5a] [6d][e5][fe][00][eb][7f][76][2e] [a9][37][fa][1f][98][f7][df][6b] [26][1a][62][7b][18][be][c5][71] [16][a2][41][35][9e][da][f4][67] [8a][b8][bb][7e][a1][47][2d][0f] [3e][60][14][4a][cf][09][6c][57] [45][56][2c][31][3e][12][63][e2] [79][79][9e][6c][16][f1][b6][64] [6f][42][a3][1b][fa][cb][7a][a6] [97][21][b1][94][c1][86][b6][e2] [55][5e][23][3b][c8][42][16][09]
...
[23][b2][59][cb][5d][32][1d][48]

C.1.4 Bob Recovery Private Key Encryption

Authentication Data
A8YUT vuhhu c9h29 8y43u h9j3i 23
Converted Authentication Data
[61][38][79][75][74][76][75][68] [68][75][63][39][68][32][39][38] [79][34][33][75][68][39][6a][33] [69][32][33]
Private Key
[91][8c][67][d8][bc][16][78][86] [dd][6d][39][19][91][c4][49][6f] [14][e2][61][33][8a][4a][d5][be] [6c][15][06][7b]

C.2 Pass Phrase Computation

[386]The calculation of the pass phrase values used in the examples.

C.2.1 Alice Pass Phrase Computation

Pass Phrase
"Help I Have Revealed My Key"
Converted Pass Phrase
[68][65][6c][70][69][68][61][76][65][72][65][76][65][61][6c][65][64][6d][79][6b][65][79]
Pass Phrase Pass 1 HMAC-SHA1 (Converted Authentication Data, 0x1 0x2)
[3c][7c][7c][96][2d][92][52][1a][c9][bf][67][b5][0f][27][96][6c][66][c3][ea][bb]
Pass Phrase Pass 2 = HMAC-SHA1 (Pass Phrase Pass 1 , 0x2 0x3)
[e4][01][00][6a][2d][3a][84][52][44][92][ea][b2][0f][2a][8d][87][c9][3f][bb][73]
Base 64 Encoding of Pass Phrase
5AEAai06hFJEkuqyDyqNh8k/u3M=

C.2.2 Bob Pass Phrase Computation

Pass Phrase
"Have A Banana"
Converted Pass Phrase
[68][61][76][65][61][62][61][6e][61][6e][61]
Pass Phrase Pass 1 = HMAC-SHA1 (Converted Authentication Data,0x1 0x2)
[f0][66][22][54][af][33][04][3e][44][d2][af][51][ab][66][3f][19][c8][b4][66][9a]
Base 64 Encoding of Pass Phrase Stage 1
PHx8li2SUhrJv2e1DyeWbGbD6rs= 8GYiVK8zBD5E0q9Rq2Y/Gci0Zpo=
Pass Phrase Pass 2 = HMAC-SHA1 (Pass Phrase Pass 1 , 0x2 0x3)
[60][37][64][79][9e][a9][e6][e7][97][9e][f9][ce][3f][22][39][53][bf][8f][d9][0a]
Base 64 Encoding of Pass Phrase Stage 2
YDdkeZ6p5ueXnvnOPyI5U7+P2Qo=

C.3 Private Key Parameters

[387]The parameters of the parties RSA key pairs are as follows:

C.3.1 Alice Private Key Parameters

<?xml version="1.0" encoding="utf-8"?>
<RSAKeyValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:xsd="http://www.w3.org/2001/XMLSchema"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <Modulus>0nIsmR+aVW2egl5MIfOKy4HuMKkk9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBu
        pui8LgGthO
6U9D0CNT5mbmhIAErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVD
QggPBLc1XagW20RMvok=</Modulus>
  <Exponent>AQAB</Exponent>
  <P>7p05u5P4BO+aXdyD/6n31a4Dk9kC4Tv5fMbE15/ioPii9JwPU2J29qhO1QEqvgNwxv67w4jr
        C025
Yz5LXgjziw==</P>
  <Q>4ceKAtGgSJg8ddRxwz8OESXVOd1tlSHFu7Gqona3VxbrOONLZEbsnYA4dv4nI+pxl8PmUe5C
        Pggg
GElx30OIuw==</Q>
  <DP>ve9rEDQVfaBYCRTKAY2DGJT+hgZ881qxGjCCaXz8gdPIqts6m85KEcchkQ3vvvawI8aLIXd
        wWTwS
MLxac8y+Rw==</DP>
  <DQ>jW/x3ggx76gmn+3hAl3a0xUvORukjTrl4snOyg2ylsUNv8prrTrc+WGcfbaDEHXKiTc4bnT
        iXHe8
m1pPEnz9Bw==</DQ>
  <InverseQ>yxCo+k0v8n80Qeo2QAGKiwltLF+1ObyZ1TQg4chISWdfLD+j1nIKIs1miELdszjO/
        szLWMx5kA3k
OLi6jXsByw==</InverseQ>
  <D>aeLWu8jh75/zRGdL6T1QFatvfH5uwHXQW4EeZJ00/P0lghEOvgNPWPGkjpaxNtW39GvaaWoJ
        Npil
w9CFL2HHIVn1OVZyw5BDbotQty3lm66KL7qtrjqlqyPu5ARglGqTZIaRyP8LW6NAbkyxLPnpADVf
HJuEePmooCmHbTValP0=</D>
</RSAKeyValue>
<?xml version="1.0" encoding="utf-8"?>
<RSAKeyPair xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <Modulus>
    0nIsmR+aVW2egl5MIfOKy4HuMKkk9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgG
    thO6U9D0CNT5mbmhIAErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GD
    NiHKVDQggPBLc1XagW20RMvok=
  </Modulus>
  <Exponent>AQAB</Exponent>
  <P>
    7p05u5P4BO+aXdyD/6n31a4Dk9kC4Tv5fMbE15/ioPii9JwPU2J29qhO1QEqvgNwxv67w4jrC
    025Yz5LXgjziw==
  </P>
  <Q>
    4ceKAtGgSJg8ddRxwz8OESXVOd1tlSHFu7Gqona3VxbrOONLZEbsnYA4dv4nI+pxl8PmUe5CP
    gggGElx30OIuw==
  </Q>
  <DP>
    ve9rEDQVfaBYCRTKAY2DGJT+hgZ881qxGjCCaXz8gdPIqts6m85KEcchkQ3vvvawI8aLIXdwW
    TwSMLxac8y+Rw==
  </DP>
  <DQ>
    jW/x3ggx76gmn+3hAl3a0xUvORukjTrl4snOyg2ylsUNv8prrTrc+WGcfbaDEHXKiTc4bnTiX
    He8m1pPEnz9Bw==
  </DQ>
  <InverseQ>
    yxCo+k0v8n80Qeo2QAGKiwltLF+1ObyZ1TQg4chISWdfLD+j1nIKIs1miELdszjO/szLWMx5k
    A3kOLi6jXsByw==
  </InverseQ>
  <D>
    aeLWu8jh75/zRGdL6T1QFatvfH5uwHXQW4EeZJ00/P0lghEOvgNPWPGkjpaxNtW39GvaaWoJN
    pilw9CFL2HHIVn1OVZyw5BDbotQty3lm66KL7qtrjqlqyPu5ARglGqTZIaRyP8LW6NAbkyxLP
    npADVfHJuEePmooCmHbTValP0=
  </D>
</RSAKeyPair>

C.3.2 Bob Private Key Parameters

<?xml version="1.0" encoding="utf-8"?>
<RSAKeyValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:xsd="http://www.w3.org/2001/XMLSchema"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <Modulus>3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV7twNf2TUXC
        xYuztUUClM
Iy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreynWegpFbITXc8V6Y02QfR5O7Pn1/
10ElslaF/TF8MQGqYE8=</Modulus>
  <Exponent>AQAB</Exponent>
  <P>8dnXAObQvcKL0Rr/A+5Ufp1yJgLpH+uohFcJV2kUDCzv5VWKcN+LTq2mciKlnFbAQXKa5dNP
        Ox4q
i3An/4NSMQ==</P>
  <Q>6TUX4d9+enb/aLHtck39x7cPQWlKkNFFJAqXaaRScDhjf4d8b009uW/pu3O2BdIJPY8M/QnU
        RlqX
GLqGGl26fw==</Q>
  <DP>LVEcMFcPlf72I+BjGGF4A6GM2gKBnDGUCfglD/Pohb+F0/sLTcsVV1DCd3B2h6zZqWnIDHh
        jyDgG
0MnbNM1ugQ==</DP>
  <DQ>0DWm7PMtaQl1X3P8G2Gmgvjdlfj7qfAtWtBZ/ufG8oplyyab4oOD6FwSwlm82dV8iol9fy2
        XaHjZ
Dir6L/Ae4Q==</DQ>
  <InverseQ>sD2Vl/CCVTDbhhLwdfc4IQDBOh8xpBUV7PPM5LFGjiLetlfwaYi7Bp2ol8WF1MX88
        iCV2E3xOPCN
fbMhvEB5dA==</InverseQ>
  <D>REUnMUhO6ZX6NxoCwkJ7El5wXAVGtlNJsnPqFygbeEjlBvD6TZx9TqnpP/8IX7WK6JUFWd9k
        nQJv
CWeJjhbjnImSS/3xc+v+m4glnnebZbaghvfunbI++fQaNAFRVT1hLvEGknqC/7zsrUM04ogU7hP+
XgdFTJ1QYGfGHl5c0IE=</D>
</RSAKeyValue>
<?xml version="1.0" encoding="utf-8"?>
<RSAKeyPair xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <Modulus>
    3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV7twNf2TUXCxYuztUU
    ClMIy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreynWegpFbITXc8V6Y02QfR5
    O7Pn1/10ElslaF/TF8MQGqYE8=
  </Modulus>
  <Exponent>AQAB</Exponent>
  <P>
    8dnXAObQvcKL0Rr/A+5Ufp1yJgLpH+uohFcJV2kUDCzv5VWKcN+LTq2mciKlnFbAQXKa5dNPO
    x4qi3An/4NSMQ==
  </P>
  <Q>
    6TUX4d9+enb/aLHtck39x7cPQWlKkNFFJAqXaaRScDhjf4d8b009uW/pu3O2BdIJPY8M/QnUR
    lqXGLqGGl26fw==
  </Q>
  <DP>
    LVEcMFcPlf72I+BjGGF4A6GM2gKBnDGUCfglD/Pohb+F0/sLTcsVV1DCd3B2h6zZqWnIDHhjy
    DgG0MnbNM1ugQ==
  </DP>
  <DQ>
    0DWm7PMtaQl1X3P8G2Gmgvjdlfj7qfAtWtBZ/ufG8oplyyab4oOD6FwSwlm82dV8iol9fy2Xa
    HjZDir6L/Ae4Q==
  </DQ>
  <InverseQ>
    sD2Vl/CCVTDbhhLwdfc4IQDBOh8xpBUV7PPM5LFGjiLetlfwaYi7Bp2ol8WF1MX88iCV2E3xO
    PCNfbMhvEB5dA==
  </InverseQ>
  <D>
    REUnMUhO6ZX6NxoCwkJ7El5wXAVGtlNJsnPqFygbeEjlBvD6TZx9TqnpP/8IX7WK6JUFWd9kn
    QJvCWeJjhbjnImSS/3xc+v+m4glnnebZbaghvfunbI++fQaNAFRVT1hLvEGknqC/7zsrUM04o
    gU7hP+XgdFTJ1QYGfGHl5c0IE=
  </D>
</RSAKeyPair>

C.3.3 XKMS Service Private Key Parameters

<?xml version="1.0" encoding="utf-8"?>
<RSAKeyValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:xsd="http://www.w3.org/2001/XMLSchema"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <Modulus>189VeX3+tAcwQPGMtYm8/CEKRfe6DtBFZ11SAREHhMIqf68/dsmbes0q0dnxWQcKfQ
        tVDfp6Rf0u
lk5rZZ3j2vHHK9OFXMfaF+zJdATJ3KkXd5myjNf2clYWqKZp7K8/7Wo/qIiL8EsCT7yihRQvkYfY
prFbF9GjKJPs4ng+zE8=</Modulus>
  <Exponent>AQAB</Exponent>
  <P>6+mJu5c75rQ2D0NjjZVgpzwHC2Rqcz+Dqs8E+f6yN2cYH5DTRKk08YGWSJanxwkNHCRSOC8K
        ZspL
zmnVUyKavw==</P>
  <Q>6i+ZxJX3FDz8SwIvFEp+Vzu2C+N3USgOWGghrZuYzxKSoawpmIU0+22IVug1H3w0c7ae+5d3
        58O8
APR+7v0CcQ==</Q>
  <DP>Wizzy/P8HqyF+YGd3THbNzGX07/3fMQrdTAay+CSiODsdKxsRVOUfDg3lNmZmlgYXch4cSd
        yB2aO
YYFM3LFeiw==</DP>
  <DQ>0GAuiHeP9FgXfX6h+YIXTPN6lrV9k576tLtjTCCpJYe3JVgVYvsUG6xopjvUGQHhghy69c7
        fCEBn
5smmsGw8YQ==</DQ>
  <InverseQ>phQH0GiKxdQnq7xj+5z69zLL6cI/53STn/XXZz9A/XRPUJecJxUguJHgbrKAI1ayl
        LBZB0CfS+UV
kIkoF/nP2g==</InverseQ>
  <D>ybPx+oRlO1QAqKJa1g2vgaNL28tGrbPBOnPBQlftRArJ998OnPKfi+4YWFyvs3reNbMSwubZ
        w3J4
SWlv/WDN5Ux2ozdqjl8DShZfhpeRhVIkygg8tDqqbkVmuzQyUbDR5NncMiEPX5errlrCydwsc2Og
UDHYXslORPsRFh/Fk6E=</D>
</RSAKeyValue>
<?xml version="1.0" encoding="utf-8"?>
<RSAKeyPair xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <Modulus>
    189VeX3+tAcwQPGMtYm8/CEKRfe6DtBFZ11SAREHhMIqf68/dsmbes0q0dnxWQcKfQtVDfp6R
    f0ulk5rZZ3j2vHHK9OFXMfaF+zJdATJ3KkXd5myjNf2clYWqKZp7K8/7Wo/qIiL8EsCT7yihR
    QvkYfYprFbF9GjKJPs4ng+zE8=
  </Modulus>
  <Exponent>AQAB</Exponent>
  <P>
    6+mJu5c75rQ2D0NjjZVgpzwHC2Rqcz+Dqs8E+f6yN2cYH5DTRKk08YGWSJanxwkNHCRSOC8KZ
    spLzmnVUyKavw==
  </P>
  <Q>
    6i+ZxJX3FDz8SwIvFEp+Vzu2C+N3USgOWGghrZuYzxKSoawpmIU0+22IVug1H3w0c7ae+5d35
    8O8APR+7v0CcQ==
  </Q>
  <DP>
    Wizzy/P8HqyF+YGd3THbNzGX07/3fMQrdTAay+CSiODsdKxsRVOUfDg3lNmZmlgYXch4cSdyB
    2aOYYFM3LFeiw==
  </DP>
  <DQ>
    0GAuiHeP9FgXfX6h+YIXTPN6lrV9k576tLtjTCCpJYe3JVgVYvsUG6xopjvUGQHhghy69c7fC
    EBn5smmsGw8YQ==
  </DQ>
  <InverseQ>
    phQH0GiKxdQnq7xj+5z69zLL6cI/53STn/XXZz9A/XRPUJecJxUguJHgbrKAI1aylLBZB0CfS
    +UVkIkoF/nP2g==
  </InverseQ>
  <D>
    ybPx+oRlO1QAqKJa1g2vgaNL28tGrbPBOnPBQlftRArJ998OnPKfi+4YWFyvs3reNbMSwubZw
    3J4SWlv/WDN5Ux2ozdqjl8DShZfhpeRhVIkygg8tDqqbkVmuzQyUbDR5NncMiEPX5errlrCyd
    wsc2OgUDHYXslORPsRFh/Fk6E=
  </D>
</RSAKeyPair>

Appendix D References

[388][CSP] C. A. R. Hoare, Communicating Sequential Processes, Prentice Hall, 1985, http://www.usingcsp.com/

[389][P3P] Lorrie Cranor, Marc Langheinrich, Massimo Marchiori, Martin Presler-Marshall, Joseph Reagle,  The Platform for Privacy Preferences 1.0 (P3P1.0) Specification, W3C Recommendation 16 April 2002, http://www.w3.org/TR/2002/REC-P3P-20020416/

[390][PKIX] R. Housley, W. Ford, W. Polk, D. Solo, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, IETF RFC 2459, January 1999, http://www.ietf.org/rfc/rfc2459.txt

[391][PKCS1] Kaliski, B., PKCS #1: RSA Encryption Version 2.0, RSA Laboratories, also IETF RFC 2437, October 1998. http://www.ietf.org/rfc/rfc2437.txt.

[392][RFC2119]S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119, March 1997, http://www.ietf.org/rfc/rfc2119.txt.

[393][RFC2459]R. Housley, W. Ford, W. Polk, D. Solo, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, IETF  RFC 2459, January 1999. http://www.ietf.org/rfc/rfc2459.txt

[394][RFC-2104]   Krawczyk, H., Bellare, M. and R. Canetti, HMAC: Keyed Hashing for Message Authentication, IETF  RFC 2104, February 1997. http://www.ietf.org/rfc/rfc2104.txt

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

[396][RFC-2373]     R. Hinden, S. Deering,IP Version 6 Addressing Architecture,   IETF RFC 2373 July 1998., http://www.ietf.org/rfc/rfc2373.txt

[396a][RFC 2396]     T Berners-Lee, R Fielding and L. Masinter Uniform Resource Identifiers, IETF RFC 2396 August 1998. http://www.ietf.org/rfc/rfc2396.txt

[397][RFC-2782]A. Gulbrandsen, P. Vixie, L. Esibov, A DNS RR for specifying the location of services (DNS SRV), IETF RFC 2782, February 2000, http://www.ietf.org/rfc/rfc2782.txt

[398][SOAP] Martin Gudgin, et al. SOAP Version 1.2 Part 1: Messaging Framework, W3C Recommendation 24 June 2003, http://www.w3.org/TR/2003/REC-soap12-part1-20030624/

[399][XMLP] XML Protocol Working Group, http://www.w3.org/2000/xp/Group/

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

[401][X509] ITU-T Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, June 1997.

[402][XML] T. Bray, E. Maler, J. Paoli, C. M. Sperberg-McQueen. Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation.  October 2000. http://www.w3.org/TR/2000/REC-xml-20001006

[403][XML-SIG]  D. Eastlake, J. R., D. Solo, M. Bartel, J. Boyer , B. Fox , E. Simon. XML-Signature Syntax and Processing, W3C Recommendation, 12 February 2002. http://www.w3.org/TR/xmldsig-core/

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

[405][XML-Enc]Donald Eastlake, Joseph Reagle, Takeshi Imamura, Blair Dillaway, Ed Simon, XML Encryption Syntax and Processing, W3C Recommendation, 10 December 2002, http://www.w3.org/TR/xmlenc-core/

[406][XML-NS] T. Bray, D. Hollander, A. Layman. Namespaces in XML. W3C Recommendation. January 1999. http://www.w3.org/TR/1999/REC-xml-names-19990114

[407][XML-Schema1] H. S. Thompson, D. Beech, M. Maloney, N. Mendelsohn. XML Schema Part 1: Structures, W3C Recommendation 2 May 2001, http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/, latest draft at http://www.w3.org/TR/xmlschema-1/

[408][XML-Schema2] P. V. Biron, A. Malhotra, XML Schema Part 2: Datatypes; W3C Recommendation 2 May 2001, http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/, latest draft at http://www.w3.org/TR/xmlschema-2/

[409][XAdES] J.C. Cruellas, G. Karlinger, K. Sankar XML Advanced Electronic Signatures; W3C Note 20 February 2003 http://www.w3.org/TR/XAdES/

Appendix E Changes

This appendix documents changes (other than very minor editorial changes) made since the xx.xx of the XKMS 2.0 Specification. Each entry contains: