XML Key Management Specification (XKMS 2.0)

W3C Editors Copy 20th June 2002

This version:

http://www.w3c.org/2001/XKMS/Drafts/XKMS-20020620

Latest version:

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

Previous version:

http://www.w3c.org/2001/XKMS/Drafts/XKMS-20020419/  

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)

W3C Editors Copy 20th June 2002

Abstract

Status of this document

Table Of Contents

Executive Summary

1 Introduction

1.1 Editorial and Conformance Conventions

1.2 Definition of Terms

1.3 Namepaces

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

2.2 Security Enhancements

2.3 Message Processing

2.4 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 Locate Service

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

7 Cryptographic Algorithm Specific Parameters

7.1 Use of Limited-Use Shared Secret Data

8 Security Considerations

8.1 Replay Attacks

8.2 Denial of Service

8.3 Recovery Policy

8.4 Security of Limited Use Shared Secret

9 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

C.4 Locate Request Example 1

C.5 Locate Request Example 2

C.6 Validate Request

C.7 Registration of Client Generated Key Pair

C.8 Registration of Server Generated key Pair

Appendix D References

Appendix E Legal Notices

Appendix F Work In Progress

F.1 Outstanding Issues

F.2 Issues Addressed in this Draft

F.3 Issues Addressed in Draft 8

F.4 Issues Addressed in Previous Drafts

Executive Summary

¶9 This document specifies protocols for distributing and registering public keys, suitable for use in conjunction with the proposed standard for XML Signature [XML-SIG] developed by the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF) and an anticipated companion standard for XML encryption.  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 The X-KISS specification defines a protocol for a Trust service that resolves public key information contained in XML-SIG elements. The X-KISS protocol allows a client of such a service to delegate part or all of the tasks required to process <ds:KeyInfo> elements. A key objective of the protocol design is to minimize the complexity of application implementations by allowing them to become clients and thereby to be shielded from the complexity and syntax of the underlying PKI used to establish trust relationships. The underlying PKI may be based upon a different specification such as X.509/PKIX, SPKI or PGP.

¶11 The X-KRSS specification defines a protocol for a web service that accepts registration of public key information. Once registered, the public key may be used in conjunction with other web services including X-KISS.

¶12 Both protocols are defined in terms of structures expressed in the XML Schema Language, protocols employing the Simple Object Access Protocol (SOAP) v1.1 [SOAP] and relationships among messages defined by the Web Services Definition Language v1.0 [WSDL]. Expression of XKMS in other compatible object encoding schemes is also possible.

1 Introduction

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

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

¶15 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 public key.  Its functions include the location of required public keys and describing the binding of such keys to identification information.

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 higher level trust assertion service such as XML Trust Assertion Service Specification [XTASS].

1.1 Editorial and Conformance Conventions

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

¶17 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]:

¶18 "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)"

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

¶20 The following terms are used within this document with the particular meaning indicated below:

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

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

¶23 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 Namepaces

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

¶25 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 7  1st April 2002
      </documentation>
   </annotation>
   <!-- /Namespace -->

   ...

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

1.4 Key Information Service Specification Overview (Non-Normative)

¶26 X-KISS allows a client to delegate part or all of the tasks required to process XML Signature <ds:KeyInfo> elements to a Trust service. A key objective of the protocol design is to minimize the complexity of applications using XML Signature. By becoming a client of the trust 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.

¶27 By design, the XML Signature Specification 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.

¶28 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.

¶29 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)

¶30 X-KRSS describes a protocol for registration 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.

¶31 The key pair to which the information is bound may be generated in advance by the client or, to support key recovery, may be generated on request by the service. The Registration protocol may also be used for subsequent recovery of a private key.

¶32 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.

¶33 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-Helleman and Elliptic Curve variants.

1.6 Structure of this document

¶34 The remainder of this document describes the XML Key Information Service Specification and XML Key Registration Service Specification.

Section 2: XKMS 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

¶35 At the semantic level the XKMS protocol consists of pairs of requests and responses. The XKMS protocol binding allows for the case in which an additional request/response round trip is required to support cases such as pending responses and 2 phase requests for replay attack protection.

¶36 Each XKMS response message contains a MajorResult code that determines whether the response is final or further processing is required. The protocol is specified in the CSP formalism [CSP] as follows:

Final = { Success, VersionMismatch, Sender, Receiver }

Request → Result.Final

|

Request → Result.Pending→ PendingNotification→Request→ Result.Final

|

Request → Result.Represent→ Request→Result.Final

2.1 Protocol Version

¶37 The protocol version is indicated by the schema URI.

2.2 Security Enhancements

¶38 Security enhancements MAY be applied to control the following risks:

• Authenticity of the Request
• Port transposition, Request is bound to intended service
• Authenticity of the Response
• Response Replay Attack prevention, Response is bound to request
• Request Replay Attack prevention, Request is acted on exactly once
• Confidentiality

¶39 The security enhancements required varies according to the application. In the case of a free or un-metered service the service may not require authentication of the request. A responder that requires an authenticated request must know in that circumstance that the request corresponds to the specified response.

2.2.1 Confidentiality and Integrity

¶40 Conforming XKMS services MAY support the use of encryption to ensure message confidentiality and MUST support the use of authentication to ensure message integrity as follows:

• The use of XML Signature to authenticate the message payload MUST be supported.
• The use of TLS [TLS] to support authentication and encryption of the entire SOAP transaction SHOULD be supported
• If at some future date payload authentication and encryption is specified as a part of the SOAP this means of authentication is preferred.

¶41 Note that regardless of the means used to protect the confidentiality of XKMS messages certain data items such as private keys MUST be subject to an additional layer of encryption at the element level.

¶42 In the case that payload authentication is employed the message is signed using XML signature in enveloped mode. The scope of the signature is the message element.

¶43 The means by which the client determines that the signing key is trustworthy is outside the scope of this specification. Possible mechanisms include:

• A root key embedded in the client application
• A trustworthy signing key exchanged using an XML based assertion mechanism such as that proposed by XTAML.
• A signing key obtained using some other retrieval mechanism such as PKIX or SPKI.

2.2.2 Correspondence of Response to Request

¶44 In order to prevent response replay and request message substitution attacks the requestor SHOULD ensure that the response corresponds to the request. The mechanism employed depends on whether or not the request is authenticated.

No Authentication

In this case no authentication is possible

Non-authenticated Request, Authenticated Response

[Here what I think we want to say is that the request SHOULD be authenticated with a signature that specifies a message digest and the response should specify the same message digest as an authenticated signature property, alternatively we may want to specify a slot for the digest]

Authenticated Request, Authenticated Response

If the request and the response are authenticated the correspondence of the request and response may be determined by verifying the value of RequestID in the response.

2.2.3 Request Replay Protection

¶45 An XKMS service MAY at its option protect against replay attacks by means of a two phase protocol:

¶46 In the first phase the requestor presents the request and the service responds the MajorResult value Represent and presents a nonce.

¶47 In the second phase the requestor represents the original request together with the nonce.

¶48 The service can protect against replay attacks by ensuring that it only responds to each nonce once. This may be achieved in a computationally efficient manner by appropriate construction of the nonce value. The actual construction of the nonce value is outside the scope of this specification and may be chosen as site specific circumstances dictate.

¶49 For example the nonce may be constructed from the current time at the service, a unique serial number and a Message Authentication Code computer computed over the preceding items using a  secret key known only to the service:

¶50 nonce = time + serial + M ( time + serial , k )

¶51 The service may limit the time interval in which replay attacks are possible by rejecting nonce values that specify an unacceptable time value or an incorrect MAC value.

¶52 The service may prevent replay attacks completely by tracking the serial numbers for which responses have already been given.

2.3 Message Processing

¶53 The following sections summarize the message processing steps taken by both parties in each of the message

2.3.1 All Messages

Generation

Service is set to the value of the URI to which the XKMS request is directed
ds:Signature is generated in enveloped mode over the entire element derived from the MessageAbstractType

Processing

The value of Service is verified
The ds:Signature value is verified (if required)

2.3.2 Single phase Request / Response

Requestor generation of the Request Message

RequestID is set to a randomly generated unique value
Nonce and OriginalRequestID  are not present
RespondWith values Represent and/or Pending MAY be specified

Service processing of the Request Message

Verify that request meets service authorization policy
Process request to completion

Service generation of the Response Message

ResponseID is set to a randomly generated unique value
RequestID is set to the value specified in the request

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

Requestor processing of the Response Message

The value of RequestID is verified

2.3.3 Two phase Request / Response

¶54 The processing steps specified for the single phase case are performed with the following exceptions:

Requestor generation of the Phase 1 Request Message

RespondWith value Represent MUST be specified

Service processing of the Phase 1 Request Message

Request is NOT processed

Service generation of the Phase 1 Response Message

Nonce value is set in accordance with service replay protection requirements

MajorResult is set to Represent

Requestor processing of the Phase 1 Response Message

Proceed to phase 2

¶55 The processing steps specified for the single phase case are performed with the following exceptions:

Requestor generation of the Phase 2 Request Message

OriginalRequestID  set to value in Phase 1 request
Nonce value is set to value in Phase 1 response

Service processing of the Phase 2 Request Message

Verify value of Nonce

Verify that request meets service authorization policy
Process request to completion

Service generation of the Phase 2 Response Message

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

Requestor processing of the Phase 2 Response Message

If MajorResult set to a non-final value consider to be failure

2.3.4 Pending Response

¶56 The processing steps specified for the single phase case are performed with the following exceptions:

Requestor generation of the Initial Request Message

As in the single phase case except that:
RespondWith value Pending MUST be specified

Service processing of the Initial Request Message

Schedule request for asynchronous processing

Service generation of the Initial Response Message

MajorResult is set to Pending

Requestor processing of the Initial Response Message

Register request as pending completion, wait for notification.

¶57 The processing steps specified for the single phase case are performed with the following exceptions:

Requestor generation of the Pending Request Message

Request element is PendingRequest

OriginalRequestID  set to value in initial request
ResponseID is set to value in initial response

Service processing of the Pending Request Message

Match pending request to pending response

Service generation of the Pending Response Message

ResponseID is set to a randomly generated unique value

RequestID  set to value in Pending request

Requestor processing of the Pending Response Message

If MajorResult set to a non-final value consider to be failure

2.4 Syntax

2.4.1 Type MessageAbstractType

¶58 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 in enveloped mode. The scope of the signature is the element derived from the MessageAbstractType abstract type.

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 attacks

¶59 The following schema defines the MessageAbstractType abstract type:

   <!-- MessageAbstractType -->
   <complexType name="MessageAbstractType" abstract="true">
      <sequence>
         <element ref="ds:Signature" minOccurs="0" />
      </sequence>
      <attribute name="Service" type="anyURI" use="required" />
      <attribute name="Nonce" type="ds:CryptoBinary" use="optional" />
   </complexType>
   <!-- /MessageAbstractType -->

2.4.2 Type RequestAbstractType

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

<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 <RespondWith> value.

RequestID  [Required]

A unique identifier generated by the requestor.

OriginalRequestID  [Optional]

Specifies the identifier of the original request in the case of a represented or pending request

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.

¶61 The following schema defines the RequestAbstractType abstract type:

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

2.4.3 Element <RespondWith>

¶62 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 <ds:Keyinfo> element [XML-SIG] or the private key information defined in section 6.3.2. The XML Signature elements are described here for convenience. The normative reference is the specification [XML-SIG].

¶63 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.

¶64 The following identifiers are defined:

¶107 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 Respond element values in this case would be "KeyName" and "KeyValue".

¶108 The following schema defines the <RespondWith> element::

   <!-- RespondWith -->
   <element name="RespondWith" type="QName" />
   <simpleType name="RespondWithEnumType">
      <restriction base="QName">
         <enumeration value="KeyName" />
         <enumeration value="KeyValue" />
         <enumeration value="X509Cert" />
         <enumeration value="X509Chain" />
         <enumeration value="X509CRL" />
         <enumeration value="OCSP" />
         <enumeration value="RetrievalMethod" />
         <enumeration value="MgmtData" />
         <enumeration value="PGP" />
         <enumeration value="PGPWeb" />
         <enumeration value="SPKI" />
         <enumeration value="Multiple" />
         <enumeration value="Private" />
      </restriction>
   </simpleType>
   <!-- /RespondWith -->

2.4.4 Element <PendingNotification>

¶109 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.

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

¶111 The following mechanisms are defined:

¶112 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.4.5 Element <PendingRequest>

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

ResponseID  [Optional]

The value of the ResponseID attribute sent in the original pending response.

¶114 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="IDREF" use="optional" />
         </extension>
      </complexContent>
   </complexType>
   <!-- /PendingRequest -->

2.4.6 Element <ResultAbstractType>

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

ResultMajor  [Required]

The most significant component of the result code

ResultMinor  [Optional]

The least significant component of the result code

RequestID  [Required]

The unique identifier RequestID specified in the request

ResponseID  [Required]

A unique identifier generated by the service.

¶116 If the MajorResult value has the value Represent the nonce attribute MUST be present and MUST NOT be the empty string.

¶117 The following schema defines the ResultAbstractType abstract type:

   <!-- ResultAbstractType -->
   <complexType name="ResultAbstractType" abstract="true">
      <complexContent>
         <extension base="xkms:MessageAbstractType">
            <attribute name="ResultMajor" type="QName" use="required" />
            <attribute name="ResultMinor" type="QName" use="required" />
            <attribute name="RequestID" type="IDREF" use="required" />
            <attribute name="ResponseID" type="ID" use="required" />
         </extension>
      </complexContent>
   </complexType>
   <!-- /ResultAbstractType -->

2.4.6.1 Result Codes

¶118 Result codes consist of a major code and a minor code. This specification uses the notation ResultMajor.ResultMinor to specify a result code. For example the result code Sender.NoMatch indicates a ResultMajor code of Sender and a ResultMinor code of NoMatch.

¶119 The following ResultMajor codes are defined:

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

¶121 The following ResultMinor codes are defined:

3 Key Information Service Overview

¶122 In the XML Signature Specification, 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.

¶123 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.

¶124 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).

¶125

¶126 Figure 1: Substitution of the <ds:KeyInfo> element as a message is passed amongst processors

3.1 XKISS Locate Service

¶127 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.

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

¶129

¶130 Figure 2: Locate Service Provides Name Resolution

¶131 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.

3.1.1 Example: Data Encryption

¶132 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 bobcorp.test then sends an XKMS Locate request to the discovered XKMS service for a key bound to bob@bobcorp.test and the S/MIME or PGP rotocol.

¶133 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://test.xmltrustcenter.org/XKMS" RequestId="enLA2Uclpj9XZcf7hzS02A==" 
      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>
  <KeyBindingQuery Id="Hw6lCli9I7zxqmYSymHhDw==">
    <KeyUsage>Encryption</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2440" Identifier="bob@bobcorp.test" />
    <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="bob@bobcorp.test" />
  </KeyBindingQuery>
</LocateRequest>

¶134 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://test.xmltrustcenter.org/XKMS" ResultMajor="Success" 
      RequestId="enLA2Uclpj9XZcf7hzS02A==" ResponseId="IWkzXR+RX619poeNscVM9Q==" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <KeyBinding Id="TQ+XPzESyDA75lDVXFGyZA==">
    <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>
    </KeyInfo>
    <KeyUsage>Signature</KeyUsage>
    <KeyUsage>Encryption</KeyUsage>
    <KeyUsage>Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="bob@bobcorp.test" />
  </KeyBinding>
</LocateResult>

3.1.2 Example: Document Signature

¶135 Bob recieves 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 trust 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.

¶136 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://test.xmltrustcenter.org/XKMS" RequestId="4O6Wk141c8IjfoPE0V/7zg==" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>KeyValue</RespondWith>
  <KeyBindingQuery Id="6TRukJCuffkhsw2wuhJoXg==">
    <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>
    </KeyInfo>
    <KeyUsage>Signature</KeyUsage>
  </KeyBindingQuery>
</LocateRequest>

¶137 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..

¶138 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://test.xmltrustcenter.org/XKMS" ResultMajor="Success" 
      RequestId="4O6Wk141c8IjfoPE0V/7zg==" ResponseId="H0M221XNBzEoyVteIZGVaw==" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <KeyBinding Id="/hJA8mw2cI+ujjjJu3fNIg==">
    <KeyInfo>
      <ds:KeyValue>
        <ds:RSAKeyValue>
          <ds:Modulus>zvbTdKsTprGAKJdgi7ulDR0eQBptLv/SJNIh3uVmPBObZFsLbqPwo5nyLOkzWlEHNbShP
                MRp1qFr
AfF13LMmeohNYfCXTHLqH1MaMOm+BhXABHB9rUKaGoOBjQPHCBtHbfMGQYjznGTpfCdTrUgq8VNl
qM2Ph9XWMcc7qbjNHw8=</ds:Modulus>
          <ds:Exponent>AQAB</ds:Exponent>
        </ds:RSAKeyValue>
      </ds:KeyValue>
    </KeyInfo>
    <KeyUsage>Signature</KeyUsage>
    <KeyUsage>Encryption</KeyUsage>
    <KeyUsage>Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="alice@alicecorp.test" />
  </KeyBinding>
</LocateResult>

3.2 XKISS: Validate Service

¶139 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 trust service a prototype containing some or all of the elements for which the status of the trust binding is required. If the information in the prototype is incomplete, the trust service MAY obtain additional data required from an underlying PKI Service. Once the validity of the Key Binding has been determined the Trust service returns the status result to the client (Figure 3).

¶140

¶141 Figure 3: Validate Service Provides Key Validation

3.2.1 Example: Document Signature

¶142 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, has a valid validity interval and has not been revoked.

¶143 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://test.xmltrustcenter.org/XKMS" RequestId="zzjmNi9YL+dnkRXzDoqPoQ==" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>KeyName</RespondWith>
  <RespondWith>KeyValue</RespondWith>
  <RespondWith>Multiple</RespondWith>
  <KeyBindingQuery Id="T/QMi7gGuKCcNWPi120A/w==">
    <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>
    </KeyInfo>
    <KeyUsage>Signature</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="alice@alicecorp.test" />
  </KeyBindingQuery>
</ValidateRequest>

¶144 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://test.xmltrustcenter.org/XKMS" ResultMajor="Success" 
      RequestId="zzjmNi9YL+dnkRXzDoqPoQ==" ResponseId="0WeinJVdbyBKruXhiqTscg==" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <KeyBinding Id="m0/p5bekjemI4tV+FPBkig==">
    <KeyInfo>
      <ds:KeyValue>
        <ds:RSAKeyValue>
          <ds:Modulus>zvbTdKsTprGAKJdgi7ulDR0eQBptLv/SJNIh3uVmPBObZFsLbqPwo5nyLOkzWlEHNbShP
                MRp1qFr
AfF13LMmeohNYfCXTHLqH1MaMOm+BhXABHB9rUKaGoOBjQPHCBtHbfMGQYjznGTpfCdTrUgq8VNl
qM2Ph9XWMcc7qbjNHw8=</ds:Modulus>
          <ds:Exponent>AQAB</ds:Exponent>
        </ds:RSAKeyValue>
      </ds:KeyValue>
    </KeyInfo>
    <KeyUsage>Signature</KeyUsage>
    <KeyUsage>Encryption</KeyUsage>
    <KeyUsage>Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="alice@alicecorp.test" />
    <Reason>IssuerTrust</Reason>
    <Reason>RevocationStatus</Reason>
    <Reason>ValidityInterval</Reason>
  </KeyBinding>
</ValidateResult>

3.3 Using Locate and Validate

¶145 The Locate and Validate operations are both used to obtain information about a public key from a Trust 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 Trust Service verifies the information returned. A Location service SHOULD attempt to provide only information which is trustworthy to the best of its knowledge. A Validation service undertakes to only return information which has been positively validated by the Trust Service as meeting its validation criteria.

¶146 For example a Locate Service MAY act as an aggregator of public key related information obtained from a variety of sources without performing any checks to determine whether specific information is current or establishing any formal trust policy. Such a service would correspond to the role of a directory in a traditional PKI. A Validate service MAY provide a service that validates key information presented to it but does not provide aggregation services. An email client might use a pair of such services in combination to obtain a valid public key for the intended recipient of an encrypted email by first querying the un-trusted Locate service and then forward the information received to a Validate service to establish its trustworthiness (Figure 4).

¶147

¶148 Figure 4: Combined use of Locate and Validate service

3.3.1 DNS Integration

¶149 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@cryptographer.test. Unless an XKMS service which provides key information about keys bound to email addresses in the domain cryptographer.test is known a priori some means of locating the correct XKMS service is required.

¶150 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@cryptographer.test 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 cryptographer.test. The Validate service does not have an established trust relationship with the cryptographer.test XKMS service and so a Locate request is made to determine if any key information bound to bob@cryptographer.test 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.

¶151

¶152 Figure 5: Combined use of Locate and Validate service

¶153 Appendix B provides further information on the use of the DNS SRV record.

4 Key Information Service Message Set

¶154 The protocol consists of pairs of messages, with an application sending a request message to a trust service and the service responding with another message. 

4.1 Locate Service

¶155 The Locate service accepts as input a <ds:Keyinfo> element that specifies a public key and returns one or more <ds:Keyinfo> elements that relate to the same public key. The <ds:Keyinfo> elements returned are specified by the Respond element in the request.

4.1.1 Locate Request Element <LocateRequest>

¶156 The request message contains a <LocateRequest> element that contains the following element.

KeyInfoQuery  [Required]

A single complex structure containing a <ds:Keyinfo> element that specifies the public key for which additional data is requested.

¶157  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:KeyBindingQuery" />
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /LocateRequest -->

4.1.2 Locate Response Element<LocateResult>

¶158 The request message contains a <LocateResult> element

<ds:KeyInfo>  [Any Number]

A <ds:Keyinfo>element that matches the criteria specified in the corresponding request.

¶159  The following schema defines the <LocateResult> element:

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

4.2 Validate Service

¶160 The Validate service allows the client to query the binding between a <ds:Keyinfo> element and other data such as an identifier. The client supplies a prototype for the <KeyBinding> assertion requested. The prototype may specify either a <KeyId> or a <ds:Keyinfo> element or both. The server returns one or more <KeyBinding> assertions that meet the criteria specified in the request.

4.2.1 Element <KeyBinding>

¶161 The <KeyBinding> element asserts a binding between data elements that relate to a public key including <KeyName>, <KeyID>, <KeyValue> and <X509Data>. Furthermore, the Service represents to the client accessing the service and to that client alone that the binding between the data elements is valid under whatever trust policy the service offers to that client.

ID  [Optional]

Identifier of the key binding.

<KeyInfo>   [Optional]

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

<ProcessInfo>  [Optional]

Processing information associated with a key binding that end clients SHOULD treat as opaque data

<ValidityInterval>  [Required]

The time interval in which the key binding relationship is asserted

<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

<Reason>  [Any Number]

Reason

any [Any Number]

¶162 The following schema defines the <KeyBinding> element and the KeyBindingType type. The <Query> and <Prototype> elements share the KeyBindingType definition.

   <!-- KeyBinding -->
   <element name="KeyBinding" type="xkms:KeyBindingType" />
   <complexType name="KeyBindingType">
      <sequence>
         <element ref="xkms:KeyInfo" minOccurs="0" />
         <element ref="xkms:PassPhrase" minOccurs="0" />
         <element ref="xkms:ProcessInfo" minOccurs="0" />
         <element ref="xkms:ValidityInterval" minOccurs="0" />
         <element ref="xkms:KeyUsage" minOccurs="0" maxOccurs="3" />
         <element ref="xkms:UseKeyWith" minOccurs="0" maxOccurs="unbounded" />
         <element ref="xkms:Reason" minOccurs="0" maxOccurs="unbounded" />
         <any namespace="##other" processContents="lax" minOccurs="0" 
               maxOccurs="unbounded" />
      </sequence>
      <attribute name="ID" type="ID" use="optional" />
   </complexType>
   <element name="KeyBindingQuery" type="xkms:KeyBindingType" />
   <!-- /KeyBinding -->

4.2.2 Element <KeyInfo>

¶163 The following schema defines the <KeyInfo> element of the KeyInfoType type imported from the XML Signature Specification:

   <!-- KeyInfo -->
   <element name="KeyInfo" type="ds:KeyInfoType" />
   <!-- /KeyInfo -->

4.2.3 Element <PassPhrase>

¶164 The <PassPhrase> element contains a MAC output value encoded as a base64 string.

¶165 On initial registration the <PassPhrase> value is obtained by first performing the MAC calculation on the pass phrase value, then performing a second MAC calculation on the result.

¶166 To prove knowledge of the pass phrase in a subsequent revocation request the <PassPhrase> value is obtained by performing the MAC calculation on the pass phrase value.

¶167 Details of the MAC output value calculation are provided in section 6  below.

¶168 The following schema defines the <PassPhrase> element and the PassPhraseValueType type:

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

4.2.4 Element <ProcessInfo>

¶169 The <ProcessInfo> element MAY be used to specify processing information associated with a key binding that end clients SHOULD treat as opaque data.

any  [Any Number]

Processing information to be treated as opaque data by clients.

¶170 TBS Example of use

¶171 The following schema defines the <ProcessInfo> element and the ProcessInfoType type:

   <!-- ProcessInfo -->
   <element name="ProcessInfo" type="xkms:ProcessInfoType" />
   <complexType name="ProcessInfoType">
      <sequence minOccurs="0" maxOccurs="unbounded">
         <any namespace="##other" />
      </sequence>
   </complexType>
   <!-- /ProcessInfo -->

4.2.5 Element <ValidityInterval>

¶172 The <ValidityInterval> element specifies limits on the validity of the assertion.

NotBefore     [Optional]

Time instant at which the validity interval begins

NotOnOrAfter     [Optional]

Time instant at which the validity interval has ended

¶173 All dateTime values MUST fully specify the date.

¶174 The NotBefore and NotOnOrAfter attributes are optional. If the NotBefore attribute is omitted the assertion is valid on any date up to but excluding the date specified in the NotOnOrAfter attribute . If the NotOnOrAfter attribute is omitted the assertion is valid from the NotBefore attribute with no expiry. If both elements are omitted the assertion is valid at any time.

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

¶176 Implementations MUST NOT generate time instances that specify leap seconds.

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

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

¶179 The following schema defines the <ValidityInterval> element:

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

4.2.6 Element <KeyUsage>

¶180 The <KeyUsage> element specifies one or more intended uses of the key. If no <KeyUsage> is specified all uses are permitted.

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

¶181 If a key usage is specified that the algorithm does not support (e.g. use of a DSA key for encryption) the element MUST be ignored.

¶182 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.2.7 Element <UseKeyWith>

¶183 The  <UseKeyWith> element specifies a subject and application protocol for which the keys specified in the enclosing key binding may be used.

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.

¶184 The following table lists application URIs for common protocols and the corresponding format for the identifier information:

¶185 The following table describes the formatting for the specified types of identifier:

¶186 The following schema defines the <UseKeyWith> element:

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

4.2.8 Element <Reason>

¶187 The <Reason> element is used to specify a string that specifies a reason for a particular assertion status.

¶188 If the Trust service returns the AssertionStatus value Valid, the <Reason> elements list the status aspects that have been affirmatively verified to be Valid. If the service returns the AssertionStatus value Invalid the Reason element lists the aspects of status that have been determined to be either Invalid or Indeterminate. If the service returns the AssertionStatus value Indeterminate the Reason element lists the aspects of status that have been determined to be Indeterminate.

¶189 The status aspects are defined in the table below. For convenience the equivalent X509 processing steps are given:

¶205 If the Reason code ValidityInterval is returned with a Status code of Invalid additional information MAY be provided in the <ValidityInterval> element of the KeyBinding. If only the NotOnOrAfter attribute is specified it indicates that the specified time instant is before the credential became valid. If only the NotAfter attribute is specified it indicates that either the credential expired or was revoked. If both the NotOnOrAfter and NotAfter attributes are specified it is likely that the credential was suspended and MAY be reinstated at a later time.

¶206 The following schema defines the <Reason> element and the ReasonCodeType type:

   <!-- Reason -->
   <element name="Reason" type="xkms:ReasonEnumType" />
   <simpleType name="ReasonEnumType">
      <restriction base="QName">
         <enumeration value="IssuerTrust" />
         <enumeration value="Status" />
         <enumeration value="ValidityInterval" />
         <enumeration value="Signature" />
      </restriction>
   </simpleType>
   <!-- /Reason -->

4.2.9 Validate Request Element <ValidateRequest>

¶207 The validate request message contains a <ValidateRequest> element:

<KeyBindingQuery>     [Required]

A single KeyBinding structure that is to be completed and validated.

¶208 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:KeyBindingQuery" />
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /ValidateRequest -->

4.2.10 Validate Response Element <ValidateResult>

¶209 The validate response message contains a <ValidateResult> element:

<Keybinding>     [Any Number]

A sequence of <KeyBinding> structures that contain the results of the validation. If no results are found the sequence is empty and the <ResultCode>NoMatch returned. In some circumstances a Locate operation MAY return multiple matching results.

¶210 The following schema defines the <ValidateResult> element and the ValidateResultType type.

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

5 Key Registration Service Overview

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

Register

Information is bound to a public key pair through a key binding

Reissue

A previously registered key binding is reissued.

Revoke

A previously registered key binding is revoked.

Recover

The private key associated with a key binding is recovered.

¶212 The Register operation does not in itself place any requirement on the Registration Service to communicate that information to any other party. In most applications, however, a Registration Service will provide key information to other trust services such as those described in the XKMS specification or a separate underlying PKI such as PKIX.

5.1 Registration

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

¶214 The Registration request message contains a prototype of the requested assertion. The Registration Service MAY require the client to provide additional information to authenticate the request. If the public key pair is generated by the client, the service MAY require the client to provide Proof of Possession of the private key.

¶215 The Registration service MAY accept the name specified in the prototype or MAY substitute its own name.

¶216 On receipt of a registration request, the registration service verifies the authentication and POP information provided (if any). If the registration service accepts the request an assertion is registered. This assertion MAY include some, all or none of the information provided by the prototype assertion and MAY include additional information.

¶217 The Registration Service MAY return part or all of the registered assertion to the client.

¶218

¶219 Figure 5: Registration of a KeyBinding

5.1.1 Example: Registration of Client-Generated Key Pair

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

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

<?xml version="1.0" encoding="utf-8"?>
<RegisterRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
      Service="http://test.xmltrustcenter.org/XKMS" RequestId="hZMRGyATbUL4H7rYOanR6Q==" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>X509Cert</RespondWith>
  <RespondWith>X509Chain</RespondWith>
  <RespondWith>Multiple</RespondWith>
  <Prototype Id="tX4Y83grmj/eIVoeYNuTNg==">
    <KeyInfo>
      <ds:KeyValue>
        <ds:RSAKeyValue>
          <ds:Modulus>zvbTdKsTprGAKJdgi7ulDR0eQBptLv/SJNIh3uVmPBObZFsLbqPwo5nyLOkzWlEHNbShP
                MRp1qFr
AfF13LMmeohNYfCXTHLqH1MaMOm+BhXABHB9rUKaGoOBjQPHCBtHbfMGQYjznGTpfCdTrUgq8VNl
qM2Ph9XWMcc7qbjNHw8=</ds:Modulus>
          <ds:Exponent>AQAB</ds:Exponent>
        </ds:RSAKeyValue>
      </ds:KeyValue>
    </KeyInfo>
    <KeyUsage>Signature</KeyUsage>
    <KeyUsage>Encryption</KeyUsage>
    <KeyUsage>Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2459" Identifier="C=&quot;US&quot; O=&quot;Alice
          Corp&quot; CN=&quot;Alice Aardvark&quot;" />
    <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="alice@alicecorp.test" />
  </Prototype>
  <Authentication>
    <ProofOfPossession>
      <ds:Signature>
        <ds:SignedInfo>
          <ds:CanonicalizationMethod 
                Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
          <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
          <ds:Reference URI="#tX4Y83grmj/eIVoeYNuTNg==">
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
            <ds:DigestValue>ljsEz1vlJvPX5aBLr0kjQI+VZGs=</ds:DigestValue>
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>MHivseFjoElhmT30ZQSWG10fyOOwr1NChXIW1WCFZXgz5/D/Yj5Z1CB3IwvO4Wnw
              seK1HqFv2OrZ
j+lz+LS39O0hpZKvlt5s7XH3FSI5kKUgX90W56wTxDX+MufE4XO6MW72DOXK75bosD3Yr4X+JhZv
dewZxhatfvwW5tOqlb8=</ds:SignatureValue>
      </ds:Signature>
    </ProofOfPossession>
    <KeyBindingAuthentication>
      <ds:Signature>
        <ds:SignedInfo>
          <ds:CanonicalizationMethod 
                Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
          <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1" />
          <ds:Reference URI="#tX4Y83grmj/eIVoeYNuTNg==">
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
            <ds:DigestValue>ljsEz1vlJvPX5aBLr0kjQI+VZGs=</ds:DigestValue>
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>xbglp7MBZdBr88LKlcL95PKpiNY=</ds:SignatureValue>
      </ds:Signature>
    </KeyBindingAuthentication>
  </Authentication>
</RegisterRequest>

¶223 The service accepts the registration and returns the following response:

<?xml version="1.0" encoding="utf-8"?>
<RegisterResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
      Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success" 
      RequestId="hZMRGyATbUL4H7rYOanR6Q==" ResponseId="k9gyjDdhLLV1vbF7RzJjIw==" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <KeyBinding Id="LVrJqd26QzO9GWJD0usQwg==">
    <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>
    </KeyInfo>
    <KeyUsage>Signature</KeyUsage>
    <KeyUsage>Encryption</KeyUsage>
    <KeyUsage>Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2459" Identifier="C=&quot;US&quot; O=&quot;Alice
          Corp&quot; CN=&quot;Alice Aardvark&quot;" />
    <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="alice@alicecorp.test" />
  </KeyBinding>
</RegisterResult>

5.1.2 Example: Registration of Service-Generated Key Pair

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

¶225 Bob requests a  server generated key pair using the authentication code 3N9CJ-JK4JK-S04JF-W0934-JSR09-JWIK4. The request specifies only Encryption and Exchange Key uses as the key is to be escrowed for possible later recovery.

¶226 The calculation of the authentication data and encryption of the private key for this example is shown in Appendix C.

¶227 The response includes both the public key data and the encrypted private key:

<?xml version="1.0" encoding="utf-8"?>
<RegisterResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
      Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success" 
      RequestId="ZP8bsH6zBJIE81DBJFB/Tg==" ResponseId="r47vmRE/i6GcCZwUfKO9pA==" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <KeyBinding Id="VEJawB3y3LgjmWB2cv5Q8g==">
    <KeyInfo>
      <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>
    </KeyInfo>
    <PassPhrase>YDdkeZ6p5ueXnvnOPyI5U7+P2Qo=</PassPhrase>
    <KeyUsage>Encryption</KeyUsage>
    <KeyUsage>Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2459" Identifier="C=&quot;UK&quot; O=&quot;Bob 
          Corp&quot; CN=&quot;Bob Baker&quot;" />
    <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="bob@bobcorp.test" />
  </KeyBinding>
  <PrivateKey>
    <xenc:EncryptedData>
      <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
      <xenc:CipherData>
        <xenc:CipherValue>Hnp23IfB9Vpt5f4A6392Lqk3+h+Y999rJhpiexi+xXEWokE1ntr0Z4q4u36hRy0PP
              mAUSs8JbFdF
ViwxPhJj4nl5nmwW8bZkb0KjG/rLeqaXIbGUwYa24lVeIzvIQhYJqMgB7dGQ71bjPDQGglS5Fvgn
rA2zn95YuJGHxy2mAAZpw1jQW6InaIQ//Qksklq6arIqj+wBASUa7DhwxWa1N2H1SQ5eTtG6SdiN
lNtI5doXIvabkFRby+oRqCK+gw7N3eDTyVo5H82ZyRC4JA+norx47adKWViM+4/Ry66RF2zZrlkD
akLw7u32BwMqYG3J96C9icvyKj69R4IuoSflDBP0HHzNOcq80E6lWYcvp9yJVhisp+ZkruSfIXWS
51xrmfhHjG806dn3SWJCYLuY3x3KMdR/b+fC63RtAOVmzlZ0f5uevtzc9duO9rorkn7bKdfwX8Fs
ZvYqs9jdJkuRh+90HozzDiKpYTaagQl5Do2/MUBfGJqr7qWJhrPfK/JS97Y+8bLSj70zjIAvGmRX
aTjTCxDh8i2hn0/hVzrsAhI2Rwr4uG6JNJosG3C2RqPrVuyktT/ebv1vW2jo4UYhWxq5STngR6tK
DeszLiJTdbtWfXfgLVlp0cgvEdJPS0y4gWMZ2rjk8G3qA2la9oEMYeh2wuuXY3geQPZnSepK/SIa
j93885uMmUB8GVwUQ5ZRCwkBcDjbGL1WEP70R/SWBm++U/XMeqSBE882iV1ky2llmpz7UUzDkIhL
K+fyTOkljZgwiXFAId6CACs/LYBn0OsX3FORAxQ19xaslpHFTQxpE9/GcRfhUhRIv1cwppCAPtL0
pSltwtxNEoXSDFKUQi1HxTJLSo23mCsV4hxNOD9PPXwbDRILqGxTjLWnhpw275OltfWnChVTTiu7
IuwEKJa+7cmeC5YagyRWi3DhUwsj3XR2qC4Nxh7QzfHB910/8oS7pLVUGjWFOS7Hy5iYdsKb9r8K
4+UOBNLdoiWWXgqkuNOsKEY4tIMqicQ78e2PI7JZy10yHUg=</xenc:CipherValue>
      </xenc:CipherData>
    </xenc:EncryptedData>
  </PrivateKey>
</RegisterResult>

5.2 Reissue

¶228 A Registration service MAY permit clients to reissue previously issued assertions. A reissue request is made in the same manner as the initial registration of a key.

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

5.2.1 Example: Reissue

¶230 Alice requests reissue of her previously issued RSA key pair for her email address.

¶231 The X-KRSS request message contains the following <ReissueRequest> element:

<?xml version="1.0" encoding="utf-8"?>
<ReissueRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
      Service="http://test.xmltrustcenter.org/XKMS" RequestId="ZB+o5L/ZPSy7xNR4g1STKg==" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>X509Cert</RespondWith>
  <RespondWith>X509Chain</RespondWith>
  <KeyBinding Id="d44udZpC9HFNgU+LCYVcug==">
    <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>
    </KeyInfo>
  </KeyBinding>
  <Authentication>
    <ProofOfPossession>
      <ds:Signature>
        <ds:SignedInfo>
          <ds:CanonicalizationMethod 
                Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
          <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
          <ds:Reference URI="#d44udZpC9HFNgU+LCYVcug==">
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
            <ds:DigestValue>ClxylVZlNsYE7lFWUaX1CZT2phk=</ds:DigestValue>
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>ar8L/51RtsiSA2c+kmn4W0aY5oFxD0MG83skRWMsZPz8ZBrxnalolmTTNTHxD+gM
              41kYnbxD6BkX
FLtjSMrlxhkPu4IWTpwOzsbL4zJr/8vZipAuVYnz/my4zQ+n2eOpMzT5+Mq+BUh5OfOFkSm4Ev82
aCxs7hG4/3EKQPKSa4U=</ds:SignatureValue>
      </ds:Signature>
    </ProofOfPossession>
  </Authentication>
</ReissueRequest>

¶232 The service accepts the registration and returns the following response:

<?xml version="1.0" encoding="utf-8"?>
<ReissueResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
      Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success" 
      RequestId="ZB+o5L/ZPSy7xNR4g1STKg==" ResponseId="2s091pGj3zE9nR7DfUQwVQ==" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <KeyBinding Id="dF5jKstGU2HrqU8atK2ctQ==">
    <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>
    </KeyInfo>
    <KeyUsage>Signature</KeyUsage>
    <KeyUsage>Encryption</KeyUsage>
    <KeyUsage>Exchange</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="alice@alicecorp.test" />
  </KeyBinding>
</ReissueResult>

5.3 Revocation

¶233 A Registration service MAY permit clients to revoke previously issued assertions.

5.3.1 Example: Revocation

¶234 For some reason Alice requests the Registration Service revoke the binding for her public key. Alice authenticates herself using the pass phrase value established during registration.

¶235 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://test.xmltrustcenter.org/XKMS" RequestId="nGH0QiFc5fmSIccwVLtUDA==" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <KeyBinding Id="NHYGbgxadnv0QE1j8roa1g==">
    <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>
    </KeyInfo>
  </KeyBinding>
  <Authentication>
    <PassPhraseSecretAuthentication>PHx8li2SUhrJv2e1DyeWbGbD6rs=</PassPhraseSecretAuthentic
          ation>
  </Authentication>
</RevokeRequest>

¶236 The service responds that the key binding has been revoked:

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

5.4 Key Recovery

¶237 A Registration service MAY permit clients to request key recovery. A key recovery request is made in the same manner as the initial registration of a key except that:

• The key recovery service is likely to require time to respond to the recovery request and MAY return a <ResultCode> of Pending.
  
  
• If the Registration service has no record of the assertion the result code NotFound is returned.
  
  

5.4.1 Example: Key Recovery

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

¶239 The request parameters for the key recovery are:

<?xml version="1.0" encoding="utf-8"?>
<RecoverRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
      Service="http://test.xmltrustcenter.org/XKMS" RequestId="WB91ALuRc83bv5UyWZM0VA==" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <RespondWith>PrivateKey</RespondWith>
  <KeyBinding Id="8qaK1/K2eUDSa9wNn9b1wg==">
    <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>
    </KeyInfo>
  </KeyBinding>
  <Authentication>
    <KeyBindingAuthentication>
      <ds:Signature>
        <ds:SignedInfo>
          <ds:CanonicalizationMethod 
                Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
          <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1" />
          <ds:Reference URI="#8qaK1/K2eUDSa9wNn9b1wg==">
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
            <ds:DigestValue>5tVMAuw24jXXR/7CIIQjHyeWEik=</ds:DigestValue>
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>6d5RJrwNUj63CFt4EYAL88omDsE=</ds:SignatureValue>
      </ds:Signature>
    </KeyBindingAuthentication>
  </Authentication>
</RecoverRequest>

¶240 The registration service policy is to revoke a private key whenever key recovery is performed. The service returns the revoked key binding and the private key parameters:

<?xml version="1.0" encoding="utf-8"?>
<RecoverResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
      Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success" 
      RequestId="WB91ALuRc83bv5UyWZM0VA==" ResponseId="LB3tobvBmyZ/ZLq3ExQpMw==" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <KeyBinding Id="8qaK1/K2eUDSa9wNn9b1wg==">
    <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>
    </KeyInfo>
  </KeyBinding>
  <PrivateKey>
    <xenc:EncryptedData>
      <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
      <xenc:CipherData>
        <xenc:CipherValue>hcq+ZmNCyjbotxsLUwR7EyKqwxw2hvoLVJDBiE2ToHAG9x3d5G5byhD0CvAumVUY1
              FIPurlEsU6D
IiI1dkIBuzlDiKqF42O2GAGu2VQTjI8vBlR0uUCUG4XIpWoiMNfFff/ZVUp/aaNdwvgYkpLjtGnS
XKq49pqPjTf+jJx1ZHCsrRM/9toNOPko723PMcYQzvOOhy92mxG2Hnmbtk0amgrHTmeVhfQg7zOa
yFHxZeIOhGg5Z58qCpBBPu9QtaEuX4V8R1AaHvKBCn6M5nCzOPGZFAiW+I59obC+T42Rj9/W3V1o
8CBr5LujZ/dXZqBpDitmiVOnp2rMnUpuyrK1EOG5Nr6YFSN0fqaw+YaIKgIvNWtTszXuvzDMM0BN
Frwee/Pu5lszT+PhOgDxH/g8dcHnKvvy2fcvjmky0ZLUbEnBeeLRdWxrs3MdMbfIx7OKw4Q3cOKG
qnnxEFdDs40yoBLOZaOWNTKHYERU/N4mtNmUoSD9yIW2tEYJKbUmMNOZ9n1IOasB3jHyWuWdy+ih
K1US2kXJogpmdr5NVs/G3u+mnwx6LKKPtjBsxIfecnbkrAHCin7c80wMhLE1qUrKyX2ns5zjt2kp
W/DuzJKyJ88YuJZMCYr4AzlfYWRmQ36DPKNCu6M4HSnFIS+BhnXwf5NWyxeHzXUkqnLkWrHZulwn
xwGGH2SHKO/JK5GjG+Ln2Hr95DEVzy8Tipu3nIQ9JXvMhElMiFsKz1VRAypnWjkWv1Su1M3D+Tq/
FX+5//pPraQdoFxKIU7n95QIyrKyd4e5/fGmottpBZRClYDn2OQQ40s1OZrBIQChSuxeIUmA4+4L
hbZNQyXNic84OXXa2lc7bKCygxIow1ZvU3yaKuhJ+j+qNWjt3MkjfuJEMUiBbJKnTfcWhG29BOuD
SKU7QBTd4guirt57GbZ4vnxuFTNPlgQtuD4yliQvYz0/+qa8GRSg7Zh/QXbCMFrqr+lIfIjOhgD/
SDH9grlm//qIxp90OzzzI0Zlk0MD0s6bHWkq+JYVRG6vmnU=</xenc:CipherValue>
      </xenc:CipherData>
    </xenc:EncryptedData>
  </PrivateKey>
</RecoverResult>

<?xml version="1.0" encoding="utf-8"?>
<RSAKeyPair xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <Modulus>4i0BEhQ8Jc4tjwZYbvtMyYfBrIGOMx34K4Cdo2pAzoGnV679FLmGHWnQy2cSj39hf5D1mIaPyD3j
/33TdfglTaaKqp7IPf6ei754fOuI/r1HpX7uqsw+j9LC4Z7GnG3yoY/eBJOZ8TRwMnx+MkwmopXP
VLvhMWRyiUOcO3SEkTE=</Modulus>
  <PublicExponent>AQAB</PublicExponent>
  <PrivateExponent>ystjbFxsWdF2FAmyfUAh54kr5Ir9f2PdwtO9hGqe1Qp3iy1BirWWRQU9y0MN51BlkUXej/YH
        MZoc
tlaRpfLrLfcNYB4odKP4Tku+3eqqoc70kMYorU34NJQeeDVvDHaCm21qiSa9Je9QTlHI4PN38kM0
N3mEuHXRuw7MQI7W62k=</PrivateExponent>
  <P>9bfMM0ZkTd/bs9Vy9vGSdaOZ2qQh/0JVbpAMXSd0AEtPj8m28ZaGW+8wQ4OdOEmouNPDkhm6O7HC
TJ3IY18Phw==</P>
  <Q>66PdfVufWHWghfUMVg3SypsiFWYCWIlgzl0AyZfUpRufjAMXpkpJckNh5qBAEikEPEsY7p3DvISV
TDqHeh/Xhw==</Q>
</RSAKeyPair>

5.5 Request Authentication

¶241 The Service SHOULD ensure that all requests are valid.

¶242 Authenticity: The request message originated from the specified party.

¶243 Integrity: The request message has not been modified.

¶244 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.

¶245 Registration services set their own authentication policy. This specification defines an authentication mechanism that employs a shared secret established out of band between the client and the Registration Service.

¶246 Services SHOULD require that clients demonstrate Proof of Possession of the private key components of a public key if a request is made to register a valid assertion bound to that public key.

¶247 Services SHOULD accept Proof of Possession of the private key component of a public key to effect revocation of any assertion bound to that key.

6 Key Registration Service Message Set

¶248 The protocol operations consist of a remote procedure call that consists of a single request message sent by the client to the Registration Service followed by a single response message sent by the server to the client. 

6.1 Registration

¶249 The Request message specifies a <Prototype> element that has the type KeyBinding and provides the prototype for the key binding to be registered.

¶250 The <Prototype> element may contain only partial information, a key without a name or a name without a key. In this case, the client is requesting that the Registration Service provide the additional information required to complete the binding.

¶251 For example, the client may not specify the public key parameters because the public and private key pair is to be generated by the Registration Service.

6.1.1 Element <Authentication>

¶252 The  <Authentication> element is used to authenticate the <keybinding> element within an XKRSS request.

<ProofOfPossesion>     [Optional]

Proof of possession of the public key component of the key binding.

<KeyBindingAuthentication>     [Optional]

Authentication of the key binding by means of a signature using a previously established key.

<PassPhraseAuthentication>     [Optional]

Plaintext data used to authenticate the registration request that is not bound to the key binding.

¶253 The following schema defines the <Authentication> element:

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

6.1.2 Element <PassPhraseAuthentication>

¶254 The <PassPhraseAuthentication> contains a plaintext limited use shared secret that is used to authenticate the request.

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

¶256 The following schema defines the <PassPhraseAuthentication> element:

   <!-- PassPhraseAuthentication -->
   <element name="PassPhraseAuthentication" type="string" />
   <!-- /PassPhraseAuthentication -->

6.1.3 Element <PassPhraseSecretAuthentication>

¶257 The <PassPhraseSecretAuthentication> is used to authenticate revocation messages only. The element demonstrates knowledge of the revocation pass phrase established during authentication.

¶258 The following schema defines the <PassPhraseSecretAuthentication> element:

6.1.4 Element <KeyBindingAuthentication>

¶259 The <KeyBindingAuthentication> element: contains a XML Signature element that is used to authenticate the <KeyBinding> request using a previously established key. The signature scope is the <KeyBinding> prototype using the public key that is to be registered.

<ds:Signature>     [Required]

An XML Signature element that contains a detached signature over the <KeyBinding> element.

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

6.1.5 Element <ProofOfPossession>

¶261 The <ProofOfPossession> element contains a XML Signature element. The signature scope is the <KeyBinding> prototype using the public key that is to be registered. The private key component of the public key contained within the <KeyBinding> is used to generate the signature.

<ds:Signature>     [Required]

An XML Signature element that contains a detached signature over the <KeyBinding> element. The signing key is the key identified by the ds:KeyInfo element within the <KeyBinding> element.

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

6.1.6 Element <PrivateKey>

¶263 The <Private> element contains the encrypted private key parameters returned by the service in a response to a registration request with server generated keys or a response to a successful recovery request.

<xenc:EncryptedData>     [Required]

The encrypted private key data

¶264 The following schema defines the <PrivateKey> element:

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

6.1.7 Register Request Element <RegisterRequest>

¶265 The register request message contains a <RegisterRequest> element that contains the following elements:

<Prototype>     [Required]

Specifies elements that the client requests be registered.

<Authentication>     [Required]

Information that authenticates the request.

¶266 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:Prototype" />
               <element ref="xkms:Authentication" />
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <element name="Prototype" type="xkms:KeyBindingType" />
   <!-- /RegisterRequest -->

6.1.8 Register Response Element<RegisterResult>

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

¶268 The following schema defines the <RegisterResult> element:

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

6.1.9 Reissue Request Element<ReissueRequest>

¶269 The reissue request message contains a <ReissueRequest> element that contains the following elements:

< KeyBinding >     [Required]

Identifies the key binding to be reissued

<Authentication>     [Required]

Information that authenticates the request.

¶270 The following schema defines the <ReissueRequest> element:

   <!-- ReissueRequest -->
   <element name="ReissueRequest" type="xkms:ReissueRequestType" />
   <complexType name="ReissueRequestType">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <sequence>
               <element ref="xkms:KeyBinding" />
               <element ref="xkms:Authentication" />
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /ReissueRequest -->

6.1.10 Reissue Response Element<ReissueResult>

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

¶272  The following schema defines the <ReissueResult> element:

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

6.1.11 Revoke Request Element <RevokeRequest>

¶273 The revoke request message contains a <RevokeRequest> element that contains the following elements:

< KeyBinding >     [Required]

Identifies the key binding to be revoked.

<Authentication>     [Required]

Information that authenticates the request.

¶274 The following schema defines the <RevokeRequest> element:

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

6.1.12 Revoke Response Element<RevokeResult>

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

¶276 The following schema defines the <RevokeResult> element:

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

6.1.13 Recover Request Element<RecoverRequest>

¶277 The recover request message contains a <RecoverRequest> element that contains the following elements:

< KeyBinding >     [Required]

Identifies the key binding to be recovered.

<Authentication>     [Required]

Information that authenticates the request.

¶278 The following schema defines the <RecoverRequest> element:

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

6.1.14 Recover Response Element<RecoverResult>

¶279 The request message contains a <RecoverResult> element that contains the following elements:

< KeyBinding >     [Any Number]

May be present to advertise a change to the status of the key binding made as a result of the key recovery.

<PrivateKey>    [Optional]

The values of the private key parameters of the recovered private key

¶280 The following schema defines the <RecoverResult> element:

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

7 Cryptographic Algorithm Specific Parameters

7.1 Use of Limited-Use Shared Secret Data

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

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

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

• All shared string values are encoded as XML
• All space and control characters are removed.
• All upper case characters in the Latin-1 alphabet (A-Z) are converted to lower case.
• No other characters, including accented characters are converted

¶284 Keying material is derived from the shared string using a MAC function. Different MAC keying values are used according to the use of the symmetric key derived as follows:

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

¶296 If the output of the MAC function provides less keying material than is required additional keying material is obtained as follows:

¶297 block₀ = MAC (converted, key)

¶298 block_n+1 = MAC (converted, key XOR block_n)

¶299 output = block₀ + block₁ ...  block_n

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

7.1.1 Element <RSAKeyPair>

¶301 The <RSAKeyPair> element specifies the public and private parameters of an RSA Key Pair.

<Modulus> (Required)

The modulus

<PublicExponent> (Required)

The public exponent

<PrivateExponent> (Required)

The private exponent

<P> (Optional)

The prime parameter P

<Q> (Optional)

The prime parameter Q

¶302 The public and private parameters for the RSA algorithm are generated from the parameters p and q. Although private key operations may be performed using the private modulus alone knowledge of the generator parameters permits optimizations such as the Chinese Remainder Theorem to be applied. Accordingly the private key element permits these to be specified.

¶303  The following schema defines the <RSAKeyPair> element:

   <!-- RSAKeyPair -->
   <element name="RSAKeyPair" type="xkms:RSAKeyPairType" />
   <complexType name="RSAKeyPairType">
      <sequence>
         <element name="Modulus" type="ds:CryptoBinary" />
         <element name="PublicExponent" type="ds:CryptoBinary" />
         <element name="PrivateExponent" type="ds:CryptoBinary" />
         <element name="P" type="ds:CryptoBinary" minOccurs="0" />
         <element name="Q" type="ds:CryptoBinary" minOccurs="0" />
      </sequence>
   </complexType>
   <!-- /RSAKeyPair -->

8 Security Considerations

¶304 Implementations SHOULD consider the following security issues.

8.1 Replay Attacks

¶305 Implementations SHOULD ensure that replay of a previous XKMS response is not possible.

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

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

• 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

¶308 Freshness tokens MAY be encoded as XML Signature Properties.

8.2 Denial of Service

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

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

8.3 Recovery Policy

¶310 Key recovery policy is left as an implementation decision.

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

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

8.4 Security of Limited Use Shared Secret

¶313 If a limited use shared secret is used care must be taken to ensure that the secret is not revealed to an attacker. A means of protecting the confidentiality of the shared secret SHOULD be employed. This MAY be a message level or transport level protocol that protects both encryption and integrity such as SSL.

¶314 Note that merely encrypting the shared secret does not provide adequate security since the <PassPhraseAuth> element is not cryptographically bound to the message.

9 Acknowledgments

¶315 The authors also acknowledge the extensive assistance provided in the design stage of this specification by David Solo (CitiGroup), and the contributions of Steve Farrell (Baltimore), Mack Hicks (Bank of America), Andrew Layman  (Microsoft), Dr Paul Boisen (NSA),  Dan Guinan, Marc Hayes, Alex Deacon, Mingliang Pei (VeriSign).

Appendix A Schemas

A.1 XKMS Schema

<?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 7  1st April 2002
      </documentation>
   </annotation>
   <!-- /Namespace -->
   <!-- MessageAbstractType -->
   <complexType name="MessageAbstractType" abstract="true">
      <sequence>
         <element ref="ds:Signature" minOccurs="0" />
      </sequence>
      <attribute name="Service" type="anyURI" use="required" />
      <attribute name="Nonce" type="ds:CryptoBinary" use="optional" />
   </complexType>
   <!-- /MessageAbstractType -->
   <!-- RequestAbstractType -->
   <complexType name="RequestAbstractType" abstract="true">
      <complexContent>
         <extension base="xkms:MessageAbstractType">
            <sequence>
               <element ref="xkms:RespondWith" minOccurs="0" maxOccurs="unbounded" />
               <element ref="xkms:PendingNotification" minOccurs="0" />
            </sequence>
            <attribute name="RequestID" type="ID" use="required" />
            <attribute name="OriginalRequestID" type="IDREF" use="optional" />
            <attribute name="ResponseLimit" type="integer" use="optional" />
         </extension>
      </complexContent>
   </complexType>
   <!-- /RequestAbstractType -->
   <!-- RespondWith -->
   <element name="RespondWith" type="QName" />
   <simpleType name="RespondWithEnumType">
      <restriction base="QName">
         <enumeration value="KeyName" />
         <enumeration value="KeyValue" />
         <enumeration value="X509Cert" />
         <enumeration value="X509Chain" />
         <enumeration value="X509CRL" />
         <enumeration value="OCSP" />
         <enumeration value="RetrievalMethod" />
         <enumeration value="MgmtData" />
         <enumeration value="PGP" />
         <enumeration value="PGPWeb" />
         <enumeration value="SPKI" />
         <enumeration value="Multiple" />
         <enumeration value="Private" />
      </restriction>
   </simpleType>
   <!-- /RespondWith -->
   <!-- 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 -->
   <!-- PendingRequest -->
   <element name="PendingRequest" type="xkms:PendingRequestType" />
   <complexType name="PendingRequestType">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <attribute name="ResponseID" type="IDREF" use="optional" />
         </extension>
      </complexContent>
   </complexType>
   <!-- /PendingRequest -->
   <!-- ResultAbstractType -->
   <complexType name="ResultAbstractType" abstract="true">
      <complexContent>
         <extension base="xkms:MessageAbstractType">
            <attribute name="ResultMajor" type="QName" use="required" />
            <attribute name="ResultMinor" type="QName" use="required" />
            <attribute name="RequestID" type="IDREF" use="required" />
            <attribute name="ResponseID" type="ID" use="required" />
         </extension>
      </complexContent>
   </complexType>
   <!-- /ResultAbstractType -->
   <!-- KeyBinding -->
   <element name="KeyBinding" type="xkms:KeyBindingType" />
   <complexType name="KeyBindingType">
      <sequence>
         <element ref="xkms:KeyInfo" minOccurs="0" />
         <element ref="xkms:PassPhrase" minOccurs="0" />
         <element ref="xkms:ProcessInfo" minOccurs="0" />
         <element ref="xkms:ValidityInterval" minOccurs="0" />
         <element ref="xkms:KeyUsage" minOccurs="0" maxOccurs="3" />
         <element ref="xkms:UseKeyWith" minOccurs="0" maxOccurs="unbounded" />
         <element ref="xkms:Reason" minOccurs="0" maxOccurs="unbounded" />
         <any namespace="##other" processContents="lax" minOccurs="0" 
               maxOccurs="unbounded" />
      </sequence>
      <attribute name="ID" type="ID" use="optional" />
   </complexType>
   <element name="KeyBindingQuery" type="xkms:KeyBindingType" />
   <!-- /KeyBinding -->
   <!-- KeyInfo -->
   <element name="KeyInfo" type="ds:KeyInfoType" />
   <!-- /KeyInfo -->
   <!-- PassPhrase -->
   <element name="PassPhrase" type="xkms:PassPhraseValueType" />
   <simpleType name="PassPhraseValueType">
      <restriction base="base64Binary" />
   </simpleType>
   <!-- /PassPhrase -->
   <!-- ProcessInfo -->
   <element name="ProcessInfo" type="xkms:ProcessInfoType" />
   <complexType name="ProcessInfoType">
      <sequence minOccurs="0" maxOccurs="unbounded">
         <any namespace="##other" />
      </sequence>
   </complexType>
   <!-- /ProcessInfo -->
   <!-- ValidityInterval -->
   <element name="ValidityInterval" type="xkms:ValidityIntervalType" />
   <complexType name="ValidityIntervalType">
      <attribute name="NotBefore" type="dateTime" />
      <attribute name="NotOnOrAfter" type="dateTime" />
   </complexType>
   <!-- /ValidityInterval -->
   <!-- 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 -->
   <!-- UseKeyWith -->
   <element name="UseKeyWith" type="xkms:UseKeyWithType" />
   <complexType name="UseKeyWithType">
      <attribute name="Application" type="anyURI" />
      <attribute name="Identifier" type="string" />
   </complexType>
   <!-- /UseKeyWith -->
   <!-- Reason -->
   <element name="Reason" type="xkms:ReasonEnumType" />
   <simpleType name="ReasonEnumType">
      <restriction base="QName">
         <enumeration value="IssuerTrust" />
         <enumeration value="Status" />
         <enumeration value="ValidityInterval" />
         <enumeration value="Signature" />
      </restriction>
   </simpleType>
   <!-- /Reason -->
   <!-- LocateRequest -->
   <element name="LocateRequest" type="xkms:LocateRequestType" />
   <complexType name="LocateRequestType">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <sequence>
               <element ref="xkms:KeyBindingQuery" />
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /LocateRequest -->
   <!-- LocateResult -->
   <element name="LocateResult" type="xkms:LocateResultType" />
   <complexType name="LocateResultType">
      <complexContent>
         <extension base="xkms:ResultAbstractType">
            <sequence>
               <element ref="xkms:KeyBinding" minOccurs="0" maxOccurs="unbounded" />
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /LocateResult -->
   <!-- ValidateRequest -->
   <element name="ValidateRequest" type="xkms:ValidateRequestType" />
   <complexType name="ValidateRequestType">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <sequence>
               <element ref="xkms:KeyBindingQuery" />
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /ValidateRequest -->
   <!-- ValidateResult -->
   <element name="ValidateResult" type="xkms:ValidateResultType" />
   <complexType name="ValidateResultType">
      <complexContent>
         <extension base="xkms:ResultAbstractType">
            <sequence>
               <element ref="xkms:KeyBinding" minOccurs="0" maxOccurs="unbounded" />
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /ValidateResult -->
   <!-- Authentication -->
   <element name="Authentication" type="xkms:AuthenticationType" />
   <complexType name="AuthenticationType">
      <sequence>
         <element ref="xkms:ProofOfPossession" minOccurs="0" />
         <element ref="xkms:KeyBindingAuthentication" minOccurs="0" />
         <element ref="xkms:PassPhraseAuthentication" minOccurs="0" />
      </sequence>
   </complexType>
   <!-- /Authentication -->
   <!-- PassPhraseAuthentication -->
   <element name="PassPhraseAuthentication" type="string" />
   <!-- /PassPhraseAuthentication -->
   <!-- KeyBindingAuthentication -->
   <element name="KeyBindingAuthentication" type="xkms:KeyBindingAuthenticationType" />
   <complexType name="KeyBindingAuthenticationType">
      <sequence>
         <element ref="ds:Signature" />
      </sequence>
   </complexType>
   <!-- /KeyBindingAuthentication -->
   <!-- ProofOfPossession -->
   <element name="ProofOfPossession" type="xkms:ProofOfPossessionType" />
   <complexType name="ProofOfPossessionType">
      <sequence>
         <element ref="ds:Signature" />
      </sequence>
   </complexType>
   <!-- /ProofOfPossession -->
   <!-- Private -->
   <element name="PrivateKey" type="xkms:PrivateKeyType" />
   <complexType name="PrivateKeyType">
      <sequence>
         <element ref="xenc:EncryptedData" />
      </sequence>
   </complexType>
   <!-- /Private -->
   <!-- RegisterRequest -->
   <element name="RegisterRequest" type="xkms:RegisterRequestType" />
   <complexType name="RegisterRequestType">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <sequence>
               <element ref="xkms:Prototype" />
               <element ref="xkms:Authentication" />
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <element name="Prototype" type="xkms:KeyBindingType" />
   <!-- /RegisterRequest -->
   <!-- RegisterResult -->
   <element name="RegisterResult" type="xkms:RegisterResultType" />
   <complexType name="RegisterResultType">
      <complexContent>
         <extension base="xkms:ResultAbstractType">
            <sequence>
               <element ref="xkms:KeyBinding" minOccurs="0" maxOccurs="unbounded" />
               <element ref="xkms:PrivateKey" minOccurs="0" />
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /RegisterResult -->
   <!-- ReissueRequest -->
   <element name="ReissueRequest" type="xkms:ReissueRequestType" />
   <complexType name="ReissueRequestType">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <sequence>
               <element ref="xkms:KeyBinding" />
               <element ref="xkms:Authentication" />
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /ReissueRequest -->
   <!-- ReissueResult -->
   <element name="ReissueResult" type="xkms:ReissueResultType" />
   <complexType name="ReissueResultType">
      <complexContent>
         <extension base="xkms:ResultAbstractType">
            <sequence>
               <element ref="xkms:KeyBinding" minOccurs="0" maxOccurs="unbounded" />
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /ReissueResult -->
   <!-- RevokeRequest -->
   <element name="RevokeRequest" type="xkms:RevokeRequestType" />
   <complexType name="RevokeRequestType">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <sequence>
               <element ref="xkms:KeyBinding" />
               <element ref="xkms:Authentication" />
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /RevokeRequest -->
   <!-- RevokeResult -->
   <element name="RevokeResult" type="xkms:RevokeResultType" />
   <complexType name="RevokeResultType">
      <complexContent>
         <extension base="xkms:ResultAbstractType">
            <sequence>
               <element ref="xkms:KeyBinding" minOccurs="0" maxOccurs="unbounded" />
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /RevokeResult -->
   <!-- RecoverRequest -->
   <element name="RecoverRequest" type="xkms:RecoverRequestType" />
   <complexType name="RecoverRequestType">
      <complexContent>
         <extension base="xkms:RequestAbstractType">
            <sequence>
               <element ref="xkms:KeyBinding" />
               <element ref="xkms:Authentication" />
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /RecoverRequest -->
   <!-- RecoverResult -->
   <element name="RecoverResult" type="xkms:RecoverResultType" />
   <complexType name="RecoverResultType">
      <complexContent>
         <extension base="xkms:ResultAbstractType">
            <sequence>
               <element ref="xkms:KeyBinding" minOccurs="0" maxOccurs="unbounded" />
               <element ref="xkms:PrivateKey" minOccurs="0" />
            </sequence>
         </extension>
      </complexContent>
   </complexType>
   <!-- /RecoverResult -->
   <!-- RSAKeyPair -->
   <element name="RSAKeyPair" type="xkms:RSAKeyPairType" />
   <complexType name="RSAKeyPairType">
      <sequence>
         <element name="Modulus" type="ds:CryptoBinary" />
         <element name="PublicExponent" type="ds:CryptoBinary" />
         <element name="PrivateExponent" type="ds:CryptoBinary" />
         <element name="P" type="ds:CryptoBinary" minOccurs="0" />
         <element name="Q" type="ds:CryptoBinary" minOccurs="0" />
      </sequence>
   </complexType>
   <!-- /RSAKeyPair -->
   <!-- End Schema -->
</schema>

Appendix B Service Location Configuration

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

B.1 Domain Name Service (DNS)

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

¶318 _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.

¶319 The following service values are defined:

_XKMS_XKISS_SOAP_HTTP

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

_XKMS_XKRSS_SOAP_HTTP

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

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

B.1.1 Examples

¶321 The following SRV record advertises an XKMS XKISS service on port 80 of border-xkms.cryptographer.test:

¶322 _XKMS_XKISS_SOAP_HTTP._TCP.cryptographer.test - IN 0 1 80 border-xkms.cryptographer.test

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

¶324 _XKMS_XKISS_SOAP_HTTP._TCP.cryptographer.test - IN 0 50 80 main1.cryptographer.test
_XKMS_XKISS_SOAP_HTTP._TCP.cryptographer.test - IN 0 50 80 main2.cryptographer.test
_XKMS_XKISS_SOAP_HTTP._TCP.cryptographer.test - IN 1 1 80 backup.cryptographer.test

Appendix C Sample Protocol Exchanges

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

C.1 Authentication Computation

¶326 The calculation of the authentication values used in the examples.

C.1.1 Alice Registration Authentication Key

Authentication Data

024837

Converted Authentication Data

[30][32][34][38][33][37]

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

[d6][cc][34][cb][83][fa][e2][99] [3a][39][3a][a8][e7][de][9a][06] [c7][fa][2c][92]

C.1.2 Bob Registration Authentication Key

Authentication Data

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

Converted Authentication Data

 [33][6e][39][63][6a][6b][34][6a] [6b][73][30][34][6a][66][77][30] [39][33][34][6a][73][72][30][39] [6a][77][69][6b][34]

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

 [2d][7d][34][d5][ba][69][6b][f3] [ea][c7][9f][fe][6d][b5][e7][e7] [99][46][a0][e3]

C.1.3 Bob Registration Private Key Encryption

Authentication Data

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

Converted Authentication Data

[33][6e][39][63][6a][6b][34][6a][6b][73][30][34][6a][66][77][30][39][33][34][6a][73][72][30][39][6a][77][69][6b][34]

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

[82][6d][b2][12][44][89][22][a0][ef][83][da][23][d6][f1][ec][9a][03][03][5a][3e]

Key = First Block XOR 0x4

[86][6d][b2][12][44][89][22][a0][ef][83][da][23][d6][f1][ec][9a][03][03][5a][3e]

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

[6c][15][9b][39][ab][df][15][d4][7a][c6][1c][02][64][66][0d][ea][c5][62][4c][b3]

Final Private Key

[82][6d][b2][12][44][89][22][a0] [ef][83][da][23][d6][f1][ec][9a] [03][03][5a][3e][6c][15][9b][39]

¶327 The private key is used to encrypt Bob's private key as follows:

Initialization Vector

[1e][7a][76][dc][87][c1][f5][5a]

PlainText

<?xml version="1.0" encoding="utf-16"?>
<RSAKeyPair xmlns="http://www.w3.org/2002/03/xkms#"> ...

Plain Text

[3c][3f][78][6d][6c][20][76][65] [72][73][69][6f][6e][3d][22][31] [2e][30][22][20][65][6e][63][6f] [64][69][6e][67][3d][22][75][74] [66][2d][31][36][22][3f][3e][0d] [0a][3c][52][53][41][4b][65][79] [50][61][69][72][20][78][6d][6c] [6e][73][3d][22][68][74][74][70] [3a][2f][2f][77][77][77][2e][77] [33][2e][6f][72][67][2f][32][30] [30][32][2f][30][33][2f][78][6b] ...
[69][72][3e][05][05][05][05][05]

Cipher Text (with pre-pended Initialization Vector)

[1e][7a][76][dc][87][c1][f5][5a] [6d][e5][fe][00][eb][7f][76][2e] [a9][37][fa][1f][98][f7][df][6b] [26][1a][62][7b][18][be][c5][71] [16][a2][41][35][9e][da][f4][67] [8a][b8][bb][7e][a1][47][2d][0f] [3e][60][14][4a][cf][09][6c][57] [45][56][2c][31][3e][12][63][e2] [79][79][9e][6c][16][f1][b6][64] [6f][42][a3][1b][fa][cb][7a][a6] [97][21][b1][94][c1][86][b6][e2] [55][5e][23][3b][c8][42][16][09]

...
[23][b2][59][cb][5d][32][1d][48]

C.1.4 Bob Recovery Private Key Encryption

Authentication Data

A8YUT vuhhu c9h29 8y43u h9j3i 23

Converted Authentication Data

[61][38][79][75][74][76][75][68] [68][75][63][39][68][32][39][38] [79][34][33][75][68][39][6a][33] [69][32][33]

Private Key

[91][8c][67][d8][bc][16][78][86] [dd][6d][39][19][91][c4][49][6f] [14][e2][61][33][8a][4a][d5][be]

C.2 Pass Phrase Computation

¶328 The calculation of the pass phrase values used in the examples.

C.2.1 Alice

Pass Phrase

"Help I Have Revealed My Key"

Converted Pass Phrase

[68][65][6c][70][69][68][61][76][65][72][65][76][65][61][6c][65][64][6d][79][6b][65][79]

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

[3c][7c][7c][96][2d][92][52][1a][c9][bf][67][b5][0f][27][96][6c][66][c3][ea][bb]

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

[e4][01][00][6a][2d][3a][84][52][44][92][ea][b2][0f][2a][8d][87][c9][3f][bb][73]

Base 64 Encoding of Pass Phrase

5AEAai06hFJEkuqyDyqNh8k/u3M=

C.2.2 Bob

Pass Phrase

"Have A Banana"

Converted Pass Phrase

[68][61][76][65][61][62][61][6e][61][6e][61]

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

[f0][66][22][54][af][33][04][3e][44][d2][af][51][ab][66][3f][19][c8][b4][66][9a]

Base 64 Encoding of Pass Phrase Stage 1

PHx8li2SUhrJv2e1DyeWbGbD6rs=

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

[60][37][64][79][9e][a9][e6][e7][97][9e][f9][ce][3f][22][39][53][bf][8f][d9][0a]

Base 64 Encoding of Pass Phrase Stage 2

YDdkeZ6p5ueXnvnOPyI5U7+P2Qo=

C.3 Private Key Parameters

¶329 The parameters of the parties RSA key pairs are as follows:

C.3.1 Alice

<?xml version="1.0" encoding="utf-8"?>
<RSAKeyPair xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <Modulus>zvbTdKsTprGAKJdgi7ulDR0eQBptLv/SJNIh3uVmPBObZFsLbqPwo5nyLOkzWlEHNbShPMRp1qFr
AfF13LMmeohNYfCXTHLqH1MaMOm+BhXABHB9rUKaGoOBjQPHCBtHbfMGQYjznGTpfCdTrUgq8VNl
qM2Ph9XWMcc7qbjNHw8=</Modulus>
  <PublicExponent>AQAB</PublicExponent>
  <PrivateExponent>oMqalfWjmsoka2TQGT97h6irq9ncIbuWpAytS+Klft8sxtcFFrw/ZJthzwqOXwi8tTjUW8Wt
        BJb7
79KMYx68MOdG7eKgSz9yuYMKo3KZVxa0gUvtzBroI3kH/ggqIwT0zgTEU6sDjGIezRt1tt3hmaMO
ekPaOBiGym+h6nv+9+E=</PrivateExponent>
  <P>+6Tn14NSh6SAKPFYwM90SyPpaLUlKrXlkHYK+kz4NhwL0gWFs47wNEMqt3jst2dbMWXGvaS/wGhf
83Z1OiSE7Q==</P>
  <Q>0ovuzCkVfkcLegWTiHU1N7y012ZEMXO1/9at+t/91u5uKvdmV7hW+A9TDfo8Np8lkKxAp7ygNXPB
/LxdjY3Qaw==</Q>
</RSAKeyPair>

C.3.2 Bob

<?xml version="1.0" encoding="utf-8"?>
<RSAKeyPair xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <Modulus>4i0BEhQ8Jc4tjwZYbvtMyYfBrIGOMx34K4Cdo2pAzoGnV679FLmGHWnQy2cSj39hf5D1mIaPyD3j
/33TdfglTaaKqp7IPf6ei754fOuI/r1HpX7uqsw+j9LC4Z7GnG3yoY/eBJOZ8TRwMnx+MkwmopXP
VLvhMWRyiUOcO3SEkTE=</Modulus>
  <PublicExponent>AQAB</PublicExponent>
  <PrivateExponent>ystjbFxsWdF2FAmyfUAh54kr5Ir9f2PdwtO9hGqe1Qp3iy1BirWWRQU9y0MN51BlkUXej/YH
        MZoc
tlaRpfLrLfcNYB4odKP4Tku+3eqqoc70kMYorU34NJQeeDVvDHaCm21qiSa9Je9QTlHI4PN38kM0
N3mEuHXRuw7MQI7W62k=</PrivateExponent>
  <P>9bfMM0ZkTd/bs9Vy9vGSdaOZ2qQh/0JVbpAMXSd0AEtPj8m28ZaGW+8wQ4OdOEmouNPDkhm6O7HC
TJ3IY18Phw==</P>
  <Q>66PdfVufWHWghfUMVg3SypsiFWYCWIlgzl0AyZfUpRufjAMXpkpJckNh5qBAEikEPEsY7p3DvISV
TDqHeh/Xhw==</Q>
</RSAKeyPair>

C.3.3 The XKMS Service

<?xml version="1.0" encoding="utf-8"?>
<RSAKeyPair xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
      xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
      xmlns="http://www.w3.org/2002/03/xkms#">
  <Modulus>wqmaAkC8cZi/KSAO/T9ICP+Blf2MRL66/rgj+c0hqgOrXnkOpDYXQXRWl1RG2DIcROH2KWZPgP2H
JlRc2xiF8dZvahoNCZTsQdqrgmo9hdNFxm65RHQsnUdcUfw24ojP4hGQaBzCAkGt8f0/7W9wg2p/
2fiCGe4gM1Wzixssd2c=</Modulus>
  <PublicExponent>AQAB</PublicExponent>
  <PrivateExponent>ESpJdVdmBpJUkPjNuZEh9gEp2SMRgmJbNOjh6z4mcMqACwWbv+kxJclvdUquMJRCn+RZA4+N
        BS/W
AhBAW+WOsfvyvXqMLk+h3Y8p4qI5xp/DTcJceXUl2902owMOZD2KNI4jmm+AyBB7Vw/oa1GK4era
cK4/acuRjnKWPcgubFk=</PrivateExponent>
  <P>+59K7Ed5qVT6310U4UZi1tec4Bu/2Gwbq9X/4cIZAeX00Ia8PY9SiFrCvCdYzEUi65iCXr0/w8N3
iQUQtjtlSw==</P>
  <Q>xgydSIsBjcJe/XUQovNKE94JaU5GvYmewKs2E3vF8R8UnrjB1tDlF3w5m+44rP6o2LmO8W5hRrKV
QO8jJvWQ1Q==</Q>
</RSAKeyPair>

C.4 Locate Request Example 1

¶330 This example shows the formatting of the X-KISS request and response for the first example in section 2.2  above.

¶331 Request Message

¶332 TBS

¶333 Server Response

¶334 TBS

C.5 Locate Request Example 2

¶335 This example shows the formatting of the X-KISS request and response for the second example in section 2.2  above.

¶336 Request Message

¶337 TBS

¶338 Server Response

¶339 TBS

C.6 Validate Request

¶340 This example shows the formatting of the X-KISS request and response for the example in section 2.2.1 above.

¶341 Request Message

¶342 TBS

¶343 Server Response

¶344 TBS

C.7 Registration of Client Generated Key Pair

¶345 Request Message

¶346 TBS

¶347 Server Response

¶348 TBS

C.8 Registration of Server Generated key Pair

¶349 Request Message

¶350 TBS

¶351 Server Response

¶352 TBS

Appendix D References

¶353 [CSP] C. A. R. Hoare

¶354 [PKCS1] Kaliski, B., PKCS #1: RSA Encryption Version 2.0, RSA Laboratories, also IETF RFC 2437, October 1998.

¶355 [RFC2459] R. Housley, W. Ford, W. Polk, D. Solo, Internet X.509 Public Key Infrastructure Certificate and CRL Profile, IETF  RFC 2459, January 1999.

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

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

¶358 [SOAP] D. Box, D Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. Frystyk Nielsen, S Thatte, D. Winer. Simple Object Access Protocol (SOAP) 1.1, W3C Note 08 May 2000, http://www.w3.org/TR/SOAP/

¶359 [TLS] TBS

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

¶361 [XTASS] P. Hallam-Baker, XML Trust Assertion Service Specification, To Be Published, January 2001

¶362 [XML-SIG]  D. Eastlake, J. R., D. Solo, M. Bartel, J. Boyer , B. Fox , E. Simon. XML-Signature Syntax and Processing, World Wide Web Consortium. http://www.w3.org/TR/xmldsig-core/

¶363 [XML-SIG-XSD] XML Signature Schema available from http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/xmldsig-core-schema.xsd.

¶364 [XML-Enc] XML Encryption Specification, In development.

¶365 [XML-Schema1] H. S. Thompson, D. Beech, M. Maloney, N. Mendelsohn. XML Schema Part 1: Structures, W3C Working Draft 22 September 2000, http://www.w3.org/TR/2000/WD-xmlschema-1-20000922/, latest draft at http://www.w3.org/TR/xmlschema-1/

¶366 [XML-Schema2] P. V. Biron, A. Malhotra, XML Schema Part 2: Datatypes; W3C Working Draft 22 September 2000, http://www.w3.org/TR/2000/WD-xmlschema-2-20000922/, latest draft at http://www.w3.org/TR/xmlschema-2/

Appendix E Legal Notices

¶367 TBS

Appendix F Work In Progress

F.1 Outstanding Issues

F.1.1 Protocol Issues

[I-Examples]

Some remaining issues with examples, in particular the canonicalization of the signature block may be incorrect, the certificates presented bear no relation to the public keys allegedly certified.

[I-Multiple Requests]

Handling of multiple requests needs to be considered

[I-SecurityConsiderations]

Need to add a note to state that the passphrase values for recovery need to be strong (i.e. server generated with 128 bits of randomness) recommend the use of Base32 encoding.

[I-MUST-SHOULD]

Need to specify that support for key recovery is not mandated.

[I-Multiple KeyBindings]

Discuss use of multiple keybindings by client & server

[I-Status]

Is this actually needed after all?

[I-RevokeOnRecover]

The registration authority may have a revoke on recover policy, this would require a means of communicating the change in the keybinding status

[I-Reason]

Add reason codes to examples

[I-ProcessInfo]

Need a decision on keeping this.

F.1.2 Bindings Issues

[I-PayloadHash]

For establishing correspondence of response to a specific request.

[I-SOAP]

Introduce section in the request/response section that discusses the SOAP binding issues, in particular SOAP faults.

[I-KeybindingReturns]

Register, Revoke, Reissue and Recover can all return multiple responses, it appears however that multiple responses are not appropriate here,

[I-MessageProcessing]

Add examples to message processing section.

[I-SeparateMessage]

Separate out the message processing section to allow for convergence with ws-security etc. at later date

F.2 Issues Addressed in this Draft

[I-Examples]

The examples are currently incomplete, in particular the KeyInfo and XML Encryption components are not correctly handled

[I-Passphrase]

Needs to become Base64 data at the very least. - In fact it turns out that the passphrase authentication element was serving two purposes leading to inevitable cross purposes.

F.3 Issues Addressed in Draft 8

[I-Organization]

The section on message formats now precedes discussion of the protocols, before section 2 and 3 were swapped.

[I-Versioning]

The protocol versioning mechanism was amended

[I-QNames]

The use of QNames was rationalized, redundant enumerations were removed

[I-Examples]

The examples are now generated from the schema, although they are still incomplete

[I-SRV]

The use of the DNS SRV record for location of XKMS services is described

[I-LocateValidate]

The distinction between locate and validate is clarified.

[I-Tranclusion]

The schema fragments and examples are now incorporated automatically from the relevant source files to ensure compatibility.

[I-Status]

Removed keybinding status, this may prevent query or reasons for revocation

[I-9-Duration]

Reworded the versioning to use omitted in place of unspecified

[I-10-ReasonRevocation]

Changed wording.

[I-11-Amiguity]

Made edits to restrict use of term assertion.

[I-13-NoMatch-Failure]

Added text to clarify difference between nomatch and failure.

[I-17-KeyInfoKeybinding]

Locate now uses keybinding.

[I-Enveloping]

The message signature is in enveloped mode, not enveloping as incorrectly stated

F.4 Issues Addressed in Previous Drafts

[I-PayloadAuth]

Require decision on how payload authentication is to be handled, in particular whether by a SOAP header or a signature within the Request packet.

[I-RespondWith]

Need to decide on the format of the identifiers here, I am still unsure as to what QNames do. In particular note that there are three types of query that return <X509Data>; X509Cert, X509Chain and OCSP.

[I-FaultHandling]

We need to address this, how is XP getting on here?

[I-KeyID]

I forget can we delete this now?

[I-Pending]

We were going to include some way of dealing with a Pending response (only makes sense to consider for <Register> or <ReIssue>). 

[I-MultipleResponseLimit]

I believe we were going to allow the client to set a limit on the number of "Multiple" responses that might be returned. The server would have to indicate whether there were more responses that were not sent because the limit would have been exceeded.

[I-Reason]

Connect up the Reason code to Result Code, possibly introduce Qnames here.