XML Key Management Specification (XKMS 2.0)
Part I: Schema

W3C Editors Copy 13th February 2003

This version:

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

Latest version:

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

Previous version:

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

Editor:

Phillip Hallam-Baker VeriSign

Contributors:

See the WG participants list.

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

---

Table Of Contents

XML Key Management Specification (XKMS 2.0) Part I: Schema

W3C Editors Copy 13th February 2003

Abstract

Status of this document

Table Of Contents

1 Introduction

1.1 Editorial and Conformance Conventions

1.2 Definition of Terms

1.3 Namespaces

1.4 Key Information Service Specification Overview (Non-Normative)

1.5 Key Registration Service Specification Overview (Non-Normative)

1.6 Structure of this document

2 Message Format

2.1 Request Types

2.2 Responses

2.3 Synchronous and Asynchronous Processing

2.4 Two Phase Request Protocol

2.5 Compound Requests and Responses

2.6 Security Binding

2.7 Message Syntax

3 Key Information Service Overview

3.1 XKISS Locate Service

3.2 XKISS: Validate Service

3.3 Using Locate and Validate

4 Key Information Service Message Set

4.1 Key Binding Specification

4.2 Locate Service

4.3 Validate Service

5 Key Registration Service Overview

5.1 Registration

5.2 Reissue

5.3 Revocation

5.4 Key Recovery

5.5 Request Authentication

6 Key Registration Service Message Set

6.1 Common Elements

6.2 Register

6.3 Reissue

6.4 Revoke

6.5 Recover

7 Cryptographic Algorithm Specific Parameters

7.1 Use of Limited-Use Shared Secret Data

7.2 Private Key Parameters

8 Conformance

9 Security Considerations

9.1 Replay Attacks

9.2 Denial of Service

9.3 Recovery Policy

9.4 Security of Limited Use Shared Secret

9.5 Confidentiality of Opaque Client Data

9.6 Security of Not Bound Authentication Data

9.7 Signature Oracle

9.8 Privacy

9.9 Security of the Private Key

9.10 Message Length Disclosure Vulnerabilities

10 Acknowledgments

Appendix A Schemas

A.1 XKMS Schema

Appendix B Service Location Configuration

B.1 Domain Name Service (DNS)

Appendix C Sample Protocol Exchanges

C.1 Authentication Computation

C.2 Pass Phrase Computation

C.3 Private Key Parameters

Appendix D References

1 Introduction

[9]This document specifies protocols for distributing and registering public keys, suitable for use in conjunction with the standard for XML Signatures [XML-SIG] defined by the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF) and companion standard for XML encryption [XML-ENC]. The XML Key Management Specification (XKMS) comprises two parts -- the XML Key Information Service Specification (X-KISS) and the XML Key Registration Service Specification (X-KRSS).

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

[11]This document comprises the following service specifications:

XML Key Information Service Specification:

A protocol to support the delegation by an application to a service of the processing of Key Information associated with an XML signature, XML encryption, or other usage of the XML Signature [XML-SIG]<ds:KeyInfo> element.

XML Key Registration Service Specification:

A protocol to support the registration of a key pair by a key pair holder, with the intent that the key pair subsequently be usable in conjunction with the XML Key Information Service Specification or a Public Key Infrastructure (PKI) such as [X.509][PKIX].

1.1 Editorial and Conformance Conventions

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

[13]The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in RFC2119 [KEYWORDS]:

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

[15]Consequently, we use these capitalized keywords to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. These key words are not used (capitalized) to describe XML grammar; schema definitions unambiguously describe such requirements and we wish to reserve the prominence of these terms for the natural language descriptions of protocols and features. For instance, an XML attribute might be described as being "optional." Compliance with the XML-namespace specification [XML-NS] is described as "REQUIRED."

1.2 Definition of Terms

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

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

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

[19] Client
An application that makes requests of a service. The concept of 'client' is relative to a service request; an application may have the role of client for some requests and service for others.

1.3 Namespaces

[20]For clarity, some examples of XML are not complete documents and namespace declarations may be omitted from XML fragments. In this document, certain namespace prefixes represent certain namespaces as follows

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

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

   ...

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

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

1.4 Key Information Service Specification Overview (Non-Normative)

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

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

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

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

[26]In the case of an encryption operation:

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

1.5 Key Registration Service Specification Overview (Non-Normative)

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

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

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

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

1.6 Structure of this document

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

Section 2: Message Format

Features of the XKMS that are common to the XKMS services are described

Section 3: Key Information Service Specification Overview.

The functional behavior of the X-KISS service is described.

Section 4: Key Information Service Specification Message Set.

The semantics of the X-KISS protocol messages are defined.

Section 5: Key Registration Service Specification Overview.

The functional behavior of the X-KRSS service is described.

Section 6: Key Registration Service Specification Message Set.

The semantics of the X-KRSS protocol messages is defined.

Section 7: Cryptographic Algorithm Specific Parameters

Parameters and data formats specific to the use of particular cryptographic algorithms are defined.

Section 8: Security Considerations

Security considerations for implementation and deployment of XKMS are described

2 Message Format

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

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

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

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

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

2.1 Request Types

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

X-KISS Request

A Locate or Validate request as specified by the Key Information Service Specification

X-KRSS Request

A Register, Reissue, Revoke or Recover request as specified by the Key Information Service Specification

Compound Request

A compound request consists of a set of one or more X-KISS or X-KRSS requests.

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

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

Asynchronous Processing

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

Two Phase Request Protocol

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

Compound Requests and Responses

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

2.2 Responses

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

2.3 Synchronous and Asynchronous Processing

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

• In synchronous processing the service returns the final response to the requestor using the same communication channel used to issue the request.
• Asynchronous processing is used in cases where a service cannot complete the request immediately and it is undesirable to keep the communication channel used for the request open while the request is being completed.

[42]A client MAY advise a service that it will accept asynchronous processing of a request by specifying the ResponseMechanism value xkms:Asynchronous. An XKMS service advises the client that the response value will be returned asynchronously by specifying the MajorResult code xkms:Pending.

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

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

[45]The Synchronous and Asynchronous processing of requests is described in Part II.

2.4 Two Phase Request Protocol

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

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

[48]An XKMS service MUST NOT return the MajorResult code xkms:Represent unless the ResponseMechanism value xkms:Represent was specified in the corresponding request. If an XKMS service requires the use of the Two Phase Request protocol and the ResponseMechanism value xkms:Represent is not specified in the corresponding request the MajorResult code xkms:Receiver and MinorResult code xkms:MustRepresent are returned.

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

[50]The Two Phase Request Protocol may be combined with the Asynchronous protocol in which case a single XKMS operation would require a total of three request/response message pairs to complete.

[51]The Two Phase Request Protocol is described in Part II.

2.5 Compound Requests and Responses

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

[53]The response to a compound request is a compound response. A compound response consists of an outer response and zero or more inner responses. If the ResultMajor value of the outer response is xkms:success the compound response SHOULD contain an inner response response element corresponding to each inner request element of the compound request. If the the Major.Result value of the outer response is not xkms:success the response MUST NOT contain any inner responses. If a compound request has an outer ResultMajor value xkms:success but does not contain a response corresponding to an inner request the ResultMajor value xkms:failure is assumed.

[54]A Web Service MAY support the use of the two phase protocol on the outer request of a compound response. The two phase protocol SHOULD NOT be used on an inner response. If an inner request specifies the ResponseMechanism value xkms:Represent the value SHOULD be ignored.

[55]A Web Service MAY support the use of asynchronous processing in conjunction with a compound request. Asynchronous processing MAY be performed on the compound request as a whole, on individual inner requests or both.

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

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

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

2.6 Security Binding

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

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

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

2.7 Message Syntax

2.7.1 Type MessageAbstractType

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

<ds:Signature> [Optional]

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

<MessageExtension> [Any Number]

An extension element derived from the MessageExtensionAbstractType.

<OpaqueClientData> [Optional]

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

Id [Required]

A unique identifier generated by the requestor.

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.

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

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

2.7.2 Element <ds:Signature>

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

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

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

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

2.7.3 Element <MessageExtension>

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

[67]The following schema defines the MessageExtension element:

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

2.7.4 Element <OpaqueClientData>

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

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

[70]The following schema defines the OpaqueClientData element:

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

2.7.5 Type RequestAbstractType

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

<ResponseMechanism> [Any Number]

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

<RespondWith> [Any Number]

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

<PendingNotification> [Optional]

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

OriginalRequestID [Optional]

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

ResponseLimit [Optional]

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

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

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

2.7.6 Element <ResponseMechanism>

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

[74] ResponseMechanism values are specified as QNames, the following identifiers are defined:

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

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

2.7.7 Element <RespondWith>

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

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

[78] RespondWith values are specified as QNames, the following identifiers are defined:

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

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

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

2.7.8 Element <PendingNotification>

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

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

Mechanism [Required]

A URI that specifies the protocol by which the notification is made

Identifier [Required]

A URI that specified the address to which the notification is made

[83]The following mechanisms are defined:

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

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

2.7.9 Element <PendingRequest>

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

ResponseID [Optional]

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

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

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

2.7.10 Element <ResultAbstractType>

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

<RequestSignatureValue> [Optional]

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

ResultMajor [Required]

The most significant component of the result code

ResultMinor [Optional]

The least significant component of the result code

RequestId [Optional]

The unique identifier Id specified in the request

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

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

[90]The following schema defines the ResultAbstractType abstract type:

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

2.7.10.1 Result Codes

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

[92]The following ResultMajor codes are defined:

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

[94]The following ResultMinor codes are defined:

2.7.11 Element <RequestSignatureValue>

[95]The <RequestSignatureValue> element provides a cryptographic linkage between the request and the response.

[96]A service SHOULD include the <RequestSignatureValue> element element in a response if the following conditions are satisfied and MUST NOT include the value otherwise:

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

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

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

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

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

2.7.12 Element <CompoundRequest>

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

<LocateRequest> [AnyNumber]

An XKMS Locate Request

<ValidateRequest> [AnyNumber]

An XKMS Validate Request

<RegisterRequest> [AnyNumber]

An XKMS Register Request

<ReissueRequest> [AnyNumber]

An XKMS Reissue Request

<RecoverRequest> [AnyNumber]

An XKMS Recover Request

<RevokeRequest> [AnyNumber]

An XKMS Revoke Request

[100]The following schema defines the CompoundRequest element and CompoundRequestType type:

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

2.7.13 Element <CompoundResult>

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

<LocateResult> [AnyNumber]

An XKMS Locate Result

<ValidateResult> [AnyNumber]

An XKMS Validate Result

<RegisterResult> [AnyNumber]

An XKMS Register Result

<ReissueResult> [AnyNumber]

An XKMS Reissue Result

<RecoverResult> [AnyNumber]

An XKMS Recover Result

<RevokeResult> [AnyNumber]

An XKMS Revoke Result

[102]The following schema defines the CompoundResult element and CompoundResultType type:

   <!-- CompoundResponse -->
   <element name="CompoundResult" type="xkms:CompoundResultType"/>
   <complexType name="CompoundResultType">
      <complexContent>
         <extension base="xkms:ResultAbstractType">
            <choice 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>
   <!-- /CompoundResponse -->

2.7.14 Element <StatusRequest>

[103]The StatusRequest element is

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

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

2.7.15 Element <StatusResult>

[105]The <StatusResult> element is

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

3 Key Information Service Overview

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

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

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

[110]

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

3.1 XKISS Locate Service

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

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

[114]

[115]Figure 2: Locate Service Provides Name Resolution

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

3.1.1 Example: Data Encryption

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

[118]Request:

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

[119]Response:

<?xml version="1.0" encoding="utf-8"?>
<LocateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
      Id="I0b1fc9e8e8e0396bd433c221f953ebb8" Service="http://test.xmltrustcenter.org/XKMS"
      ResultMajor="Success" RequestId="#I0745750b3bf76e91a20298244396a25d" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <UnverifiedKeyBinding Id="I6131fa62efbfe90e1ec1ed4fdf790fcc">
    <ds:KeyInfo>
      <ds:KeyValue>
        <ds:RSAKeyValue>
          <ds:Modulus>4i0BEhQ8Jc4tjwZYbvtMyYfBrIGOMx34K4Cdo2pAzoGnV679FLmGHWnQy2cSj39hf5D1m
                IaPyD3j
/33TdfglTaaKqp7IPf6ei754fOuI/r1HpX7uqsw+j9LC4Z7GnG3yoY/eBJOZ8TRwMnx+MkwmopXP
VLvhMWRyiUOcO3SEkTE=</ds:Modulus>
          <ds:Exponent>AQAB</ds:Exponent>
        </ds:RSAKeyValue>
      </ds:KeyValue>
      <ds:X509Data>
        <ds:X509Certificate>MIIB+zCCAWigAwIBAgIQhzf6GHdFobRCYrjlFTCekjAJBgUrDgMCHQUAMBIxEDA
              OBgNVBAMTB1Rl
c3QgQ0EwHhcNMDIwNjEzMjEzMzQyWhcNMzkxMjMxMjM1OTU5WjAlMSMwIQYDVQQGExpVUyBPPUJv
YiBDb3JwIENOPUJvYiBCYWtlcjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtw2qGqYbO0aK
eZFb0Z3verx3Cp+KS94LiHG09D1DdgTd48FZaB5eXa4U3mLax2/Fsg/cxGZkXJur0YylS8QvRuX+
9STQgiFTO277sHFfRMvtFsuQ56ovrQWH/KoGQZssMUIqO2aN2cbMQJST3a2HZuxqPQ1rwXxHrEoA
XHZv3ysCAwEAAaNHMEUwQwYDVR0BBDwwOoAQRWvWDxzHMSR0xfgYCUPpNqEUMBIxEDAOBgNVBAMT
B1Rlc3QgQ0GCEHKxUcSI0WKITaXFa+Ylh5IwCQYFKw4DAh0FAAOBgQCieDKjvNCo7MPsgUwHydki
d4KnulcuBbZet87lcIA7ReH1qEK4s0p49po2UM69eWG7hfv8LW2Ga8HiEexTwLDFBvH2g7f09xI/
vYgPw4qhJfWoZuY/HWHUzZIRSoggipndVfdvUkmsFSx1rR4FMu0mYBjq79OkYsmwISQlaXejUg==</ds:X509Certif
      icate>
        <ds:X509Certificate>MIIB9zCCAWSgAwIBAgIQcrFRxIjRYohNpcVr5iWHkjAJBgUrDgMCHQUAMBIxEDA
              OBgNVBAMTB1Rl
c3QgQ0EwHhcNMDIwNjEzMjEzMzQxWhcNMzkxMjMxMjM1OTU5WjASMRAwDgYDVQQDEwdUZXN0IENB
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPF33VmCmSSFufPnu0JdFaKsPHsx0ee+OYedhM
xVh3LXMkMNC++JWDva7H+E9o+uj7dt5cwxHSePsyxPx3Vq+AbEZOsYxGxXgf4OuGb8ONBv3B5c8h
raOg24c5hjFS6tfNzoiatLVKHeOmPnifhkBI8h8LD7dLHsHfKUrVNwIJNQIDAQABo1YwVDANBgNV
HQoEBjAEAwIHgDBDBgNVHQEEPDA6gBBFa9YPHMcxJHTF+BgJQ+k2oRQwEjEQMA4GA1UEAxMHVGVz
dCBDQYIQcrFRxIjRYohNpcVr5iWHkjAJBgUrDgMCHQUAA4GBAAynWUPRSbabAEuX0Z8kKN/C2GoE
uULW73QxX6Q0PHAatRM6G9ZnzU+ce3lELgOj0Usw/xC9Y+2FMgj68rIas+DId5JMMj+SIZEUV1vP
PTEiEQ16Gxz9piUQoFljhI22hEl8ki0hIJlFGnki+K9dhv/7trMrfKSSHAPIDQZuz01P</ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <KeyUsage>Signature</KeyUsage>
    <KeyUsage>Encryption</KeyUsage>
    <KeyUsage>Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="bob@bobcorp.test" />
  </UnverifiedKeyBinding>
</LocateResult>

3.1.2 Example: Document Signature

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

[121]Request:

<?xml version="1.0" encoding="utf-8"?>
<LocateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
      Id="Ic3d3ccf7914e669572b49c4ee0fbabd1" Service="http://test.xmltrustcenter.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>KeyValue</RespondWith>
  <QueryKeyBinding>
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>MIICAjCCAW+gAwIBAgIQlzQovIEbLLhMa8K5MR/juzAJBgUrDgMCHQUAMBIxEDA
              OBgNVBAMTB1Rl
c3QgQ0EwHhcNMDIwNjEzMjEzMzQxWhcNMzkxMjMxMjM1OTU5WjAsMSowKAYDVQQGEyFVUyBPPUFs
aWNlIENvcnAgQ049QWxpY2UgQWFyZHZhcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMoy
4c9+NoNJvJUnV8pqPByGb4FOJcU0VktbGJpO2imiQx+EJsCt27z/pVUDrexTyctCWbeqR5a40JCQ
mvNmRUfg2d81HXyA+iYPl4L6nUlHbkLjrhPPtMDSd5YHjyvnCN454+Hr0paA1MJXKuw8ZMkjGYsr
4fSYpPELOH5PDJEBAgMBAAGjRzBFMEMGA1UdAQQ8MDqAEEVr1g8cxzEkdMX4GAlD6TahFDASMRAw
DgYDVQQDEwdUZXN0IENBghBysVHEiNFiiE2lxWvmJYeSMAkGBSsOAwIdBQADgYEAKp+RKhDMIVIb
ooSNcoIeV/wVew1bPVkEDOUwmhAdRXUA94uRifiFfmp9GoN08Jkurx/gF18RFB/7oLrVY+cpzRoC
ipcnAnmh0hGY8FNFmhyKU1tFhVFdFXB5QUglkmkRntNkOmcb8O87xO0XktmvNzcJDes9PMNxrVtC
hzjaFAE=</ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <KeyUsage>Signature</KeyUsage>
  </QueryKeyBinding>
</LocateRequest>

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

[123]Response:

<?xml version="1.0" encoding="utf-8"?>
<LocateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
      Id="I9ef51fbe324e8bff07e69414462efe4c" Service="http://test.xmltrustcenter.org/XKMS"
      ResultMajor="Success" RequestId="#Ic3d3ccf7914e669572b49c4ee0fbabd1" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <UnverifiedKeyBinding Id="I28a07e741dcc00396cce85b61aa80479">
    <ds:KeyInfo>
      <ds:KeyValue>
        <ds:RSAKeyValue>
          <ds:Modulus>zvbTdKsTprGAKJdgi7ulDR0eQBptLv/SJNIh3uVmPBObZFsLbqPwo5nyLOkzWlEHNbShP
                MRp1qFr
AfF13LMmeohNYfCXTHLqH1MaMOm+BhXABHB9rUKaGoOBjQPHCBtHbfMGQYjznGTpfCdTrUgq8VNl
qM2Ph9XWMcc7qbjNHw8=</ds:Modulus>
          <ds:Exponent>AQAB</ds:Exponent>
        </ds:RSAKeyValue>
      </ds:KeyValue>
    </ds:KeyInfo>
    <KeyUsage>Signature</KeyUsage>
    <KeyUsage>Encryption</KeyUsage>
    <KeyUsage>Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="alice@alicecorp.test" />
  </UnverifiedKeyBinding>
</LocateResult>

3.2 XKISS: Validate Service

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

[125]

[126] Figure 3: Validate Service Provides Key Validation

3.2.1 Example: Document Signature

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

[128]Request:

<?xml version="1.0" encoding="utf-8"?>
<ValidateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
      Id="I1083e8e39034a9e5b33506c62bec34e8" Service="http://test.xmltrustcenter.org/XKMS"
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>KeyName</RespondWith>
  <RespondWith>Multiple</RespondWith>
  <QueryKeyBinding>
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>MIICAjCCAW+gAwIBAgIQlzQovIEbLLhMa8K5MR/juzAJBgUrDgMCHQUAMBIxEDA
              OBgNVBAMTB1Rl
c3QgQ0EwHhcNMDIwNjEzMjEzMzQxWhcNMzkxMjMxMjM1OTU5WjAsMSowKAYDVQQGEyFVUyBPPUFs
aWNlIENvcnAgQ049QWxpY2UgQWFyZHZhcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMoy
4c9+NoNJvJUnV8pqPByGb4FOJcU0VktbGJpO2imiQx+EJsCt27z/pVUDrexTyctCWbeqR5a40JCQ
mvNmRUfg2d81HXyA+iYPl4L6nUlHbkLjrhPPtMDSd5YHjyvnCN454+Hr0paA1MJXKuw8ZMkjGYsr
4fSYpPELOH5PDJEBAgMBAAGjRzBFMEMGA1UdAQQ8MDqAEEVr1g8cxzEkdMX4GAlD6TahFDASMRAw
DgYDVQQDEwdUZXN0IENBghBysVHEiNFiiE2lxWvmJYeSMAkGBSsOAwIdBQADgYEAKp+RKhDMIVIb
ooSNcoIeV/wVew1bPVkEDOUwmhAdRXUA94uRifiFfmp9GoN08Jkurx/gF18RFB/7oLrVY+cpzRoC
ipcnAnmh0hGY8FNFmhyKU1tFhVFdFXB5QUglkmkRntNkOmcb8O87xO0XktmvNzcJDes9PMNxrVtC
hzjaFAE=</ds:X509Certificate>
        <ds:X509Certificate>MIIB9zCCAWSgAwIBAgIQcrFRxIjRYohNpcVr5iWHkjAJBgUrDgMCHQUAMBIxEDA
              OBgNVBAMTB1Rl
c3QgQ0EwHhcNMDIwNjEzMjEzMzQxWhcNMzkxMjMxMjM1OTU5WjASMRAwDgYDVQQDEwdUZXN0IENB
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPF33VmCmSSFufPnu0JdFaKsPHsx0ee+OYedhM
xVh3LXMkMNC++JWDva7H+E9o+uj7dt5cwxHSePsyxPx3Vq+AbEZOsYxGxXgf4OuGb8ONBv3B5c8h
raOg24c5hjFS6tfNzoiatLVKHeOmPnifhkBI8h8LD7dLHsHfKUrVNwIJNQIDAQABo1YwVDANBgNV
HQoEBjAEAwIHgDBDBgNVHQEEPDA6gBBFa9YPHMcxJHTF+BgJQ+k2oRQwEjEQMA4GA1UEAxMHVGVz
dCBDQYIQcrFRxIjRYohNpcVr5iWHkjAJBgUrDgMCHQUAA4GBAAynWUPRSbabAEuX0Z8kKN/C2GoE
uULW73QxX6Q0PHAatRM6G9ZnzU+ce3lELgOj0Usw/xC9Y+2FMgj68rIas+DId5JMMj+SIZEUV1vP
PTEiEQ16Gxz9piUQoFljhI22hEl8ki0hIJlFGnki+K9dhv/7trMrfKSSHAPIDQZuz01P</ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <KeyUsage>Signature</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="alice@alicecorp.test" />
  </QueryKeyBinding>
</ValidateRequest>

[129]Response:

<?xml version="1.0" encoding="utf-8"?>
<ValidateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
      Id="Icdc7d2b65911171d75070ce1cee303cb" Service="http://test.xmltrustcenter.org/XKMS"
      ResultMajor="Success" RequestId="#I1083e8e39034a9e5b33506c62bec34e8" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <KeyBinding Id="I4711f138525f319baeb58f50f975a75c">
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>MIICAjCCAW+gAwIBAgIQlzQovIEbLLhMa8K5MR/juzAJBgUrDgMCHQUAMBIxEDA
              OBgNVBAMTB1Rl
c3QgQ0EwHhcNMDIwNjEzMjEzMzQxWhcNMzkxMjMxMjM1OTU5WjAsMSowKAYDVQQGEyFVUyBPPUFs
aWNlIENvcnAgQ049QWxpY2UgQWFyZHZhcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMoy
4c9+NoNJvJUnV8pqPByGb4FOJcU0VktbGJpO2imiQx+EJsCt27z/pVUDrexTyctCWbeqR5a40JCQ
mvNmRUfg2d81HXyA+iYPl4L6nUlHbkLjrhPPtMDSd5YHjyvnCN454+Hr0paA1MJXKuw8ZMkjGYsr
4fSYpPELOH5PDJEBAgMBAAGjRzBFMEMGA1UdAQQ8MDqAEEVr1g8cxzEkdMX4GAlD6TahFDASMRAw
DgYDVQQDEwdUZXN0IENBghBysVHEiNFiiE2lxWvmJYeSMAkGBSsOAwIdBQADgYEAKp+RKhDMIVIb
ooSNcoIeV/wVew1bPVkEDOUwmhAdRXUA94uRifiFfmp9GoN08Jkurx/gF18RFB/7oLrVY+cpzRoC
ipcnAnmh0hGY8FNFmhyKU1tFhVFdFXB5QUglkmkRntNkOmcb8O87xO0XktmvNzcJDes9PMNxrVtC
hzjaFAE=</ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
    <KeyUsage>Signature</KeyUsage>
    <KeyUsage>Encryption</KeyUsage>
    <KeyUsage>Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="alice@alicecorp.test" />
    <Status StatusValue="Valid">
      <ValidReason>Signature</ValidReason>
      <ValidReason>IssuerTrust</ValidReason>
      <ValidReason>RevocationStatus</ValidReason>
      <ValidReason>ValidityInterval</ValidReason>
    </Status>
  </KeyBinding>
</ValidateResult>

3.3 Using Locate and Validate

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

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

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

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

3.3.1 DNS Integration

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

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

[136]

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

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

4 Key Information Service Message Set

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

4.1 Key Binding Specification

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

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

UnverifiedKeyBinding

Specifies the parameters of a particular instance of a key binding but
      not the status.

KeyBinding

Specifies the parameters of a particular instance of a key binding

QueryKeyBinding

A template used to specify one or more key bindings using query by
      example.

PrototypeKeyBinding

A template used to specify the key binding parameters requested in a
      registration request.

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

4.1.1 Abstract Type KeyBindingAbstractType

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

Id [Optional]

Identifier of the key binding.

<ds:KeyInfo> [Optional]

The public key information to which the key binding information is bound

<KeyUsage> [0 to 3]

The cryptographic key uses for which the key may be used

<UseKeyWith> [Any Number]

The applications with which the key may be used together with the
      application specific subject identifier of the key holder for that
      application

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

[145]The following schema defines the KeyBindingAbstractType type:

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

4.1.2 Element <KeyUsage>

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

xkms:Encryption

The key pair may be used for encryption and decryption

xkms:Signature

The key pair may be used for signature and verification

xkms:Exchange

The key pair may be used for key exchange

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

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

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

   <!-- KeyUsage -->
   <element name="KeyUsage" type="xkms:KeyUsageType"/>
   <simpleType name="KeyUsageType">
      <restriction base="QName">
         <enumeration value="xkms:Encryption"/>
         <enumeration value="xkms:Signature"/>
         <enumeration value="xkms:Exchange"/>
      </restriction>
   </simpleType>
   <!-- /KeyUsage -->

4.1.3 Element <UseKeyWith>

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

QueryKeyBinding / TemplateKeyBinding

    A key binding is requested that meets the specified criteria. 
    If the service is unable to meet the criteria exactly 'best guess' is 
    acceptable.

UnverifiedKeyBinding / KeyBinding

    The key may be used for the purpose specified (if unverified 
    after validation). If more than one use key with is specified then all are 
    applicable jpointly and severaly

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

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