Movatterモバイル変換

XMLKey Management Specification (XKMS 2.0)

Version 2.0

W3C Recommendation 28 June 2005

This version:

http://www.w3.org/TR/2005/REC-xkms2-20050628/

Latest version:

http://www.w3.org/TR/xkms2/

Previous version:

http://www.w3.org/TR/2005/PR-xkms2-20050502/

Editors:

Phillip Hallam-Baker, Verisign

Shivaram H. Mysore

Contributors:

See theAcknowledgments.

Please refer to theerratafor this document, which may include some normative corrections.

See alsotranslations.

Copyright ©2005W3C^® (MIT,ERCIM,Keio), All Rights Reserved. W3Cliability,trademark anddocument use rules apply.

1Introduction

[8]This document specifies protocols fordistributing and registering public keys, suitable for use in conjunctionwith the standard for XML Signatures[XML-SIG] definedby the World Wide Web Consortium (W3C) and the Internet Engineering TaskForce (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 particularunderlying public key infrastructure (such as X.509) but are designed to becompatible with such infrastructures.

[10]This document defines the following servicespecifications:

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.1Editorial and ConformanceConventions

[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 keywordsto unambiguously specify requirements over protocol and application featuresand behavior that affect the interoperability and security ofimplementations. These key words are not used (capitalized) to describe XMLgrammar; schema definitions unambiguously describe such requirements and wewish to reserve the prominence of these terms for the natural languagedescriptions of protocols and features. For instance, an XML attribute mightbe described as being "optional." Compliance with the XML-namespacespecification [XML-NS] is described as"REQUIRED."

1.2Definition of Terms

[17]The following terms are used within thisdocument 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.

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

[20a]Payload Security
    Use of end-to-end security mechanisms, such as XML DSIG, not dependent on the transport mechanism (HTTP, TLS, SOAP, ...).

1.3Versions Namespaces and Identifiers

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

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

[22]This namespace is also used as the prefix foralgorithm identifiers used by this specification. While applications MUSTsupport XML and XML namespaces, the use of internal entities [XML] or the "xkms" XML namespace prefix anddefaulting/scoping conventions are OPTIONAL; we use these facilities toprovide compact and readable examples.

[23]In this document, certain namespace prefixesrepresent certain namespaces in the schema fragments (shown on a yellowbackground) as follows:

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

[25]In all examples (shown on a light bluebackground) and in the body of the text the default namespace refers to thexkms namespace itself. This means that namespace prefixes are omitted for allelement and type names in thexkmsnamespace.

[26]These namespaces are declared in the XKMSschema 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 Proposed Recommendation Candidate 2005      </documentation>   </annotation>   <!-- /Namespace -->

   ...

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

[27]Internet Protocol addresses and Domain NameSystem names used in examples are purposely chosen to avoid confusion withassigned addresses and names. All Internet Protocol Addresses are in thereserved non-routable network 10.x.x.x. All DNS names are in the reserveddomainexample.com.

1.4Key Information Service Overview(Non-Normative)

[28]X-KISS allows a client to delegate part or allof 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 ofapplications using XML Signature[XML-SIG]. Bybecoming a client of the XKMS service, the application is relieved of thecomplexity and syntax of the underlying PKI used to establish trustrelationships, which may be based upon a different specification such asX.509/PKIX, SPKI or PGP.

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

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

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

[31]In the case of an encryption operation:

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

1.5Key Registration Service Overview(Non-Normative)

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

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

[34]The protocol provides for authentication of theapplicant 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 theprivate key to the client is provided in the case that the private key isgenerated by the registration service.

[35]This document specifies means of registeringRSA and DSA keys and a framework for extending the protocol to support othercryptographic algorithms such as Diffie-Hellman and Elliptic Curvevariants.

1.6Structure of this document

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

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.

2Protocol Exchanges

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

[38]XKMS protocol messages share a common formatthat may be carried within a variety of protocols.  A binding to theSOAP [SOAP][XMLP] messageprotocol is provided inPart II:Protocol Bindings. It is recommended XKMS implementers support SOAP overHTTP for interoperability purposes. XKMS is transport protocol agnostichowever and MAY be layered over any SOAP transport.

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

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

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

[42]The XKMS protocol consists of pairs of requestsand responses. The XKMS protocol binding allows for the case in which anadditional request/response round trip is required to support cases such aspending responses and two-phase requests for replay attack protection.

[43]Each XKMS response message contains aMajorResult code thatdetermines whether the response is final or further processing is required.The protocol is specified in the CSP formalism[CSP] asfollows:

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 messageprotocol and the message processing steps taken by both parties in each ofthe messages.

2.1All Messages

[45]The following processing steps are taken withrespect to all messages regardless of whether they are a request or aresponse:

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 ofService is verified
The Authentication Signature value is verified (if required).

2.1.1Example

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

2.2Request Types

[46]The XKMS specification defines three types ofrequest:

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 protocoloptions, including asynchronous processing, two-phase requests and compoundrequests. The client specifies the protocol options it supports in relationto a specific request throughResponseMechanism elements in the request.

[48]The means by which the service specifiesprotocol options which it accepts is outside the scope of this document. Ifthe mechanism used for this purpose uses URI based identifiers for thispurpose 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.3Responses

[49]All XKMS responses contain a Result codecomprised of a major and minor component. If a service applies a protocolprocessing option the client is informed by means of theMajorResult code value of theresponse.

2.4Synchronousand Asynchronous Processing

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

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

[51]A client MAY advise a service that it willaccept asynchronous processing of a request by specifying theResponseMechanism valuePending. An XKMS service that receives a request thatspecifies theResponseMechanism valuePending MAY respond either synchronously orasynchronously. If the service is to respond asynchronously it advises theclient that the response value will be returned asynchronously by specifyingtheMajorResult codePending.

[52]An XKMS service MUST NOT return theMajorResult codePending unless theResponseMechanism valuePending was specified in the corresponding request. Ifan XKMS service receives a request that cannot be processed synchronously andtheResponseMechanism valuePending is not specified theMajorResult codeReceiver andMinorResult codeNotSynchronous are returned.

[53]Asynchronous processing MAY be used to allowadministrator intervention during the processing of a request. For example anadministrator might be required to verify and approve all X-KRSS Registrationrequests before they are processed.

2.4.1SynchronousRequest / Response

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

Requestor generation of the Request Message

Nonce andOriginalRequestId  are not present
ResponseMechanism valuePending MAY be specified but the service will ignore it

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 ofId in the request message

Nonce is not present
MajorResult is set to a Final result value

Requestor processing of the Response Message

The value ofRequestId is verified

2.4.2Example

2.4.2.1 Request

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

2.4.2.2 Response

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

2.5AsynchronousProcessing

[55]Asynchronous processing consists of a sequence of request/responsepairs; an initial request which specifies the request values, zero ormore status requests and a pending request which obtains the result ofthe operation. The client may issue status requests in order to pollthe status of an asynchronous operation independently of the use ofthe notification mechanism indicated (by the client) in the initialrequest.

2.5.1 Initial Request

[56]The initial request message is processed asfollows:

Requestor generation of the Initial Request Message

Nonce andOriginalRequestId  are not present
ResponseMechanism valuePending 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 valueId in the initial request message

Nonce is not present

MajorResult is set toPending

Requestor processing of the Initial Response Message

Register request as pending completion, poll processing status and/or wait for notification

2.5.2 Status Request

[56a]The client may poll the status of the asynchronous operation as follows:

Requestor generation of the Status Request Message

The request element isStatusRequest

OriginalRequestId is set to the value ofId in the initial request message
ResponseId is set to value ofId in the initial response message

Service processing of the Status Request Message

Identify pending request usingOriginalRequestId andResponseId.

Service generation of the Status Response Message

RequestId is set to the value ofId in the Status request message

Nonce is not present

Requestor processing of the Status Response Message

For non-compound messages, theResultMajor attribute indicates the status of the operation. For compound messages, theSuccess,Failure, andPending attributes further indicate the number of inner requests that have the respective status.

2.5.3 Pending Request

[57] The client determines, through notification or polling, that therequested operation has completed and requests the return of theresult values by issuing aPendingRequest message as follows:

Requestor generation of the Pending Request Message

The request element isPendingRequest

OriginalRequestId is set to the value ofId in the initial request message
ResponseId is set to value ofId 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 ofId in the Pending request message

Nonce is not present

Requestor processing of the Pending Response Message

IfMajorResult  is set to a non-final value consider it to befailure

[58]The client MAY request the return of the resultvalues before processing has been completed. In this case the serviceresponds to the Pending Request with theMajorResultcodePending.

2.5.4 Example

2.5.4.1 Request

<?xml version="1.0" encoding="utf-8"?><LocateRequest      Service="http://www.example.org/XKMS"      xmlns="http://www.w3.org/2002/03/xkms#">  <ResponseMechanism>http://www.w3.org/2002/03/xkms#Pending</ResponseMechanism>  <PendingNotification Mechanism="urn:ietf:rfc:822"       Identifier="mailto:alice@example.org">  <QueryKeyBinding /></LocateRequest>

2.5.4.2 Response

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

2.5.4.3 Notification

The XKMS service notifies the client about the completion of the request processing using the notification mechanism specified in the<PendingNotification> element.

2.5.4.4 Pending Request

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

2.5.4.5 Response

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

2.6Two-Phase RequestProtocol

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

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

[61]In the first phase the requestor presents the request and the service responds theMajorResult valueRepresent 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 supportsthe two-phase request protocol by specifying theResponseMechanism valueRepresent. An XKMS service advises the client that theuse of the two-phase request protocol is required by specifying theMajorResult codeRepresent.

[64]An XKMS service MUST NOT return theMajorResult codeRepresent unless theResponseMechanism valueRepresent was specified in the corresponding request.If an XKMS service requires the use of the two-phase request protocol and theResponseMechanism valueRepresent is not specified in the corresponding requesttheMajorResult codeSender andMinorResult codeRepresentRequired are returned.

[65]The two-phase request protocol bears somesimilarity to asynchronous request processing. Both mechanisms introduce anextra protocol round trip but each serve different purposes. The purpose ofasynchronous processing is to allow a delay to be introduced between theinitial request and the return of the result. In the two-phase requestprotocol however there is no delay between the first request and the firstresponse or between the first response and the second request. The purpose ofthe two-phase request protocol is to allow a service to protect itselfagainst a denial of service attack by allowing the service to perform alightweight authentication of the source of the request.

[66]The service SHOULD verify that the nonce valuespecified in a second phase request was recently generated by the service.The service MAY verify that the nonce value has not been previously respondedto. The actual construction of the nonce value is outside the scope of thisspecification and may be chosen as site specific circumstances dictate. Thetechniques described in the sectionConstruction ofNonce Values describe a technique that reduces or avoids the need tomaintain server state in order to meet this requirement.

2.6.1 Processing Steps

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

Requestor generation of the Phase 1 Request Message

ResponseMechanism valueRepresent 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 valueId in the Phase 1 request message

Nonce value is set in accordance with service replay protection requirements

MajorResult is set toRepresent

Requestor processing of the Phase 1 Response Message

Proceed to phase 2

[68]In the Second phase of the two-phase protocolthe processing steps specified for the single phase case are performed withthe following exceptions:

Requestor generation of the Phase 2 Request Message

OriginalRequestId  set to the value ofId in the Phase 1 request message
Nonce value is set to the value ofNonce in the Phase 1 response message

Service processing of the Phase 2 Request Message

Verify value ofNonce

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

IfMajorResult 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 mannerthat the service chooses. It may be useful to construct the nonce so as topermit the service to determine that they were generated by the server at aspecific time in a computationally efficient manner as follows.

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

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

[72]The service may limit the time interval inwhich replay attacks are possible by rejecting nonce values that specify anunacceptable time value or an incorrect MAC value.

[73]The service may prevent replay attackscompletely by tracking the serial numbers for which responses have alreadybeen given, using the nonce time construction value to limit the intervalover which the serial number is tracked.

[74]The nonce value may be encrypted to avoidleaking information such as the serial number value which might be ofinterest to an attacker.

2.6.3Example

2.6.3.1 Request 1

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

2.6.3.2 Response 1

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

2.6.3.3 Request 2

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

2.6.3.4 Response 2

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

2.7Two-Phase Protocol withAsynchronous Processing

[75]The two-phase protocol may be combined withAsynchronous Processing. In this case the operation will consist of threeround trips as follows:

• Initial Request / Phase 1
• Initial Request / Phase 2
• Pending Response

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

• OriginalRequestId  set to that value ofId in Initial Request / Phase 1 inboth subsequent requests.
• Nonce value is set to the value ofNonce in Phase 1 response inboth subsequent requests.

2.8Compound Requests and Responses

[77]An XKMS service MAY support processing ofCompound Requests. A compound request permits multiple XKMS requests to bemade at the same time. A compound request consists of an outer request andone or more inner requests. There is no ordering implicit in the innerrequests. The semantics of making a set of requests as a compound request areexactly the same as if each individual request in the set had been madeseparately and simultaneously.

[78]The response to a compound request is acompound response. A compound response consists of an outer response and zeroor more inner responses. If theResultMajor valueof the outer response isSuccess the compoundresponse SHOULD contain an inner response response element corresponding toeach inner request element of the compound request. If the theResultMajor value of the outer response is notSuccess the response MUST NOT contain any innerresponses. If a compound response has an outerResultMajor valueSuccessbut does not contain a response corresponding to an inner request, that inner request is assumed to have failed.

[79]An XKMS service MAY support the use of the twophase protocol on the outer request of a compound response. The two-phaseprotocol SHOULD NOT be used on an inner response. If an inner requestspecifies theResponseMechanism valueRepresent the value SHOULD be ignored.

[80]An XKMS service MAY support the use ofasynchronous processing in conjunction with a compound request. Asynchronousprocessing MAY be performed on the compound request as a whole, on individualinner requests or both.

[81]If asynchronous processing is to be performedon the compound request as a whole the outer request specifies theResponseMechanism valuePending. If the service decides to return an asynchronousresponse a compound response is returned with a ResultMajor code ofPending. When the service has completed the processing, as determined through polling or notification, the client issues aPendingRequest message forthe outer request to which the service replies with a compound responsereturning either the inner responses corresponding to the original innerrequests or an error report.

[82]If asynchronous processing is performed on theindividual inner requests each inner request for which an asynchronousresponse is to be accepted specifies the ResponseMechanism valuePending. If the service decides to return an asynchronousresponse to an inner request a compound response is returned with an outerResultMajor code ofSuccess and an innerResultMajor code ofPendingfor the requests for which an asynchronous response is to be issued. Aservice MAY return synchronous and asynchronous responses in a singlecompound response.

[83]Since the semantics of a compound request areexactly the same as if each inner request were made separately a client MAYissue separate pending requests to obtain the results of the inner requestsof a previous compound request.

2.8.1 Example

2.8.1.1 Request 1

<?xml version="1.0" encoding="utf-8"?><CompoundRequest      Service="http://www.example.org/XKMS"      xmlns="http://www.w3.org/2002/03/xkms#">  <LocateRequest        Service="http://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        Service="http://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.2 Response 1

<?xml version="1.0" encoding="utf-8"?><CompoundResult      Service="http://www.example.org/XKMS"      ResultMajor="http://www.w3.org/2002/03/xkms#Success"      RequestId="I264f5da49b1ff367d4e7aef1f7a1df1a"      xmlns="http://www.w3.org/2002/03/xkms#">  <LocateResult        Service="http://www.example.org/XKMS"        ResultMajor="http://www.w3.org/2002/03/xkms#Success"        RequestId="I8c26be5f1b4dd228b43fb6eaee285faa">    <UnverifiedKeyBinding>      <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        Service="http://www.example.org/XKMS"        ResultMajor="http://www.w3.org/2002/03/xkms#Success"        RequestId="If8e63d729384ad35498e7b65b3dc785e">    <UnverifiedKeyBinding>      <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.9Security Binding

[84]The security concerns that an XKMS service isrequired to address are dependent on the specific service deployment. Forexample a free XKMS Location service may not require controls for RequestAuthentication or to prevent Request Replay attacks while a paid Validateservice might. The application of security enhancements is addressed inPart II which describesthe application of the following security enhancements:

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

[85]The use of security enhancements is furtherdiscussed in the sectionSecurityConsiderations below.

3 MessageSyntax

3.1 MessageBase

3.1.1TypeMessageAbstractType

[86]TheMessageAbstractTypeabstract type is the type from which all XKMS message element types arederived. TheMessageAbstractType abstract typecontains 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 theId attribute specified in theMessageAbstractType abstract type.

<MessageExtension>   [Any Number]

An extension element derived from theMessageExtensionAbstractType.

<OpaqueClientData>   [Optional]

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

Id   [Required]

A unique identifier generated by the originator.

Service   [Required]

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

Nonce   [Optional]

Cryptographically random data used to defend against replay attack.

[87]The following schema defines theMessageAbstractType 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.2Element<ds:Signature>

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

[89]Validation of XML Signatures MUST be doneindependent of any ancestral XML context of the message.  This may beachieved by:

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

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

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

3.1.3Element<MessageExtension>

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

[93]The following schema defines theMessageExtension element:

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

3.1.4Element<OpaqueClientData>

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

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

[96]The following schema defines theOpaqueClientData element:

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

3.2 RequestMessage

3.2.1TypeRequestAbstractType

[97]TheRequestAbstractTypeabstract type is the type from which all XKMS request element types arederived. TheRequestAbstractType abstract typeinherits the element and attributes of theMessageAbstractType abstract type and in addition containsthe following elements and attributes

<ResponseMechanism>   [Any Number]

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

<RespondWith>   [Any Number]

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

<PendingNotification>   [Optional]

Specifies a means by which the service may notify the requestor of the completion of a pending response. If the<PendingNotification> element is present the valuePending 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 the 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 theRequestAbstractType 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.2Element<ResponseMechanism>

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

[100]ResponseMechanismvalues are specified asanyURIs, the following identifiers are defined:

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

   <!-- 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.3Element<RespondWith>

[102]The<RespondWith> element in arequest specifies one or more URI values that SHOULD resolve to dataelements provided in either the<ds:KeyInfo> element or private keyinformation defined in the sectionCryptographic Algorithm Specific Parametersbelow. The<RespondWith> element SHOULDbe included in requests of typeLocateRequest,ValidateRequest,RegisterRequest,ReissueRequest,RevokeRequest, andRecoverRequest. The XML Signature elements aredescribed here for convenience. The normative reference is the XMLDigital Signature Specification[XML-SIG].

[103]The Service SHOULD return any data elements that are resolvable<RespondWith> URI values and thatare supported by the Service. The Service MAY return additional dataelements not requested. In particular, the service MAY return dataelements specified in the request with the response.

[104]RespondWith valuesare specified asanyURIs, the following identifiers are defined (all names under the first columnn are prefixed with URIhttp://www.w3.org/2002/03/xkms#):

[104a](In the above table,* stands for one or more.).

[105]For example, a client that has no X.509processing capability might perform aLocateoperation to obtain the public key parameters and name information from a<ds:Keyinfo> element that specifies only acertificate. TheRespondWith element values in thiscase would beKeyName andKeyValue.

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

   <!-- 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#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.4Element<PendingNotification>

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

[108]The<PendingNotification> element contains the followingattributes

Mechanism   [Required]

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

Identifier   [Required]

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

[109]The following mechanisms are defined:

[110]The following schema defines the<PendingNotification> element andPendingNotificationType 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.5Element<PendingRequest>

[111]ThePendingRequestelement is used to request the result of a previously presented request forwhich theMajorResultcodePending wasreturned. ThePendingRequest element inherits the element andattributes ofRequestAbstractType and the followingattribute:

ResponseId   [Required]

The value of theId attribute sent in the original response containing theMajorResult codePending.

[112]If the value of ResponseId is unknown to theservice the resultSender.UnknownResponseId isreturned.

[112a]TheRespondWith elementMUST NOT be presentinside aPendingRequest element.

[113]The following schema defines thePendingRequest element andPendingRequestType 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.3 ResponseMessage

3.3.1Element<Result>

[114]TheResultType type isthe type from which all XKMS response element types are derived. TheResultType  type inherits the element and attributesof theMessageAbstractType abstract type and inaddition 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 identifierId specified in the request.

[115]If theMajorResultvalue has the valueRepresent theNonce attribute MUST be present andMUST NOT be the empty string.

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

[117]Security Consideration: Care must betaken when signing responses to ensure that the service does not provide asigning oracle, that is sign messages whose content is guessable by anattacker. Implementations MUST ensure that response messages contain asufficient quantity of  unpredictable data such as a pseudo-randomlychosenId attribute. For more information see thesectionSecurity Considerations.

[118]The following schema defines the<Result> element andResultType type:

<!-- 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"/>             <enumeration                  value="http://www.w3.org/2002/03/xkms#OptionalElementNotSupported"/>             <enumeration                  value="http://www.w3.org/2002/03/xkms#ProofOfPossessionRequired"/>             <enumeration                  value="http://www.w3.org/2002/03/xkms#TimeInstantNotSupported"/>             <enumeration                  value="http://www.w3.org/2002/03/xkms#TimeInstantOutOfRange"/>          </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.1Result Codes

[119]Result codes consist of a major code and anoptional minor code. The major and minor codes are expressed as XMLanyURI types.This specification uses the notationResultMajor.ResultMinor to specify a result code. For examplethe result codeSender.NoMatch indicates aResultMajor code ofSender and aResultMinor code ofNoMatch.

[120]The followingResultMajor codes are defined (theanyURI name entries are all prefixed withhttp://www.w3.org/2002/03/xkms#):

[121]TheResultMajor codesSuccess,VersionMismatch,Sender andReceiver areFinal, that is the protocol has completed when the code is returned.TheResultMajor codesRepresent andPending areNotFinal and indicate that further processing is necessary to receive theresult.

[122]The followingResultMinor codes are defined (theanyURI name entries are all prefixed withhttp://www.w3.org/2002/03/xkms#):

3.3.2Element<RequestSignatureValue>

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

[124]A service SHOULD include the<RequestSignatureValue> element in a response if thefollowing conditions are satisfied and MUST NOT include the valueotherwise:

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

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

• The corresponding request was not authenticated, or
• The content of the<ds:SignatureValue> element used in the request does not match the content of the<RequestSignatureValue> element in the response.

[126]The<RequestSignatureValue> element is ofds:SignatureValueType type specified in the XML Signaturespecification[XML-SIG].

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

3.4 CompoundRequests

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

3.4.1Element<CompoundRequest>

[128]The<CompoundRequest> element is used to issue multiplerequests at the same time. The<CompoundRequest> element inherits the element andattributes ofRequestAbstractType together with thefollowing elements in any order:

<LocateRequest>   [Any Number]

An XKMSLocate Request

<ValidateRequest>   [Any Number]

An XKMSValidate Request.

<RegisterRequest>   [Any Number]

An XKMSRegister Request.

<ReissueRequest>   [Any Number]

An XKMSReissue Request.

<RecoverRequest>   [Any Number]

An XKMSRecover Request.

<RevokeRequest>   [Any Number]

An XKMSRevoke Request.

[128a]TheRespondWith element MUST NOT be a direct child of aCompoundRequest element. Each request that is encapsulated inside aCompoundRequest element may or may not have its ownRespondWith element child.

[129]The following schema defines the<CompoundRequest> element andCompoundRequestType 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.2Element<CompoundResult>

[130]The<CompoundResult> element is used to respond to a<CompoundRequest>. If the compound result hastheMajorResult valueSuccess it contains multiple responses corresponding tothe multiple requests specified in the<CompoundRequest>. The<CompoundResult> element inherits the element andattributes ofResultType together with the followingadditional elements in any order:

<LocateResult>   [Any Number]

An XKMSLocate Result.

<ValidateResult>   [Any Number]

An XKMSValidate Result.

<RegisterResult>   [Any Number]

An XKMSRegister Result.

<ReissueResult>   [Any Number]

An XKMSReissue Result.

<RecoverResult>   [Any Number]

An XKMSRecover Result.

<RevokeResult>   [Any Number]

An XKMSRevoke Result.

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

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

3.5 StatusRequest

3.5.1Element<StatusRequest>

[132]TheStatusRequestelement is used to request that the service return the status of a pendingrequest by means of a<StatusResult> element.TheStatusRequest element inherits the element and attributesofPendingRequestType.TheRespondWith element MUST NOT be presentinside aStatusRequest element.

[133]The following schema defines theStatusRequest element andStatusRequestType type:

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

3.5.2Element<StatusResult>

[134]The<StatusResult> element returns the status of apending request. In the case of a non-compound request, the status is indicated in theResultMajor attribute. For a compound request, the statusof each of the inner compound requests is indicated with three different optionalattributes, defined here below.

[134a]TheStatusResultType inherits the element and attributesofResultType and contains the followingadditional attributes for reporting the status of compoundrequests:

Success   [Optional]

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

Failure   [Optional]

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

Pending   [Optional]

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

[135]The following schema defines theStatusResult element andStatusResultType 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 -->

4KeyInformation Service Description

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

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

[138]For example Alice signs a document and sendsit to Bob with a<ds:KeyInfo> element thatspecifies only the signing key data. On receiving the message Bob retrievesadditional information required to validate the signature and adds thisinformation into the<ds:KeyInfo> element whenhe passes the document on to Carol (see Figure 1 below).

[139]

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

4.1LocateService

[141]The X-KISSLocateservice resolves a<ds:Keyinfo> element butdoes NOT REQUIRE the service to make an assertion concerning the validity ofthe binding between the data in the<ds:Keyinfo> element.

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

[143]

[144]Figure 2: LocateService Provides Name Resolution

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

4.1.1Example: DataEncryption

[146]Alice wants to send an encrypted email to Bobbut does not know his encryption key. Alice can use both the S/MIME and PGPsecure email formats. Alice's client uses DNS to locate the XKMS service thatprovides a Locate service for keys bound to the domain example.com then sends an XKMS Locate request to the discoveredXKMS service for a key bound to bob@example.com and the S/MIME or PGP protocol. The applicationthen verifies that the certificate obtained meets its trust criteria bystandard 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#"           Service="http://www.example.org/XKMS"      xmlns="http://www.w3.org/2002/03/xkms#">  <RespondWith>http://www.w3.org/2002/03/xkms#KeyName</RespondWith>  <RespondWith>http://www.w3.org/2002/03/xkms#KeyValue</RespondWith>  <RespondWith>http://www.w3.org/2002/03/xkms#X509Cert</RespondWith>  <RespondWith>http://www.w3.org/2002/03/xkms#X509Chain</RespondWith>  <RespondWith>http://www.w3.org/2002/03/xkms#PGPWeb</RespondWith>  <RespondWith>http://www.w3.org/2002/03/xkms#PGP</RespondWith>  <QueryKeyBinding>    <KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>    <UseKeyWith Application="urn:ietf:rfc:2440"          Identifier="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#"           Service="http://www.example.org/XKMS"      ResultMajor="http://www.w3.org/2002/03/xkms#Success"      RequestId="I8fc9f97052a34073312b22a69b3843b6"      xmlns="http://www.w3.org/2002/03/xkms#">  <UnverifiedKeyBinding>    <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.2Example:Document Signature

[149]Bob receives the signed document from Alicewhich specifies Alice's X.509v3 certificate but not the key value. Bob'semail client is not capable of processing X.509v3 certificates but can obtainthe 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<KeyValue> element 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#"           Service="http://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.509v3certificate from the<ds:Keyinfo> element andreturns the key values. The location service DOES NOT report the revocationstatus 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#"           Service="http://www.example.org/XKMS"      ResultMajor="http://www.w3.org/2002/03/xkms#Success"      RequestId="I045c66f6c525a9bf3842ecd3466cd422"      xmlns="http://www.w3.org/2002/03/xkms#">  <UnverifiedKeyBinding>    <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.2ValidateService

[153]The X-KISS Validate Service allows all that theLocate Service does, and in addition, the client may obtain an assertionspecifying the status of the binding between the public key and other data,for example a name or a set of extended attributes. Furthermore the servicerepresents that the status of each of the data elements returned is valid andthat all are bound to the same public key. The client sends to the XKMSservice a prototype containing some or all of the elements for which thestatus of the key binding is required. If the information in the prototype isincomplete, the XKMS service MAY obtain additional data required from anunderlying PKI Service. Once the validity of the key binding has beendetermined the XKMS service returns the status result to the client (Figure3).

[154]

[155]Figure 3: Validate Service Provides KeyValidation

4.2.1Example:Document Signature

[156]Bob has received Alice's message and his emailclient has verified the signature on the document against the public key inthe certificate supplied by Alice. It is not yet known whether thecertificate is considered trustworthy however. To determine this, Bob's emailclient sends the certificate chain to an XKMS Validate service. The servicereports back that it has successfully determined that the key binding has atrusted 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#"           Service="http://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#"           Service="http://www.example.org/XKMS"      ResultMajor="http://www.w3.org/2002/03/xkms#Success"      RequestId="Ie26380bfeb9d0c5bc526d5213a162d46"      xmlns="http://www.w3.org/2002/03/xkms#">  <KeyBinding>    <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.3Using Locate andValidate

[159]The Locate and Validate operations are bothused to obtain information about a public key from an XKMS Service. Locateand Validate services are both expected to attempt to provide correctinformation to the requestor. The Locate and Validate services differ in theextent to which the service vouches for the trustworthiness the informationreturned.

[160]A Location service SHOULD attempt to provideonly information which is trustworthyto the best of its knowledge butdoes not provide any assurance that it will do so. Information obtainedfrom 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 byperforming the necessary trust path verification locally.

[161]A Validation service undertakes to only returninformation which has been positively validated by the XKMS Service asmeeting specific validation criteria. A client MAY rely on the informationreturned by the service without further validation provided that the clienthas a means to determine that the information returned is authentic and isassured that the validation service applied the means of validationappropriate to the circumstances.

[162]No single set of validation criteria areappropriate to every circumstance. Applications involving financialtransactions are likely to require the application of very specificvalidation criteria that ensure that certain contractual and/or regulatorypolicies are enforced. The Locate service provides a key discovery functionthat is neutral with respect to the validation criteria that the clientapplication may apply. The Validate service provides a key discovery andvalidation function that produces a results which are each specific to asingle set of validation criteria.

4.3.1DNS Integration

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

[164]Figure 5 shows an example of using the DNS SRVrecord to perform discovery of XKMS services. The email client requests a keyfor bob@example.com from a trusted Validate service. The Validate servicethen queries the DNS to locate an XKMS service providing information on keysbound to addresses in the zone example.com. The Validate service does nothave an established trust relationship with the example.com XKMS service andso a Locate request is made to determine if any key information bound tobob@example.com can be located. The Validate service then validates theinformation received by such means as are appropriate (e.g., by verifying thata certification chain may be constructed from a root of trust) and theresponse returned to the email client.

[165]

[166]Figure 5: Combineduse of Locate and Validate service

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

5Key Information Service MessageSet

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

5.1Key BindingSpecification

[169]Akey binding asserts a binding betweendata 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 Servicerepresentsto the client accessing the service and to that clientalone that the binding between the data elements isvalid underwhatever trust policy the service offers to that client.

[170]XKMS specifies four elements that specify keybindings, all of which are derived from theKeyBindingAbstractType. 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 anunderlying PKI such as PKIX or PGP. This specification does not define howXKMS operations interact with the underlying PKI. The XKMS key binding MAY bebound to a data object such as a certificate or key signing in theunderlying PKI such that XKMS operations on the key binding result in acorresponding change to the data structures in the underlying PKI and viceversa. If for example the XKMS service provides a mapping to an underlyingPKIX/X.509 PKI the registration of a key binding would typically result inthe issue of a certificate, even if the client does not ask for thecertificate to be returned in the registration result. If the key bindingwere subsequently revoked the corresponding certificate in the underlying PKIwould typically be revoked also.

5.1.1 AbstractTypeKeyBindingAbstractType

[172]TheKeyBindingAbstractType is the abstract type from which allXKMS key binding element specifiers are derived. It contains the followingelements 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]TheId identifier is defined to provide ameans by which the key binding may be signed using XML Signature. ClientsMUST NOT rely on the key binding identifier being either unique or stable. Inthe case that an XKMS service is providing an interface to an underlying PKI,clients MUST NOT rely on the service choosing key binding identifiers thatare either the same as or bear a systematic relationship to the serialnumbers or other identifiers of the corresponding credentials in theunderlying PKI.

[174]The following schema defines theKeyBindingAbstractType 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.2Element<KeyUsage>

[175]The<KeyUsage>element specifies one or more intended uses of the key. If no<KeyUsage> is specified all uses are permitted. Thefollowing 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 aKeyBinding that the cryptographic algorithm associatedwith the key does not support the element MUST be ignored. If a key usage isspecified in aQueryKeyBinding however the keyusage forms part of the criteria the service should attempt to match.

[177]For example if a KeyBinding specifies the keyusageEncryption for a Digital Signature Algorithmkey the relying application should ignore the key usage element. If however aclient makes a request that contains aQueryKeyBinding that specifies the key usage encryptionthe service should not return a Digital Signature Algorithm key.

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

   <!-- 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.3Element<UseKeyWith>

[179]The <UseKeyWith> element specifies a subject identifierand application identifier that determine a use of the key. Theinterpretation of<UseKeyWith> depends on theenclosing construct.

QueryKeyBinding / PrototypeKeyBinding

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<UseKeyWith> element 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 particularX.509 an application identifier is not guaranteed to be globally unique. Insuch circumstances the XKMS service is responsible for specifying rules tounambiguously interpret identifiers.

[182]The following table lists application URIs forcommon application protocols and the corresponding format for the identifierinformation:

[183] The XKMS application URI is used to specify akey binding that is used to secure an XKMS service. An XKMS service SHOULDsupport discovery of the supported security profiles and corresponding keybindings by means of aLocate operation thatspecifies the XKMS application URI and the URL of the service role. Note thatas with any other Locate operation the credentials returned by this mechanismSHOULD only be considered trustworthy if validated according to the trustpolicy of the client.

[184] The primary use intended for<UseKeyWith> identifiers is to identify applicationprotocols.<UseKeyWith> URI identifiers MAY bespecified that represent key binding issuance and/or use policies instead ofor in addition to an application protocol. In this case the<UseKeyWith> element specifies that the key bindingcomplies 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 referralmodel in which raw key binding information is obtained from a Locate servicethen forwarded to a validate service the<UseKeyWith> elements in the query should in bothcases 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 formattingfor the specified types of identifier:

[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.4Element<UnverifiedKeyBinding>

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

[189]The<UnverifiedKeyBinding> element extends theKeyBindingAbstractType with the following additionalelements:

<ValidityInterval>   [Optional]

The time interval for which the key binding relationship is requested to be asserted.

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

   <!-- 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.5Element<ValidityInterval>

[191]The<ValidityInterval> element specifies limits on thevalidity 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 thedate.

[193]TheNotBefore andNotOnOrAfter attributes are optional. If theNotBefore attribute is omitted the key binding is valid onany date up to but excluding the date specified in theNotOnOrAfter attribute . If theNotOnOrAfter attribute is omitted the key binding is validfrom theNotBefore attribute with no expiry. If both attributes are omitted the key binding isvalid at any time.

[194]In accordance with the XML SchemaSpecifications, all time instances are interpreted in Universal CoordinatedTime unless they explicitly indicate a time zone.

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

[196]For purposes of comparison, the time intervalNotBefore toNotOnOrAfterbegins at the earliest time instant compatible with the specification ofNotBefore andhas ended at theearliest time instant compatible with the specification ofNotOnOrAfter

[197]For example if the time interval specified isdayT12:03:02 todayT12:05:12 the times12:03:02.00 and12:05:11.9999 arewithin the time interval. The time12:05:12.0000 isoutside 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.6Element<KeyBinding>

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

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

<Status>   [Required]

The status of the key binding instance.

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

   <!-- 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.7Element<Status>

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

[203]The status value MAY be supplemented withcodes that state the status of specific aspects of the key binding statusthat 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 typeKeyBindingEnum is used toindicate 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 reasoncodes specified as follows:

• If an<InvalidReason> code is present theStatusValue attibute MUST have the valueInvalid.
• If an<IndeterminateReason> code is present theStatusValue attibute MUST have the either the valueIndeterminate or the valueInvalid.
• If neither an<InvalidReason> nor an<IndeterminateReason> code is present theStatusValue attibute MAY have any defined value, i.e.Valid,Indeterminate orInvalid.

[206a]Notethat the X-KRSS {Revoke,Reissue,Recover}KeyBinding elements are all of typeKeyBindingType, which requires aStatus element (c.f.Section 7). In the case ofReissue,Revoke, andRecover requests, servers MAY ignore theIndeterminate<Status>status value and Clients MAY setIndeterminateas status value.

[207]The following schema defines the<Status> element andStatusType andAssertionTypetypes:

   <!-- 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:KeyBindingEnum" use="required"/>   </complexType>      <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.8Elements<ValidReason>,<InvalidReason> and<IndeterminateReason>

[208]The<ValidReason>,<InvalidReason> and<IndeterminateReason> elements are used to specify aanyURI type that specifiesa reason for a particular key binding status.

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

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

   <!-- 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.9Element<QueryKeyBinding>

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

[212]A key binding matches theQueryKeyBinding if:

• The key binding contains all the<UseKeyWith> elements contained in the query,and
• The key binding contains all the<KeyInfo> elements contained in the query.

[213]The<QueryKeyBinding> element extends theKeyBindingAbstractType with the following additionalelements:

<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. A Service that does not support theTimeInstant element MUST return aReceiver.TimeInstantNotSupported result. Additionally, a Service that does support theTimeInstant element may be unable or unwilling to respond to requests indicating a time instant that is outside a certain range. In such cases, the service MUST return aSender.TimeInstantOutOfRange result.

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

   <!-- 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.10Element<TimeInstant>

[215]The<TimeInstant> element specifies a specific instant intime for which a key binding query is made. The<TimeInstant> element contains the followingattribute:

Time   [Required]

Time instant to which a<QueryKeyBinding> relates.

[216]All dateTime values MUST fully specify thedate.

[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.2Locate Service

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

5.2.1 Locate RequestElement<LocateRequest>

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

<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.2 Locate ResponseElement<LocateResult>

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

<UnverifiedKeyBinding>   [Any Number]

A sequence of<UnverifiedKeyBinding> key binding that match the key binding query specified in the corresponding request. If no results are found the sequence is empty and the result codeNoMatch is returned. In some circumstances aLocate 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.3Validate Service

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

5.3.1 Validate RequestElement<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.2 Validate ResponseElement<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 result codeNoMatch is returned. In some circumstances aValidate operation MAY return multiple matching results.

[227]The following schema defines the<ValidateResult> element and theValidateResultType 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 -->

6KeyRegistration Service Description

[228]The XML Key Registration Service Specificationpermits management of information that is bound to a public key pair. TheX-KRSS 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 theseservices.

[230]TheRegister operationdoes not in itself place any requirement on the registration service tocommunicate that information to any other party. In most applications,however, a registration service will provide key information to other WebServices such as those described in the XKMS specification or a separateunderlying PKI such as PKIX.

[231]TheRegister operationMAY be used in a mode where client requests are accepted by an intermediarysuch as a Local Registration Authority (LRA) and forwarded to a MasterRegistration Authority (MRA). This mode of operation is entirely transparentto the client which acts as if the LRA is the only registration authorityinvolved. The construction of the proof-of-possession of the private key andthe authentication information is completely separate of the messageauthentication signature. This allows verification by both the LRA and anyother registration authority that it is relayed to, even if the messageauthentication signature has been replaced by the LRA.

6.1Registration

[232]TheRegister requestis used to assert a binding of information to a public key pair. Generationof the public key pair MAY be performed by either the client or theRegistration service.

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

[234]The prototype of the requested key binding maycontain only partial information, a key without a name or a name without akey. In this case, the client is requesting that the registration serviceprovide the additional information required to complete the binding. Allinformation contained in the prototype of the requested key binding isadvisory to the service and MAY be ignored or overridden at the option of theservice.

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

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

[237]

[238]Figure 5:Registration of a Key Binding

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

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

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

6.1.1Example: Registration ofClient-Generated Key Pair

[242]Alice requests registration of an RSA key pairfor her email addressAlice@example.com. Alice haspreviously received from the XKMS service the code "024837" with which toauthenticate her request. Alice selects the pass phrase "Help I have revealedmy key" to authenticate herself should it be necessary to revoke theregistration at a later date.

[243]The X-KRSS request message contains thefollowing<RegisterRequest> element. Becausethe registration request is for a client generated key the Authenticationelement contains both a<ProofOfPossession>element which demonstrates that the request is authorized by the holder ofthe private key and a<KeyBindingAuthentication> element whichdemonstrates that the request was made by a person who knows theauthentication 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#"     Service="http://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>    <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 andreturns 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#"           Service="http://www.example.org/XKMS"      ResultMajor="http://www.w3.org/2002/03/xkms#Success"      RequestId="I1494ac4351b7de5c174d455b7000e18f"      xmlns="http://www.w3.org/2002/03/xkms#">  <KeyBinding>    <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.2Example: Registration ofService-Generated Key Pair

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

[248]Bob requests a server generated key pair afterreceiving the authentication code3N9CJ-K4JKS-04JWF-0934J-SR09JW-IK4 through someout-of-band mechanism.  The request specifies onlyEncryption andExchange key uses asthe key is to be escrowed for possible later recovery and the security policyof the issuer does not allow escrow of signature keys. 

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

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

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

[252]The response includes both the public key dataand 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#"             Service="http://www.example.org/XKMS"      ResultMajor="http://www.w3.org/2002/03/xkms#Success"      RequestId="I4e442fc461a83f320d7a3afb4f2454a9"       xmlns="http://www.w3.org/2002/03/xkms#">  <KeyBinding>    <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>          Em6xEIvjjlqqeEVOdf9Fq2E6ycz5OZrUU3jw7fBMhiM8BciSC3qry7GAlvRFp/D          iD5zZduSaDriD27HGOuWo1fLihgOcw5sw+G9nyhfxKo7IZ2DEss0DD5H3AAZnTW          reTYwposEBiBcuea4nYwzVWYFsIcplPYsHnXg1cq7MtMfaSu1WA4P/tQLhM1mdO          V6FHkEHdyL4FBaZbjfmkB1Z++Yb0OlOUTNCQLcNxDkF6lNM75sprB+2FtwG1u9x          ZnFXwP0Yt5euwCKeBRFm8Sfsf67CTIjKQ0+l9b66l/W1VszBgq2hMgSi8w+qILw          mFP7p4AhJJNaYlOXHbJAQL6dOe4jtyEkjhEfXXJAO8497Dat9JU5l4Aeb8Mw5BA          KDBT8RKnQTHqRTQZ8h5FPTapD1Av3KllxrIwRJG155enFrVwlxm6mLD+z4WeAdn          U5l9gUSaS13E0PlBApi98zDjILihycV1m90SzUNRIuSnw/8tV0ykS3uquDSmNAO          5YX7UZtieFMyQ2U8XBNRYYftLaN6RfPCejtxXZxIsGtvxyzzL+Yf3bl595J+IOt          n3M73bBvkdq3ACgOG0SCaETlTE5i60Trw19um+f7gAD4QKXawKw72gyQ70GccML          Dh4mypfstCbXxCG5nntGAPkCqT/c+t0TdPc7VrtyFLB3ta9z9yiRkeKqvkVZpvb          lQwykzDd3fgn9ds1liuy8RagrVO6Zczii9b7AQmQ9dekw+QDVkeS53xNTbByau/          aYAjOjIu4Xb6QNPOrNfHYOLMwGuf19o5nAjZEadZU83QhJq/ofwv3EL7tVMlOpF          K7n6Apk7cwmS4OtU71cbAVBMcAsh3KbfrHm0TCy67DEZLtdE9ksTekZMpDKXayQ          uRI0nyKugmwOVvI6oxyMt9JHRiSJRfyYF6yQoyGHGyX8nLX5imG8WNxHBur7j9h          rt8Nf9XRvXY2N9RRfpoDTexN/KZJIZJhDFsY5gsjs1xy0kZqushvZ+jeElGylXs          U/CSXwu3fgeM4qTnMKvJvHl9K4KlDtjIyYIRlBt22n238ADjMLFgUWS4+lyoWZ+          EJPzo0y9CIqb2uUNqp5cSAnb0v7s7gsq6yTqaB9fFSrV0oLH/I65Xoa7XW4mY06          xgwshdC/HHCaTyP/OEgq5Iv2VZUlWTGp1KuEmfko6MaRB/JqMhjNupi1esYTpre          JsBexGjBiCpPPieykC8ngC8GEWLRUyWPdDCybiM/CRFdCvgD5n/Js7nkNY0JGLf          BY0cGnkrxv7e5+5S1Be33yWonJSs8QQ6+y4/V5vPe+5tH8++VFm6dZXtL/oOU0S          DyHruc0yGmdu9GCibRcaU49rPLWbwSfg/g7mVibah2YBXkDDolW1U6pOpry9fHM          kEODQrnoIvGZLaOZ8UQ7jnI92WOTySdxylFL2ZvEHadlUKKN2KtW4zs7nhcQ6Tf          6gjYLNXX9ztkNgCKCZRzI4TXOM2khtPhxTv83rfV0hlx1mtRjlifDdbiWInrCW7          7IPgMEIkEa1oXoKcYb1pUw+W9xzeTp4hTx16izBqC9aWNSYJrT1AvX/Xa+oY8F4          p+YGGgOSvn9Cb2h1Va8YTb3ntqWaFSE+0/YyOHYgCIsaeYXV9YFN8A+fw                  </xenc:CipherValue>      </xenc:CipherData>    </xenc:EncryptedData>  </PrivateKey></RegisterResult>

6.2Reissue

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

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

6.2.1Example: Reissue

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

[256]The X-KRSS request message contains thefollowing<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#"           Service="http://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>    <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+qKDqmIh2KyvFyBut6FredSXjt3iDIXUKMmjA2/VPGEX8yyd71DbRqf9dXb2FzkvkKrCbYumlavbrChpEwiMUqk2rd5tjkFAZjYRAtuURoFfmoOYY/M+mNUU=      </SignatureValue>    </Signature>  </ProofOfPossession></ReissueRequest>

[257]The service accepts the registration andreturns 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#"           Service="http://www.example.org/XKMS"      ResultMajor="http://www.w3.org/2002/03/xkms#Success"      RequestId="I3a682dfb94cc8e9b3b648026783a8094"      xmlns="http://www.w3.org/2002/03/xkms#">  <KeyBinding>    <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.3Revocation

[258]A Registration service MAY permit clients torevoke previously issued key bindings. A revocation request need only containsufficient information to identify the key binding to be revoked and theauthority for the revocation request.

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

6.3.1Example: Revocation

[260]For some reason Alice requests theregistration service revoke the binding for her public key. Aliceauthenticates herself using the pass phrase value established duringregistration.

[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#"           Service="http://www.example.org/XKMS"      xmlns="http://www.w3.org/2002/03/xkms#">  <RevokeKeyBinding>    <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 hasbeen 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#"           Service="http://www.example.org/XKMS"      ResultMajor="http://www.w3.org/2002/03/xkms#Success"      RequestId="I2aa2c2f37195c9c4364c55f15df68091"      xmlns="http://www.w3.org/2002/03/xkms#" />

6.4Key Recovery

[263]A Registration service MAY support keyrecovery. For key recovery to be possible the private key to be recoveredMUST have been previously escrowed with the recovery service, for example bymeans of the X-KRSS registration of a server generated key. A key recoveryrequest is similar to the initial registration of a key except that since theregistration service might not have a record of the key binding to berecovered the result codeNotFound MAY bereturned.

[264]The key recovery service is likely to requiretime to respond to the recovery request. Clients supporting key recoverySHOULD support asynchronous processing.

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

6.4.1Example: KeyRecovery

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

[267]The request parameters for the key recoveryare:

<?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#"             Service="http://www.example.org/XKMS"       xmlns="http://www.w3.org/2002/03/xkms#">  <RespondWith>http://www.w3.org/2002/03/xkms#PrivateKey</RespondWith>  <RecoverKeyBinding>    <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>TtHM/i5L6ynzQHh2Xym8wnbjQ+w=</SignatureValue>      </Signature>    </KeyBindingAuthentication>  </Authentication></RecoverRequest>

[268]The policy of this particular registrationservice is to revoke a private key whenever key recovery is performed. Aregistration service might adopt a revoke on recover policy for a number ofreasons which include concern that the recovery process might be consideredto have compromised the key in some way.  The service returns therevoked 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#"             Service="http://www.example.org/XKMS"      ResultMajor="http://www.w3.org/2002/03/xkms#Success"      RequestId="I66f40510c322d281602ce76b9eb04d7d"       xmlns="http://www.w3.org/2002/03/xkms#">  <KeyBinding>    <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 Type="http://www.w3.org/2001/04/xmlenc#Content"                     MimeType="text/xml">      <xenc:EncryptionMethod             Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />      <xenc:CipherData>        <xenc:CipherValue>          DDSIEvW/tshnuCwCC+jX6y/srzMpt3qCIQ5zXmk/cHN4o/BItHsi9BJF85a3hnN          C4/aFfPVJ3WgP6vIZNAUaDY2FbAJckWRgWhGku36p7DZTB14vmt5P5C1bXGU5ps          CDw5Sbm+s/cFkReyfGk6khJTpbgQABPGIZBy2hiZMdSnu0eRgaVUXk9X5oPAhYU          BjiQRq56ckHgEhkuwa+RiA+ybDNn/Ttjt5Uu5BjCONkOdeE8eJMlu0ykj99Vn7G          NKUvt86bJsuwu5ZD1vSmVEwUAvHKV09UfVWfcKEINoj30t8Imj9naJ37oVRNPXl          EKqZY9cxqzHiYEEhu0wxiTMiLbkEyh1DIcLNW78JXpWHRuRTrU5hgNzGEO1pKo7          1uRT1/lArojeJGCJKAwQJvCDXU9zZSXVLzU/AqUshR3L0AoY8pJ/p+LbmlTh43E          4TeT0iXNWkLz0mdgWdmwhhZtj8NcP/4auqfpv7+4NAP5OFVOEYJgE1I60F49K9m          7FbNygiAczfN1YZwjc5lLoIXo75cXduxOZgTWN8ZnFKwrhG1IMhstrauywur6lr          lyxZ1JXEj2aohE4Msa7HKx1LSzDi3dejtK3ZFRqnJcJ1bQ/liOA1IgonN0wvUaH          DM9ibo2xUie2DfoSw3kWCDf0bcZEcV33UFNR3w8kOHgpSAwdHJi0pRyHdgfyd8w          3NzvfCNy9AlrU2MbTdFF7hBxmgFK3fvaX7aEcgdqY17dqkiK75TAwzkVh5WkVjS          WZGSiN49C8e4bY9zzq33lZwZabd5ts2Dvy3RuKc0hQj2rnCZcowXC+XJ7tVtMG+          lNu1ykyeYmvR8VI5Ame5h1DFPjoFLAjkt/tUu2uZlqLYoSKvJU4FWNMAXRUge+f          L3f35lObqwxPJN/LVJgvgGqoMt5hO+/uwgsb3nbR7rTHavPX2kS5LDAtW5xNcfF          dJz8l+dDjlYBJMN8cgEKnNtHTcnVJ5NiFPsGIFv/3IGUZsiw7M4dff3GN6quv9A          601e5rqG1ObMT6/7y7T0Z5IBXwiqs4HcdV+kyRfJwX1QpGat3nQsOZ59PTsIt5n          oKSH0sB5AZmLJa1zgeOILJ574r+F6kD44R32NoLjqu0QL5IqfQ/0lQJuYhn0uEr          FeZIn/lvjqzgf+rGPtgI5wtZ9Fv3qKrTPJOGM8atkzPkUtyJ8kR+WRhdAdFH9HM          0PgyrSGjcCGgFIppsN1KJawrvcXokGRzF81cD/3pVaZC/ZIBtvp4DXM2JSLGoa1          GpLuaIFUP5T/uxFf6MpW2v07bB/jqEZrcsB/ofmvv6RXD/gXrrw99iIiv0k2lyR          sHDN5/syXglGGeskPvCUOZZ5oXrZruxER/IXKRnlsD+0wJ3JZCSuPy9wYmQk77F          pynJ5//7w8UA2qWvkZ0B4rKXOgZYp2pCWaZIDknHJoY+VL7J3sQyAp7qlkQxSBj          bhTEjSYXpHWA+Vj/TiH1ue7/ULlCKfDNvDaWFuEqGT/9H+xUJ5POfTDBhUh+Row          rwCcfYe71B+pB/tylQEERKNpqqgu3TbNJZk5G8U9p41+PwJ0kw9EZnv+z8UEyFl          qAZZxj64rTelurPUsiehBFwVwh2fATuMrW9fhGew11npVlF5k+WxE1Cz+                  </xenc:CipherValue>      </xenc:CipherData>    </xenc:EncryptedData>  </PrivateKey></RecoverResult>

[269]The decrypted private key parameters are:

<?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.5RequestAuthentication

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

[271]An X-KRSS Service SHOULD ensure that allrequests 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 ownauthentication policy. This specification defines an authentication mechanismthat employs a shared secret established out of band between the client andthe registration service.

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

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

[277a]Clients and Responders MAYusedsig:KeyName for HMAC validation.Alternatively, they may use other Identity relatedinformation derived from security binding, such as the Sender's IPaddress.

7Key Registration Service MessageSet

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

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

7.1Common Elements

7.1.1Element<PrototypeKeyBinding>

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

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

[282]The<PrototypeKeyBinding> element extends theKeyBindingAbstractType with the following additionalelements:

<ValidityInterval>   [Optional]

The suggested time interval for which the key binding relationship is valid.

<RevocationCodeIdentifier>   [Optional]

Specifies a value to be used to validate aRevocationCode value in a subsequent Revocation request.

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

   <!-- 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.2Element<RevocationCodeIdentifier>

[284]The<RevocationCodeIdentifier> element contains a MACoutput 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 theservice accepts such algorithms by means of an out of band mechanism such asa Web Service description or policy mechanism.

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

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

[288]An advantage of employing the double MACcalculation is that it ensures that an XKMS service does not place arbitraryconstraints on the length of or character set in which the pass phraseis encoded.

[289]Details of the MAC output value calculationare provided in the sectionCryptographic AlgorithmSpecific Parameters below.

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

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

7.1.3Element<Authentication>

[291]The <Authentication> element is used to authenticate thekey binding element within an X-KRSS request. This may be a  <PrototypeKeyBinding>,<ReissueKeyBinding>,<RevokeKeyBinding> or<RecoverKeyBinding> element depending on the type ofrequest.

<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 X-KRSS request that is not bound to the key binding.

XKMS Responders do not have to support both of these optional elements in a request message.

[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.4Element<KeyBindingAuthentication>

[293]The<KeyBindingAuthentication> element contains an XMLSignature[XML-SIG] element that is used toauthenticate 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 theId attribute specified inKeyBindingAbstractType tospecify 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.5Element<NotBoundAuthentication>

[296]The<NotBoundAuthentication> contains plaintext authentication data (e.g., limited use sharedsecret) that is used to authenticate the request.

Protocol    [Required]

A URI specifying the authentication protocol used.

Value   [Required]

The plaintext authentication data encoded in base64 format.

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

[298]This element is provided to supportapplications in which the authentication scheme requires the server to haveplaintext access to the authentication data. The authentication data is notsecurely bound to the request and thus the element MUST NOT be employedexcept in circumstances where the message or transport protocol providesadequate 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.6Element<ProofOfPossession>

[300]The<ProofOfPossession> element contains a XML Signature[XML-SIG] element. The signature scope is the<PrototypeKeyBinding> using the public key that is tobe registered. The private key component of the public key contained withinthe<PrototypeKeyBinding> is used to generatethe 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 theds:KeyInfo element within the<PrototypeKeyBinding> element.

[301]The XML signature[XML-SIG] is generated as a detached signature using theId attribute specified inKeyBindingAbstractType tospecify 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.7Element<PrivateKey>

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

<xenc:EncryptedData>   [Required]

The encrypted private key data. This element is as defined by the XML Encryption Specification[XML-Enc]. The Type attribute SHOULD be present and, if present, MUST contain a value ofhttp://www.w3.org/2001/04/xmlenc#Content. The MimeType attribute, SHOULD be "text/xml".

[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.8Element<RevocationCode>

[305] The<RevocationCode> element contains a MAC output valueencoded 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 theservice accepts such algorithms by means of an out of band mechanism such asa Web Service description or policy mechanism.

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

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

[309]Details of the MAC output value calculation are provided in the sectionCryptographic Algorithm Specific Parametersbelow.

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

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

7.2Register

7.2.1 Register RequestElement<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. A Service that requires theProofOfPossession element MUST return aSender.ProofOfPossessionRequired result if theProofOfPossession element is not present in the request.

[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.2 Register ResponseElement<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.3Reissue

7.3.1 Reissue RequestElement<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. A Service that requires theProofOfPossessionelement MUST return aSender.ProofOfPossessionRequired result if theProofOfPossession element is not present in the request.

[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.2 Reissue ResponseElement<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.4Revoke

7.4.1 Revoke RequestElement<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.2 Revoke ResponseElement<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.5Recover

7.5.1 Recover RequestElement<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.2 Recover ResponseElement<RecoverResult>

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

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

8Cryptographic AlgorithmSpecific Parameters

8.1Use of Limited-Use Shared SecretData

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

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

[329a] The symmetric key data MAY be binary data(as from an authentication device) or as a human-readable value (numeric,alphabetic, or both). When it is binary data, no transformation is needed;the data can be used directly as input to the MAC function.

[329b] When the symmetric key data ishuman-readable, it may be issued to a human user in the form of a text stringwhich may in some circumstances be read over a telephone line. It may berandomly generated and represent an underlying numeric value, or may be apassword or phrase. In either case, it is often convenient to present thevalue to the human user as a string of characters in a character set theparticular user understands. To limit the possibility of human error inprocessing the symmetric key data, and to provide a canonical binaryrepresentation, the string text must be compliant to the SASLprep stringprepprofile for user names and passwords,[SASLPREP].

[329c] The algorithm for canonicalizing astring-text before feeding it to the MAC function is the following:

1. Convert the input string to an Unicode encoding.
   Removes the US-ASCII and ISO-LATIN-1 limitations! Let's a user type a password phrase that s/he can remember with ease or that's easy to type with his/her keyboard configuration.
2. Verify that the input string is compliant to the SASLprep stringprep profile for user names and passwords[SASLPREP]. Refuse the string otherwise.
   This operation consists of mapping and normalizing the characters in the string, and checking that it doesn't have any forbidden characters. In particular, there's no folding of multiple spaces or of case. Punctuation symbols are not removed either. Tabs are control characters and thus are considered to be forbidden.
3. Encode the result into UTF-8.
4. Apply the MAC functions.

[330]Applications MUST ensure that the limited useshared secret data contains sufficient entropy to prevent dictionary attacks.For more details see the  more detailed comment in thesecurity considerations section of thisdocument.

[331]Keying material is derived from the sharedstring 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 theservice accepts such algorithms by means of an out of band mechanism such asa Web Service description or policy mechanism.

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

[334]If the output of the MAC function providesmore 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 providesless keying material than is required additional keying material is obtainedas follows:

[336]block₀ = MAC (converted, key)

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

[338]output = block₀ + block₁ ...  block_n

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

8.2Private KeyParameters

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

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

8.2.1Element<RSAKeyPair>

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

<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="RSAKeyPair" type="xkms:RSAKeyPairType"/>   <complexType name="RSAKeyPairType">      <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 -->

9Conformance

[344]The section describes features and operationsthat XKMS applications whose support is either required or recommended toensure interoperability of XKMS services.

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

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

• [347]If support for a feature is specified as REQUIRED a conforming XKMS implementation MUST support the use of that feature in a message sent by another XKMS implementation.

• [348]If support for a feature is specified as RECOMMENDED a conforming XKMS implementation SHOULD support the use of that feature if used by another XKMS implementation.

• [349]If support for a feature is specified as OPTIONAL, XKMS implementations SHOULD NOT send messages requiring support for that feature.

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

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

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

[352a] When a client request includes anOPTIONAL element that is not supported by the Server, the server mayuseResultMajor=Receiver andResultMinor=OptionalElementNotSupported code. In some cases, depending on the context, the server may usetheFailure orMessageNotSupportedResultMinorcodes. In any of these cases, the client should check the server's supportedfeatures, for example by reading a WSDL[WSDL] or metadata file. The resourcediscovery mechanism is out of scope for this specification.

[353]Implementers should note that theserequirements may change in future versions of the XKMS specification. Forexample it is likely that future versions of the XKMS specification will makethe then current version of the SOAP specification a requirement.

10SecurityConsiderations

[355]Implementations SHOULD consider the followingsecurity issues.

10.1Replay Attacks

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

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

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

• A message origination time that the recipient verifies by checking that it is sufficiently recent.
• A nonce, that is a piece of random data that was previously issued by the user.
• A message serial number.

10.2Denial of Service

[359]XKMS Services SHOULD take measures to preventor mitigate denial of service attacks. In particular XKMS Services SHOULD NOTperform an unlimited number of resource intensive operations unless therequest comes from an authenticated source. Potentially resource intensiveoperations include:

• CPU intensive cryptographic operations, including signature verification and key exchange.
• Resolution of URLs.

10.3Recovery Policy

[360]Key recovery policy is left as animplementation decision.

[361]Depending on the implementation andapplication, a key recovery operation might involve an unacceptable loss ofconfidence in the security of a private key component. This may lead to thepossibility of repudiation of a signed document or of accountability in thecase of an encrypted document.

[362]Services SHOULD carefully assess the extent towhich a recovery operation compromises a private key and apply sufficientcontrols such as the revocation of the underlying key binding asappropriate.

10.4Security of Limited UseShared Secret

[363]If a limited use shared secret is used caremust be taken to ensure that the secret has sufficient entropy that theprobability of guessing by an attacker is tolerably low. Particular care mustbe taken if a limited use shared secret is used to encrypt a servicegenerated private key since the transported private key might be subject to adictionary attack. Implementations should not re-use revocation codesacross different key bindings (regardless of the amount of entropy used whengenerating them). Note that strong confidentiality protection ofRevocationCodeIdentifier and RevocationCode elements would also help againstthis problem. Applications SHOULD enforce the following minimum entropyvalues 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 (which MAY include strong confidentiality protections for revocation code identifiers and revocation codes, providing safeguards against the dictionary attacks, and to protect against attackers recognizing deliberate or accidental collisions of revocation codes) 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.5Confidentiality of Opaque ClientData

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

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

10.6Security of Not BoundAuthentication Data

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

[367]This MAY be a message level or transport levelprotocol that protectsboth encryptionand integrity such asTLS [RFC-2246].

10.7Signature Oracle

[368]XKMS services that provide signed responsesSHOULD ensure that the requestor cannot solicit a predicted response, thusproviding a signing oracle. Such a signing oracle might provide a directcompromise for the key under a different protocol or allow a weakness in thesignature or digest algorithm employed to be exploited.

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

10.8Privacy

[370]An XKMS service MAY solicit data which issubject to privacy concerns. In certain circumstances management of such dataMAY be subject to government regulation, corporate policies or contractualobligations. Deployments SHOULD consider whether the information they collectis subject to such concerns and if necessary deploy a privacy notificationmechanism such as P3P[P3P].

10.9Security of thePrivate Key

[371]Implementations MUST ensure that in caseswhere a private key is generated by the service, the information used toencrypt the private key data is adequately protected. In particular if anauthentication pass phrase exchanged out of band is used to encrypt theprivate key the implementation MUST ensure that the out of band communicationmechanism adequately protects the confidentiality of the pass phrase.

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

[372a]Implementations supporting encryption ofPrivate Key Data MUST support Shared Secret. Use of Shared Secret is detailedin section 8.1.

10.10Message Length DisclosureVulnerabilities

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

10.11Check for Signature Value in aSigned SOAP Message

[373a] The Implementation of XKMS MUST check fora signature value reference in the to-be-signed data when using a Signed SOAPmessage. Also, implementations MUST ensure that all the bytes in the XKMS messages,e.g., from<LocateRequest> .... </LocateRequest>, be included in hashing and in the resulting signature value of the message.

Appendix ASchemas

A.1XKMS Schema

Appendix BServiceLocation Configuration (Non-Normative)

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

B.1Domain Name Service(DNS)

[375]The provision ofan XKMS service that provides information on key information bound to DNSaddresses in a specified DNS zone MAY be advertised by means of the DNS SRVrecord[RFC 2782]. An SRV record contains thefollowing 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 X-KISS 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 X-KRSS 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 zonethat advertises an XKMS service is an affirmative statement by the operatorof the zone that the XKMS service indicated MAY be queried for informationconcerning key information bound to protocol addresses within that zone. Thepublication of an SRV record does not imply any undertaking on the part ofthe part of the publisher to ensure that the information provided by the XKMSservice is accurate or trustworthy. Relying parties MUST therefore establishthe trustworthiness of any information they may receive from an XKMS servicediscovered by means of an SRV record by other means, for example byforwarding the data to an XKMS Validate service.

B.1.1Examples

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

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

[381]The following SRV record advertises three XKMSX-KISS services, main1, main2 and backup. Clients should direct requests tomain1 and main2 with equal priority. The service backup should only beaccessed if neither main1 or main2 is available:

[382]_XKMS_XKISS_SOAP_HTTP._TCP.example.com - IN 0 50 80main1.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 80backup.example.com

Appendix CSample ProtocolExchanges (Non-Normative)

[383]For clarity the examples in the running textomit certain details such as the message authentication signatures and SOAPbinding information. This section provides these messages in fullto facilitate interoperability testing.

C.1Authentication Computation

[384]The calculation of the authentication valuesused in the examples.

C.1.1Alice Registration AuthenticationKey

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.2Bob Registration AuthenticationKey

Authentication Data

3N9CJ-JK4JK-S04JF-W0934-JSR09-JWIK4

Converted Authentication Data

[33][4e][39][43][4a][2d][4a][4b] [34][4a][4b][2d][53][30][34][4a] [46][2d][57][30][39][33][34][2d] [4a][53][52][30][39][2d][4a][57] [49][4b][34]

Key = HMAC-SHA1 (Converted Authentication Data, 0x1)

[3f][9a][5d][33][62][96][78][87] [eb][ce][55][37][b7][40][13][e8] [cd][40][b0][3f]

C.1.3Bob Registration Private KeyEncryption

Authentication Data

3N9CJ-K4JKS-04JWF-0934J-SR09JW-IK4

Converted Authentication Data

[33][4e][39][43][4a][2d][4b][34] [4a][4b][53][2d][30][34][4a][57] [46][2d][30][39][33][34][4a][2d] [53][52][30][39][4a][57][2d][49] [4b][34]

First Block = HMAC-SHA1 (Converted Authentication Data, 0x4)

[78][e8][bb][f5][32][d0][1d][ec] [e3][8a][a9][d2][a4][a4][09][db] [ff][1a][26][5c]

Key = First Block XOR 0x4

[7c][e8][bb][f5][32][d0][1d][ec] [e3][8a][a9][d2][a4][a4][09][db] [ff][1a][26][5c]

Second Block = HMAC-SHA1 (Converted Authentication Data, Key)

[db][ae][1b][95][7a][48][46][b7] [f3][6e][36][ef][0b][44][62][d0] [fe][8a][9a][7b]

Final Secret Key

[78][e8][bb][f5][32][d0][1d][ec] [e3][8a][a9][d2][a4][a4][09][db] [ff][1a][26][5c][db][ae][1b][95]

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

Initialization Vector

[12][6e][b1][10][8b][e3][8e][5a]

PlainText

<?xml version="1.0" encoding="utf-8"?>
<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][38][22][3f][3e][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][6d][73] ...
[69][72][3e][ba][cb][c1][59][05]

Cipher Text (with pre-pended Initialization Vector)

[12][6e][b1][10][8b][e3][8e][5a] [aa][78][45][4e][75][ff][45][ab] [61][3a][c9][cc][f9][39][9a][d4] [53][78][f0][ed][f0][4c][86][23] [3c][05][c8][92][0b][7a][ab][cb] [b1][80][96][f4][45][a7][f0][e2] [0f][9c][d9][76][e4][9a][0e][b8] [83][db][b1][c6][3a][e5][a8][d5] [f2][e2][86][03][9c][c3][9b][30] [f8][6f][67][ca][17][f1][2a][8e] [c8][67][60][c4][b2][cd][03][0f] [91][f7][00][06][67][4d][6a][de] ...
[75][7d][60][53][7c][03][e7][f0]

C.1.4Bob Recovery Private KeyEncryption

Authentication Data

A8YUT vuhhu c9h29 8y43u h9j3i 23

Converted Authentication Data

[41][38][59][55][54][20][76][75] [68][68][75][20][63][39][68][32] [39][20][38][79][34][33][75][20] [68][39][6a][33][69][20][32][33]

Secret Key

[21][02][af][d9][e4][7a][88][0b] [57][d8][80][04][4b][9e][ef][11] [77][b8][01][25][85][02][b7][4c]

C.2Pass PhraseComputation

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

C.2.1Alice PassPhrase Computation

Pass Phrase

"Help I Have Revealed My Key"

Converted Pass Phrase

[48][65][6c][70][20][49][20][48] [61][76][65][20][52][65][76][65] [61][6c][65][64][20][4d][79][20] [4b][65][79]

Pass Phrase Pass 1 HMAC-SHA1 (Converted Authentication Data, 0x2)

[1c][08][57][c9][54][58][c2][6f] [44][32][7e][fd][0e][f0][55][b0] [8c][ad][5c][78]

Pass Phrase Pass 2 = HMAC-SHA1 (Pass Phrase Pass 1 , 0x3)

[e6][b4][4d][d9][c3][99][88][c9] [5c][88][9c][41][a9][a7][a5][ad] [90][c2][cd][21]

Base 64 Encoding of Pass Phrase

5rRN2cOZiMlciJxBqaelrZDCzSE=

C.2.2Bob Pass PhraseComputation

Pass Phrase

"Have A Banana"

Converted Pass Phrase

[48][61][76][65][20][41][20][42] [61][6e][61][6e][61]

Pass Phrase Pass 1 = HMAC-SHA1 (Converted Authentication Data, 0x2)

[2b][62][13][bd][55][9d][c7][99] [f1][4e][d0][24][7c][4c][60][af] [42][0b][b1][76]

Base 64 Encoding of Pass Phrase Stage 1

K2ITvVWdx5nxTtAkfExgr0ILsXY=

Pass Phrase Pass 2 = HMAC-SHA1 (Pass Phrase Pass 1, 0x3)

[5b][57][bf][7b][13][63][65][23] [e9][52][e3][62][2e][35][95][e5] [6b][a0][30][cc]

Base 64 Encoding of Pass Phrase Stage 2

W1e/exNjZSPpUuNiLjWV5WugMMw=

C.3 PrivateKey Parameters

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

C.3.1Alice PrivateKey Parameters

<?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.2Bob Private KeyParameters

<?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.3XKMS Service Private KeyParameters

<?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 DReferences (Non-Normative)

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

[389][P3P] L. Cranor, M. Langheinrich, M.Marchiori, M. Presler-Marshall, J. Reagle, The Platform forPrivacy Preferences 1.0 (P3P1.0) Specification, W3C Recommendation 16April 2002,http://www.w3.org/TR/2002/REC-P3P-20020416/.

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

[391][PKCS1]B. Kaliski,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 RFCsto 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] H. Krawczyk,, M. Bellare, andR. 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 RFC2246 January 1999.http://www.ietf.org/rfc/rfc2246.txt.

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

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

[397b][SASLPREP] K. D. Zeilenga,SASLprep: Stringprep profile for user names and passwords, IETF RFC 4013, February 2005,http://www.ietf.org/rfc/rfc4013.txt.

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

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

[400][WSDL] R. Chinnici, M. Gudgin, J.-J. Moreau, J. Schlimmer, S. Weerawarana,Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, W3C Working Draft, 3 August, 2004, latest draft at http://www.w3.org/TR/wsdl20.

[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 (SecondEdition). 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, W3CRecommendation, 12 February 2002.http://www.w3.org/TR/xmldsig-core/.

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

[405][XML-Enc] D. Eastlake, J. Reagle, T.Imamura, B. Dillaway, E. Simon,XML Encryption Syntax andProcessing, 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 Second EditionW3C Recommendation 28 October 2004.2001.http://www.w3.org/TR/xmlschema-1/.

[408][XML-Schema2] P. V. Biron, A. Malhotra,XMLSchema Part 2: Datatypes Second Edition; W3C Recommendation 28 October 2004.http://www.w3.org/TR/xmlschema-2/.

[409][XAdES]J.C. Cruellas, G. Karlinger, K. SankarXML Advanced ElectronicSignatures, W3C Note 20 February 2003.http://www.w3.org/TR/XAdES/.

Appendix EAcknowledgments (Non-Normative)

[410]This specification is the work of the W3C XML Key ManagementWorking Group. The contributions of the following Working Groupmembers to this specification are gratefully acknowledged inaccordance with thecontributor policies and the activeWGroster.

[411]Participants in the Working Group are (at the time of writing, and by alphabetical order): Guillermo Alvaro Rey (Trinity College Dublin), Stephen Farrell (Trinity College Dublin, Co-Chair), José Kahan (W3C, staff contact), Berin Lautenbach (Apache Software Foundation), Tommy Lindberg (Markup Security), Roland Lockhart (Entrust, Inc.), Vamsi Motukuru (Oracle Corp.), Shivaram Mysore (Co-Chair; Editor since 13 Apr 2004), Rich Salz (DataPower Technology, Inc.), Yunhao Zhang (SQLData Systems).

[412]Previous participants were (by alphabetical order): Daniel Ash (Identrus), Blair Dillaway (Microsoft), Donald Eastlake 3rd (Motorola), Yassir Elley (Sun Microsystems), Jeremy Epstein (webMethods), Slava Galperin (Sun Microsystems), Phillip Hallam-Baker (VeriSign Inc, Editor until 13 Apr 2004),Loren Hart (VeriSign Inc.), Mack Hicks (Bank of America), Merlin Hughes (Baltimore), Frederick Hirsch (Nokia Mobile Phones), Mike Just (Treasury Board of Canada Secretariat),Brian LaMacchia (Microsoft), Pradeep Lamsal,Joseph Reagle (W3C, previous staff contact), Dave Remy (GeoTrust, Inc.), Peter Rostin (RSA Security Inc.), Ed Simon (XMLsec Inc.)

[413]The authors also acknowledge the extensive assistance provided inthe design stage of this specification by David Solo (CitiGroup) andBarbara Fox (Microsoft), and the contributions of (by alphabeticalorder) Dr. Paul Boisen (NSA), Alex Deacon, Dan Guinan, Marc Hayes,Jeremy Epstein (webMethods), Andrew Layman (Microsoft), Mingliang Pei(VeriSign).

[414]The people who have contributed to discussions onwww-xkms@w3.org are also gratefully acknowledged.

Appendix F Changes (Non-Normative)

This appendix documents changes (other than very minor editorial changes)from theProposed Recommendation of 2 May 2005 that were made to accommodate thecomments. Each entry contains:

• a change number
• a brief description and, where appropriate, what has been done about it
• a link to the message causing the change (if the message is public)

Changes in the XKMS Schema between PR and Recommendation

None.

Changes in the XKMS Specification between PR and Recommendation

1. Correction. Removed a definition of Web Service in Section 1.2 as it wass not used in the document and was not compatible with current usage. (337-phb)
2. Correction. The UseKeyWith with application "urn:ietf:rdf:2459" examples in pp. 246 and 252 was not properly escaped. (342-ml)
3. Correction. Made pp. 102 and 103 clearer by adding more RFC 2119 terminology, substituting the term "strings" by "URI" and specifying which XKMS elements include <RespondWith>. (344-ml)
4. Correction. p. 218 ended with: "The <UnverifiedKeyBinding> returned are specified by the Respondelement in the request.", but it should say "by the RespondWithelement in the request". (347-kj)