Figure 1: Substitution of the <ds:KeyInfo> element as a message is passed amongst processors
Figure 2: Tier 0 Protocol allows a <ds:Keyinfo> element to reference external data
Figure 3: Tier 1 Protocol Provides Name Resolution Service
Figure 4: Tier2 Protocol Provides Key Validation Service
Figure 5: Registration of a KeyBinding

Executive Summary

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

The X-KISS specification defines a protocol for a Trust service that resolves public key information contained in XML-SIGelements. 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.

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.

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

1.1 Overview

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

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

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

Design criteria include:

Compatibility with the XML Signature Specification (currently a standards proposal to the W3C and IETF) and with an anticipated specification on XML Encryption. However, its use is not restricted to these grammars.
Implementation should be as simple as possible using standard XML tools while remaining consistent with the entirety of relevant specifications; the only cryptographic functions required by an application are those needed to support XML Signature or Encryption;
Implementation should not require ASN.1 tools;
Management of status information (e.g. "revocation") is transparent to a public-key using application in an online environment;
Minimize client code and configuration complexity through use of standard protocols and message grammars and also by delegating tasks that may require complex configuration to web services.

To meet these design criteria, the specifications in this family are layered, separating the protocol semantics from the implementation syntax.

The message syntax presented in this document is based on XML and is designed to allow use of the Simple Object Access Protocol (SOAP) and the Web Service Definition Language (WSDL) specifications. From these, it is possible to generate APIs in common programming languages such as the C family of programming languages.

It is also possible to express the messages in syntax other than XML, over protocols other than SOAP and through a definition language other than WSDL, though such expression is outside the scope of this specification except to note that SOAP and WSDL are proposals currently or potentially considered by the World Wide Web Consortium XML Protocol Activity. If XML and SOAP are not adopted by this Activity, we anticipate that the protocol would be expressible in any specification recommended by the Activity.

1.2 Definition of Terms

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

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

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

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

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.

All XMKMS protocol elements are defined using XML schema [XML-Schema1][XML-Schema2]. For clarity unqualified elements in schema definitions are in the XML schema namespace:

xmlns="http://www.w3.org/2000/10/XMLSchema"

References to XML Key Management Specification schema defined herein use the prefix "xkms" and are in the namespace:

xmlns:xkms="http://www.xkms.org/schema/xkms-2001-01-20"

This namespace is also used for unqualified elements in message protocol examples.

The XKMS schema specification uses the elements already defined in the XML Signature namespace. The "XML Signature namespace" is represented by the prefix ds and is declared as:

xmlns:ds="http://www.w3.org/2000/09/xmldsig#"

The "XML Signature schema" is defined in [XML-SIG-XSD] and the <ds:KeyInfo> element (and all of its contents) are defined in [XML-SIG §4.4].

1.4 Key Information Service Specification

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.

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.

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.

In the case of an encryption operation:

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

1.5 Key Registration Service Specification

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.

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.

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.

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 Tiered Service Model

Different applications require different levels of PKI service. To support this need a tiered implementation model is defined in which applications may select the precise level of processing that meets their requirements.

Tier 0 Processing of the <ds:RetrievalMethod> element of the <ds:KeyInfo> element is by the application. Processing is as defined by the XML Signature specification [XML-SIG §4.4.3] and without assistance of a trust service.

Tier 1 Processing of the <ds:KeyInfo> element by the application is delegated to a service. The service returns a <ds:KeyInfo> element that describes a public key meeting the criteria specified by the client application. Validation of the <ds:KeyInfo> is performed by the client.

Tier 2 Validation Service
As in tier 1, but in addition, the service reports further information concerning the data specified in a <ds:KeyInfo> block.

Additional tiers could be defined in separate documents

Tier 3 Assertion Service
Establishment and management of long term trust relationships.

Tier 4 Assertion Status Service
Management of the status of assertions.

In each case, the trust service shields the client application from the complexities of the underlying PKI such as:

Handling of complex syntax and semantics (e.g. X.509v3).
Retrieval of information from directory and data repository infrastructure.
Revocation status verification.
Construction and processing of trust chains.

1.7 Structure of this document

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

Section 2: X-KISS Protocol Overview.
The functional behavior of the X-KISS protocol is described.

Section 3: X-KISS Message Set.
The semantics of the X-KISS protocol messages are defined.

Section 4: X-KRSS Protocol Overview.
The functional behavior of the X-KRSS protocol is described.

Section 5: X-KRSS Message Set.
The semantics of the X-KRSS protocol messages is defined.

Section 6: Cryptographic Algorithm support
Data formats to support use of the cryptographic algorithms RSA and DSA are defined.

2 Key Information Service Protocol Overview

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.

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.

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 1below).

Substitution of the <ds:KeyInfo> element as a message is passed amongst processors.

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

2.1 Tier 0: <ds:RetrievalMethod> Processing

A <ds:KeyInfo> element may include a <ds:RetrievalMethod> element which is a means to convey information available from a remote location. The <ds:RetrievalMethod> element is a feature of and is defined by the XML Signature Specification. Since it is the most basic means of resolving a <ds:KeyInfo> element it is described here as the 'Tier 0' Key Information service.

For example, the signer of a document may wish to refer verifiers to a chain of X.509 certificates without having to attach them. <ds:RetrievalMethod> consists of a location which in this case, would refer to a location on the web from which the certificate chain may be retrieved, a method, and a type.

The XML Signature Specification defines the <ds:Keyinfo> <ds:RetrievalMethod> as follows:

A RetrievalMethod element within Keyinfo is used to convey a reference to Keyinfo information that is stored at another location. For example, several signatures in a document might use a key verified by an X.509v3 certificate chain appearing once in the document or remotely outside the document; each signature's Keyinfo can reference this chain using a single ds:RetrievalMethod element instead of including the entire chain with a sequence of X509Certificate elements.

RetrievalMethod uses the same syntax and dereferencing behavior as Reference's URI (section 4.3.3.1 [of [XML-SIG]]) and The Reference Processing Model (section 4.3.3.2 [of [XML-SIG]]) except that there is no DigestMethod or DigestValue child elements and presence of the URI is mandatory. Note, if the result of dereferencing and transforming the specified URI is a node set, then it may need to be to be canonicalized. All of the KeyInfo types defined by this specification (section 4.4 [of [XML-SIG]]) represent octets, consequently the Signature application is expected to attempt to canonicalize the nodeset via the The Reference Processing Model (section 4.3.3.2 [of [XML-SIG]])

Schema Definition:

<element name="RetrievalMethod">
   <complexType>
      <sequence>
         <element ref="ds:Transforms" minOccurs="0"/>
      </sequence>
      <attribute name="URI" type="uriReference"/>
      <attribute name="Type" type="uriReference" use="optional"/>
   </complexType>
</element>

In the following example, the signer indicates a web-resident directory service (www.PkeyDir.test) where they have published information about their public key.

<ds:KeyInfo>
<ds:RetrievalMethod URI="http://www.PKeyDir.test/CheckKey"

Type="http://www.w3.org/2000/09/xmldsig#X509Certificate"/>
</ds:KeyInfo>

The relying party retrieves the additional Key Information by resolving the specified URL (Figure 2).

Tier 0 Protocol allows a <ds:Keyinfo> element to reference external data

Figure 2: Tier 0 Protocol allows a <ds:Keyinfo> element to reference external data

2.2 Tier 1 Locate Service

The Tier 1 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.

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 3) or act as a gateway to an underlying PKI based on a non-XML syntax.

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

Figure 3: Tier 1 Protocol Provides Name Resolution Service

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.

2.2.1 Example: Document Signature

The client receives a signed XML document. The <ds:Keyinfo> element specifies a <ds:RetrievalMethod> for an X.509 certificate that contains the public key. The client sends the <ds:Keyinfo> element to the location service requesting that the <KeyName> and <KeyValue> elements be returned.

Request:

<Query>

<ds:KeyInfo>

<ds:RetrievalMethod

URI="http://www.PKeyDir.test/Certificates/01293122"

Type="http://www.w3.org/2000/09/xmldsig#X509Data"/>

</ds:KeyInfo>

</Query>

<string>KeyName</string>

<string>KeyValue</string>

</Respond>

</Locate>

The location service resolves the <ds:RetrievalMethod>, obtaining an X.509v3 certificate. The certificate is parsed to obtain the public key value that is returned to the client.

The location service DOES NOT report the revocation status or the trustworthiness of the certificate. The <KeyName> returned is obtained from the certificate.

Response:

<Result>Success</Result>

<ds:KeyInfo>

<ds:KeyName>O=XMLTrustCernter.org OU="Crypto"

CN="Alice"</ds:KeyName>

<ds:KeyValue>...</ds:KeyValue>

</ds:KeyInfo>

</Answer>

</LocateResult>

(For readability, the contents of the <KeyValue>element are omitted from the example above. Full examples are shown in appendices. )

2.2.2 Example: Data Encryption

The client is attempting to send an encrypted XML document and requires the public key encryption parameters of the recipient.

Request:

<Query>

<ds:KeyInfo>

<ds:KeyName>Alice Cryptographer</ds:KeyName>

</ds:KeyInfo>

</Query>

<string>KeyName</string>

<string>KeyValue</string>

</Respond>

</Locate>

Response:

<Result>Success</Result>

<ds:KeyInfo>

<ds:KeyName>Alice Cryptographer</ds:KeyName>

<ds:KeyValue>...</ds:KeyValue>

</ds:KeyInfo>

</Answer>

</LocateResult>

2.3 Tier 2: Validate Service

The Tier 2 Validate Service allows all that tier one 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 4).

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

Figure 4: Tier2 Protocol Provides Key Validation Service

2.3.1 Example: Document Signature

The client of the example in section 2.2.1 has verified the document signature. The client now needs to determine whether the binding between the name and the public key is both trustworthy and valid.

Request:

<Query>

<Status>Valid</Status>

<ds:KeyInfo>

<ds:KeyName>...</ds:KeyName>

<ds:KeyValue>...</ds:KeyValue>

</ds:KeyInfo>

</Query>

<string>KeyName</string>

<string>KeyValue</string>

</Respond>

</Validate>

Response:

<Result>Success</Result>

<Status>Valid</Status>

<KeyID>http://www.xmltrustcenter.org/assert/20010120-39</KeyID>

<ds:KeyInfo>

<ds:KeyName>...</ds:KeyName>

<ds:KeyValue>...</ds:KeyValue>

</ds:KeyInfo>

</ValidityInterval>

</KeyBinding>

</Answer>

</ValidateResult>

2.4 Validity of the Service Response

Clients SHOULD ensure that the response from the service to a Locate or Validate operation is valid, meaning that the following criteria are met.

Authenticity: That the response message was issued by a trusted Trust service

Integrity: That the response message has not been modified

Correspondence: The response from the Trust service corresponds to the request that was made to the client.

The appropriate means of validating the service response is dependent on the application. It is not necessary for the requests to be authenticated with a digital signature if the client supports some other secure means of communicating with the Trust service.

The authenticity, integrity and correspondence of the response SHOULD be ensured using one or more of the following methods:

Authenticating the response messages using the XML Signature Specification.
Transport layer security (e.g. SSL, TLS, WTLS)
Packet layer security (e.g. IPSEC)

In the case that signed response messages are employed, 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 mechanisms described in the Tier 3 Trust Assertion Service Specification.
A signing key obtained using some other retrieval mechanism such as DNSSEC, PKIX or SPKI.

3 Key Information Service Message Set

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.

3.1 Common Data Elements

The content and format of messages are defined using the W3C XML Schema specification [XML-Schema1][XML-Schema2]. All values are encoded as element data. The XKMS specification itself uses only a restricted set of types, but element values may potentially use any type definable within XML Schemas. XKMS is compatible with the object serialization format defined within SOAP (see Appendix A ) but does not use some aspects of that format. In particular, sequences of elements are expressed as sequences of elements without reference to the SOAP array encoding.

The following common data elements are used in the message set:

3.1.1<ds:Keyinfo>

The <ds:Keyinfo> element is defined in the XML Signature Specification schema and that specification governs its format and use.

The <ds:Keyinfo> element communicates data using both attributes and elements. Arbitrary extension elements are permitted.

3.1.2ResultCode

The enumerated type ResultCode is used to return result codes from each interface. It has the following possible values:

Success
The operation succeeded.

NoMatch
No match was found for the search prototype provided.

Incomplete
Only part of the information requested could be provided.

Failure
The operation failed for unspecified reasons.

Refused
The operation was refused.

Pending
The operation was queued for future processing.

ResultCode is defined by the following schema:

</restriction>

</simpleType>

3.1.3 AssertionStatus

The enumerated type AssertionStatus is used to report the status of an assertion such as a key binding. The following values are defined:

Valid
The binding is definitively valid.

Invalid
The binding is definitively invalid.

Indeterminate
The status of the assertion cannot be determined.

The AssertionStatus type is defined by the following schema:

</simpleType>

The <status> element of the <KeyBinding> element has the type AssertionStatus.

3.1.4 <Reason>

One or more strings that specify the reason(s) for a particular assertion status.

If the Trust service returns the AssertionStatus value Valid, the <Reason> element lists 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.

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

Aspect	Description	X.509 Equivalent
IssuerTrust	The assertion issuer is considered to be trustworthy by the Trust service.	Certificate path anchored by trusted root successfully constructed
Status	The Trust service has affirmatively verified the status of the assertion with an authoritative source	Certificate status validated using CRL or OCSP
ValidityInterval	The request was made within the validity interval of the assertion	The request was made at a time when the certificate chain was valid
Signature	Signature on signed data provided by the client in the <ds:Keyinfo> element (e.g. X509Data element) was successfully verified.	Certificate Signature verified

3.1.5 <Respond>

The <Respond> 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].

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.

Defined identifiers include:

Identifier	<ds:Keyinfo> Element	Description
KeyName	<ds:KeyName>	Key Name
KeyValue	<ds:KeyValue>	Public key parameters
X509Cert	<ds:X509Data>	X509 Certificate v3 that authenticates the specified key
X509Chain	<ds:X509Data>*	X509 Certificate v3 chain that authenticates the specified key
X509CRL	<ds:X509Data>	X509 Certificate Revocation List v2
OCSP	<ds:X509Data>	PKIX OCSP token that validates an X509v3 certificate that authenticates the key
RetrievalMethod	<ds:RetrievalMethod>	Retrieval Method data
MgmtData	<ds:MgmtData>	Management Data
PGP	<ds:PGPData>	PGP key signing data
PGPWeb	<ds:PGPData>*	Collection of PGP key signing data
SPKI	<ds:SPKIData>*	SPKI key signing
Multiple		Specifies that the Trust Service SHOULD return multiple answers to the client if more than one valid answer is available.
Private		Request that the encrypted private key be returned in the response. [Used in the X-KRSS protocol]

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

The <Respond> element is defined by the following schema:

<element name="string" type="string"

minOccurs="0" maxOccurs="unbounded"/>

</sequence>

</complexType>

</element>

3.2 Locate Service

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.

3.2.1 Request Message

The request message consists of the Locate element defined by the following schema:

<element name="string" type="string"

minOccurs="0" maxOccurs="unbounded"/>

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</element>

The following elements are defined:

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

Respond
A sequence of identifiers that specify data elements that the client requests returned in the response.

3.2.2 Response Message

The Response Message consists of a <LocateResult> element defined by the following schema:

<all>

<element name="ds:KeyInfo" type="ds:KeyInfo"

minOccurs="0" maxOccurs="unbounded"/>

</all>

</complexType>

</element>

</sequence>

</complexType>

</element>

The following elements are defined:

Answer
A sequence of strings that contain <ds:Keyinfo> elements that provide the information specified by the Respond attribute, for the public key identified by the Query element.

The response message returns a ResultCode depending on the success of the Locate operation as follows:

ResultCode	Number of Elements	Description
Success	At least one element	The locate operation succeeded. All the information requested was available.
NoMatch	No elements	The locate operation succeeded but returned no matches.
Incomplete	At least one element	The locate operation succeeded. Some of the information requested was not available.
Failure	No elements	The locate operation failed.

3.2.3 Faults

When the protocol is expressed in SOAP, all ResultCode values other than Success, Incomplete and NoMatch are expressed using the SOAP Fault element with a <faultcode> of soap:Server. See the [SOAP] specification for further details. The service MAY return the descriptive text set out in section 3.2.2 above.

The format of the contents returned by the service within the detail element is left as an implementation decision. The following example shows a SOAP fault reporting that a Locate operation failed:

<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"

xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/1999/XMLSchema">

<soap:Body>

       <soap:Fault>
           <faultcode>soap:Server</faultcode>
           <faultstring>The locate operation failed.</faultstring>
           <detail>
           </detail>
       </soap:Fault>

</soap:Body>

</soap:Envelope>

3.3 Validate Service

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.

3.3.1 <ValidityInterval>

The <ValidityInterval> element specifies limits on the validity of the assertion. It is defined by the following schema:

</sequence>

</complexType>

Member	Type	Description
NotBefore	timeInstant	Time instant at which the validity interval begins
NotAfter	timeInstant	Time instant at which the validity interval has ended

All timeInstant MUST fully specify the date.

The <NotBefore> and <NotAfter> elements are optional. If the value is omitted it is unspecified. If the <NotBefore> element is unspecified the assertion is valid on any date up to but excluding the date specified in the <NotAfter> element. If the <NotAfter> element is unspecified the assertion is valid from the <NotBefore> element with no expiry. If neither element is specified the assertion is valid at any time.

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

Implementations MUST NOT generate time instances that specify leap seconds.

For purposes of comparison, the time interval <NotBefore> to <NotAfter> 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 <NotAfter>

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.

3.3.2 <KeyId>

The <KeyId> element specifies a URI identifier for the key. The URI MAY be a name (URN), a locator (URL) or anything else permitted by the URI specification. The <KeyId> element is distinct from the <ds:KeyName> element of <ds:Keyinfo> in that the <KeyName> element is not required to be a URI.

When the <KeyId> element in a <KeyBinding> specifies a URL a binding is asserted to the specified address and protocol. For example if the URL specifies an email address it is asserted that the specified key MAY be used by a security enhancement. Similarly a <KeyId> contained in a <Prototype> or <Query> specifies an intention to use the specified key with the protocol indicated.

The following table shows the correspondence between commonly used URL prefixes and security bindings:

Method	Security Enhancement
https://host/data	SSL / TLS. Key is bound to the host name host.
mailto://user@host	S/MIME email security, Key is bound to the username user@host

The <KeyId> element is defined by the following schema:

3.3.3 <KeyUsage>

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

</simpleType>

<all>

<element name="string" type="xkms:KeyUsageValue"

minOccurs="0" maxOccurs="unbounded"/>

</all>

</complexType>

</element>

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.

The following identifiers are defined:

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

3.3.4 <ProcessInfo>

The <ProcessInfo> element MAY be used to specify processing information associated with a key binding that end clients SHOULD treat as opaque data. The element is defined by the following schema:

3.3.5 <PassPhrase>

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

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.

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.

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

3.3.6 <KeyBinding>, <Query>, <Prototype>

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.

The <Query> and <Prototype> elements share the same type definition as <KeyBinding> which is defined by the following schema:

<element name="KeyUsage" type="xkms:KeyUsage"

minOccurs="0" maxOccurs="unbounded"/>

<s:element name="KeyUsage">

<s:complexType>

<s:all>

<s:element name="string" type="s:string" minOccurs="0" maxOccurs="unbounded"/>

</s:all>

</s:complexType>

</s:element>

</sequence>

</complexType>

3.3.7 Request Message

The request message consists of the <Validate> element defined by the following schema:

<all>

<all>

<element name="string" type="s:string"

minOccurs="0" maxOccurs="unbounded"/>

</all>

</complexType>

</element>

</all>

</complexType>

</element>

The following elements are defined:

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

Respond
A sequence of identifiers that specify data elements that the client requests be returned in the response.

3.3.8 Response Message

The Response Message consists of a <ValidateResult> element defined by the following schema:

<all>

<element name="KeyBinding" type="xkms:KeyBinding"

minOccurs="0" maxOccurs="unbounded"/>

</sequence>

</complexType>

</element>

</all>

</complexType>

</element>

The following elements are defined:

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

The response message returns a <ResultCode> depending on the success of the Validate operation as follows:

ResultCode	Number of Elements	Description
Success	At least one element	The validate operation succeeded. all the information requested was available.
NoMatch	No elements	The validate operation succeeded but returned no matches.
Incomplete	At least one element	The validate operation succeeded. Some of the information requested was not available.
Failure	No elements	The validate operation failed.

Note that the Validate operation returns the <ResultCode>Success even if the <KeyBinding> assertion was found to be Invalid or Indeterminate. The <ResultCode> reflects the success or failure of the service query and not the information returned by that query.

3.3.9 Faults

When the protocol is expressed in SOAP, all <ResultCode> values other than Success, Incomplete and NoMatch are expressed using the SOAP Fault element with a faultcode of soap:Server. See the [SOAP] specification for further details. The service MAY return the descriptive text set out in section 3.3.8 above.

4 Key Registration Service Protocol Overview

The XML Key Registration Service Specification permits management of information that is bound to a public key pair.

The service specification supports the following operation:

Register
Information is bound to a public key pair through a XKMS <KeyBinding> element. Generation of the public key pair by either the client or the server is supported.

The Register request 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.

4.1 Linkage to an Underlying PKI

Linkage to such an underlying PKI is considered to be an intrinsic property of the Registration Service rather than a parameter that the client application may negotiate. To be useful such a negotiation service would need to express more than the syntax of the credentials issued.

If necessary, Registration Services may offer links to multiple underlying PKIs through separate service address URIs. For example:

http://register.xmltrustcenter.org/pgp
Obtain a PGP credential

http://register.xmltrustcenter.org/x509/public_class2
Obtain an X.509v3 credential in the "Trust Center Public Class 2" hierarchy

http://register.xmltrustcenter.org/private/AKEHJQ
Obtain an X.509v3 credential in a private hierarchy, the details of which the client application does not understand

The <ds:Keyinfo> elements <ds:X509Data>, <ds:PGPData> and <ds:SPKIData> MAY be used to return credentials issued in an underlying PKI. Alternatively the client may request that a <ds:RetrievalMethod> element be returned in the response to allow retrieval of the credential to be generated (e.g. an X.509v3 certificate).

4.2 Registration

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.

The Registration request message consists of 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.

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

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.

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

Diagram shows the data passed from the client to the server for registration

Figure 5: Registration of a KeyBinding

4.2.1 Example: Registration of Client-Generated Key Pair

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.

The X-KRSS request message consists of the following <Register> element:

<Status>Valid</Status>

<KeyID>mailto:Alice@cryptographer.test</KeyID>

<ds:KeyInfo>

<ds:KeyValue>

<ds:RSAKeyValue>

<ds:Modulus>

998/T2PUN8HQlnhf9YIKdMHHGM7HkJwA56UD0a1oYq7E

fdxSXAidruAszNqBoOqfarJIsfcVKLob1hGnQ/l6xw

</ds:Modulus>

<ds:Exponent>AQAB</ds:Exponent>

</ds:RSAKeyValue>

</ds:KeyValue>

<ds:KeyName>mailto:Alice@cryptographer.test</ds:KeyName>

</ds:KeyInfo>

</Prototype>

<ds:Signature URI="#keybinding"

[RSA-Sign (KeyBinding, Private)] />

</ProofOfPossession>

<ds:Signature URI="#keybinding"

[HMAC-SHA1 (KeyBinding, Auth)] />

</KeyBindingAuth>

</AuthUserInfo>

</AuthInfo>

<string>KeyName<string>

<string>KeyValue</string>

<string>RetrievalMethod</string>

</Respond>

</Register>

Where:

Auth = HMAC-SHA1 ("024837", 0x1)
Pass = HMAC-SHA1 (HMAC-SHA1 ("helpihaverevealedmykey", 0x2), 0x3)

For clarity, the details of the signature elements are omitted. In each case the signature scope is the <KeyBinding> element and the signature scope is specified by reference. The MAC function used in this case is HMAC-SHA1 as defined in [RFC-2104]. The notation f(m, k) is used to indicate the message m signed under the key k. Further details are provided in section 6.1 .

The service accepts the registration and returns the following response:

<Result>Success</Result>

<Status>Valid</Status>

<KeyID>mailto:Alice@cryptographer.test</KeyID>

<ds:KeyInfo>

<ds:RetrievalMethod

URI="http://www.PKeyDir.test/Certificates/01293122"

Type="http://www.w3.org/2000/09/xmldsig#X509Data"/>

<ds:KeyValue>

<ds:RSAKeyValue>

<ds:Modulus>998/T2PUN8HQlnhf9YIKdMHHGM7HkJwA56UD0a1oYq7Ef

dxSXAidruAszNqBoOqfarJIsfcVKLob1hGnQ/l6xw</ds:Modulus>

<ds:Exponent>AQAB</ds:Exponent>

</ds:RSAKeyValue>

</ds:KeyValue>

<ds:KeyName>mailto:Alice@cryptographer.test</ds:KeyName>

</ds:KeyInfo>

</Answer>

</RegisterResult>

4.2.2 Example: Registration of Service-Generated Key Pair

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.

<Status>Valid</Status>

<KeyID>mailto:Alice@cryptographer.test</KeyID>

<ds:KeyInfo>

<ds:KeyName>mailto:Alice@cryptographer.test</ds:KeyName>

</ds:KeyInfo>

</KeyInfo>

</Prototype>

<ds:Signature URI="#keybinding"

[HMAC-SHA1 (Prototype, Auth)] />

</KeyBindingAuth>

</AuthServerInfo>

</AuthInfo>

<string>KeyName</string>

<string>KeyValue</string>

<string>Private</string>

</Respond>

</Register>

Where

Auth = HMAC-SHA1 ("024837", 0x1)
Pass = HMAC-SHA1 (HMAC-SHA1 ("helpihaverevealedmykey", 0x2), 0x3)

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

<Result>Success</Result>

<Status>Valid</Status>

<KeyID>mailto:Alice@cryptographer.test</KeyID>

<ds:KeyInfo>

<ds:KeyValue>

<ds:RSAKeyValue>

<ds:Modulus>998/T2PUN8HQlnhf9YIKdMHHGM7HkJwA56UD0a1oY

q7EfdxSXAidruAszNqBoOqfarJIsfcVKLob1hGnQ/l6xw

</ds:Modulus>

<ds:Exponent>AQAB</ds:Exponent>

</ds:RSAKeyValue>

</ds:KeyValue>

<ds:KeyName>mailto:Alice@cryptographer.test</ds:KeyName>

</ds:KeyInfo>

</Answer>

<Private> Base64 ( 3DES ( RSAPrivate, Enc)) </Private>

</RegisterResult>

Where:

Enc = HMAC-SHA1 ("024837", 0x4)
RSAPrivate =

<ds:Modulus>998/T2PUN8HQlnhf9YIKdMHHGM7HkJwA56UD0a1oYq7EfdxSXAidr

uAszNqBoOqfarJIsfcVKLob1hGnQ/l6xw </ds:Modulus>

<PrivateExponent>whatever</PrivateExponent>

<P>whatever</P>

<Q>whatever</Q>

</RSAKeyPair>

4.3 Revocation

A Registration service MAY permit clients to revoke previously issued assertions. A revocation request is made in the same manner as the initial registration of a key except that:

· The status of the KeyBinding or KeyAssertion prototype is Invalid.

· If the Registration service has no record of the assertion the result code NotFound is returned.

4.3.1 Example: Revocation

For some reason Alice requests the Registration Service revoke the binding for her public key. Alice authenticates herself using by signing her request with the corresponding private key. Alice could have used the pass phrase she established during registration instead.

The request message is:

<Status>Invalid</Status>

<KeyID>mailto:Alice@cryptographer.test</KeyId>

<ds:KeyInfo>

<ds:KeyValue>

<ds:RSAKeyValue>

<ds:Modulus>998/T2PUN8HQlnhf9YIKdMHHGM7HkJwA56UD0a1oYq7E

fdxSXAidruAszNqBoOqfarJIsfcVKLob1hGnQ/l6xw</ds:Modulus>

<ds:Exponent>AQAB</ds:Exponent>

</ds:RSAKeyValue>

</ds:KeyValue>

<ds:KeyName>mailto:Alice@cryptographer.test</ds:KeyName>

</ds:KeyInfo>

</Prototype>

<ds:Signature URI="#keybinding"

[RSA-Sign (KeyBinding, Private)] />

</ProofOfPossession>

</AuthUserInfo>

</AuthInfo>

<string>KeyName</string>

<string>KeyValue</string>

</Respond>

</Register>

The service responds that the key binding has been revoked:

<Result>Success</Result>

<Status>Invalid</Status>

<KeyID>mailto:Alice@cryptographer.test</KeyID>

<ds:KeyInfo>

<ds:KeyValue>

<ds:RSAKeyValue>

<ds:Modulus>998/T2PUN8HQlnhf9YIKdMHHGM7HkJwA56UD0a1oYq7E

fdxSXAidruAszNqBoOqfarJIsfcVKLob1hGnQ/l6xw</ds:Modulus>

<ds:Exponent>AQAB</ds:Exponent>

</ds:RSAKeyValue>

</ds:KeyValue>

<ds:KeyName>mailto:Alice@cryptographer.test</ds:KeyName>

</ds:KeyInfo>

</Answer>

</RegisterResult>

4.4 Key Recovery

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.

4.4.1 Example: Key Recovery

Alice has forgotten the private key she registered earlier. She 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 Alice (using an out of band method) the key recovery authorization code "A8C8S H93HU C9H29 8Y43U H9J3 I23". 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.

The request parameters for the key recovery are:

<Status>Indeterminate</Status>

<KeyID>mailto:Alice@cryptographer.test</KeyId>

<ds:KeyInfo>

<ds:KeyName>mailto:Alice@cryptographer.test</ds:KeyName>

</ds:KeyInfo>

</Prototype>

</AuthInfo>

<string>KeyName</string>

<string>KeyValue</string>

<string>Private</string>

</Respond>

</Register>

Where

Auth = HMAC-SHA1 ("a8c8sh93huc9h298y43uh9j3i23", 0x1)

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:

<Status>Invalid</Status>

<KeyID>mailto:Alice@cryptographer.test</KeyID>

<ds:KeyInfo>

<ds:KeyValue>

<ds:RSAKeyValue>

<ds:Modulus>998/T2PUN8HQlnhf9YIKdMHHGM7HkJwA56UD0a1oYq7E

fdxSXAidruAszNqBoOqfarJIsfcVKLob1hGnQ/l6xw</ds:Modulus>

<ds:Exponent>AQAB</ds:Exponent>

</ds:RSAKeyValue>

</ds:KeyValue>

<ds:KeyName>mailto:Alice@cryptographer.test</ds:KeyName>

</ds:KeyInfo>

</Answer>

<Private> Base64 ( 3DES ( RSAPrivate, Enc)) </Private>

</RegisterResult>

Where:

Enc = HMAC-SHA1 ("a8c8sh93huc9h298y43uh9j3i23", 0x4)
RSAPrivate = "

<ds:Modulus>998/T2PUN8HQlnhf9YIKdMHHGM7HkJwA56UD0a1oYq7EfdxSXAidr

uAszNqBoOqfarJIsfcVKLob1hGnQ/l6xw</ds:Modulus>

<PrivateExponent>whatever</PrivateExponent>

<P>whatever</P>

<Q>whatever</Q>

</RSAKeyPair>"

4.5 Request Authentication

The Service SHOULD ensure that all requests are valid.

Authenticity: The request message originated from the specified party.

Integrity: The request message has not been modified.

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.

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.

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.

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.

5 Key Registration Service Message Set

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.

5.1 Registration

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

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.

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.

5.1.1 <AuthInfo>

The <AuthInfo> element contains data that authenticates the request. The form of the authentication data depends upon:

· The means of authentication used;

· The public key algorithm used; and

· The party that generates the key pair (client or service).

The information MAY include a proof of possession for a public key that is registered and MAY include information that authenticates the request through a cryptographic binding to the Prototype element.

If the private key is generated by the user the <AuthInfo> element contains an <AuthUserInfo> element. If the private key is generated by the Trust Service the <AuthInfo> element contains an <AuthServerInfo> element as described in the following schema:

</choice>

</complexType>

</element>

The <AuthUserInfo> and <AuthServerInfo> elements are defined in section 6 below.

5.1.2 Request Message

The request message consists of the Register element defined by the following schema:

</choice>

</complexType>

</element>

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</element>

The following elements are defined:

Prototype
A single KeyBinding structure that specifies elements that the client requests be registered.

AuthInfo
An XML document node that provides information that authenticates the request.

Respond
A sequence of identifiers that specify data elements that the client requests be returned in the response.

5.1.3 Response Message

The Response Message consists of a RegisterResult element defined by the following schema:

<all>

<element name="KeyBinding" type="xkms:KeyBinding"

minOccurs="0" maxOccurs="unbounded"/>

</all>

</complexType>

</element>

</sequence>

</complexType>

</element>

The following elements are defined:

KeyBinding
If present specifies the key binding that was registered by the service

Private
Additional information provided by the server that MAY provide values for private key parameters generated by the Registration Service

Both the KeyBinding and the Private data elements are optional.

5.1.4 Faults

When the protocol is expressed in SOAP, all ResultCode values other than Success, Incomplete and NoMatch are expressed using the SOAP Fault element with a faultcode of soap:Server. See the [SOAP] specification for further details. The service MAY return the descriptive text set out in section 3.2.2 above.

6 Cryptographic Algorithm Specific Parameters

6.1 Use of Limited-Use Shared Secret Data

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.

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.

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

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:

Value	Application
0x1	Authentication
0x2	Encoding of Pass Phrase - Pass 1
0x3	Encoding of Pass Phrase - Pass 2
0x4	Encryption of private key data

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.

If the output of the MAC function provides less keying material than is required the first MAC output value is used to supply the least significant 160 bits of keying material. A second MAC output value is then obtained by applying the MAC function to the shared 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.

6.1.1 <PassPhraseAuth>

The <PassPhraseAuth> element contains a plaintext limited use shared secret that is used to authenticate the request.

The <PassPhraseAuth> element is defined by the following schema:

<element name="PassPhraseAuth" type="string"

minOccurs="0"/>

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. See section 7.3 below for more details.

6.1.2 <KeyBindingAuth>

The <KeyBindingAuth> 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.

The <KeyBindingAuth> element is defined by the following schema:

</sequence>

</complexType>

</element>

6.1.3 <ProofOfPossession>

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.

The <ProofOfPossession> element is defined by the following schema:

</sequence>

</complexType>

</element>

6.2 Registration of User-Generated RSA or DSA Keys

If an RSA or DSA key pair generated by the user is to be registered, the registration service MAY be required by its registration policy to ensure that:

· The party that made the request has possession of the specified private key

· The party that made the request is authorized to assert the specified binding to a public key.

The <AuthUserInfoType> element type has the following schema definition:

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</element>

<element name="PassPhraseAuth" type="string"

minOccurs="0"/>

</sequence>

</complexType>

6.3 Registration of Service-Generated RSA Keys

If the RSA key pair is generated by the registration service the registration MAY be required by its registration policy to ensure that:

· The party that made the request is authorized to assert the specified binding to a public key.

In addition the Registration Service MUST communicate the private key parameters to the user. The Registration Service SHOULD ensure that the confidentiality of the private key is protected.

The <AuthServerInfo> element is used for this request as defined by the following schema:

</sequence>

</complexType>

</element>

<element name="PassPhraseAuth" type="string"

minOccurs="0"/>

</complexType>

Registration of service-generated DSA keys is not supported. A DSA key can only be used for signature. Key recovery of signature keys has only limited application. The principal reason to perform server generation of key pairs is to support Key Recovery.

6.3.1 Encoding of RSA Private Key Parameters

The service MAY return the RSA public and private key parameters to the client.

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.

The XML schema for this structure is:

<all>

<element name='Modulus' type='ds:CryptoBinary'

minOccurs='1' maxOccurs='1'/>

<element name='PublicExponent' type='ds:CryptoBinary'

minOccurs='1' maxOccurs='1'/>

<element name='PrivateExponent' type='ds:CryptoBinary'

minOccurs='1' maxOccurs='1'/>

<element name='P' type='ds:CryptoBinary'

minOccurs='0' maxOccurs='1'/>

<element name='Q' type='ds:CryptoBinary'

minOccurs='0' maxOccurs='1'/>

<element name='DP' type='ds:CryptoBinary'

minOccurs='0' maxOccurs='1'/>

<element name='DQ' type='ds:CryptoBinary'

minOccurs='0' maxOccurs='1'/>

<element name='QINV' type='ds:CryptoBinary'

minOccurs='0' maxOccurs='1'/>

</all>

</complexType>

</element>

6.3.2 Encryption of Private Key Parameters

The use of the XML Encryption standard for this purpose is anticipated.

Until the XML Encryption standard is available, the following syntax MAY be used to wrap the private key:

<all>

<element name='KeyAlg' type='ds:String'

minOccurs='1' maxOccurs='1'/>

<element name='EncryptionAlg' type='ds:String'

minOccurs='1' maxOccurs='1'/>

<element name='IV' type='ds:CryptoBinary'

minOccurs='1' maxOccurs='1'/>

<element name='EncryptedData' type='ds:CryptoBinary'

minOccurs='1' maxOccurs='1'/>

</all>

</complexType>

</element>

Where the elements have the following meaning:

ID	Type	Description
KeyAlg	String	Means of deriving the encryption key from the shared authentication parameter. Possible value HMAC-SHA1
EncryptionAlg	String	Symmetric cipher algorithm. Possible values to include 3DES-CBC, AES
IV	CryptoBinary	Initialization vector for the symmetric cipher
EncryptedData	CryptoBinary	The encrypted data itself

7 Security Considerations

Implementations SHOULD consider the following security issues.

7.1 Replay Attacks

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

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.

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

Freshness tokens MAY be encoded as XML Signature Properties.

7.2 Denial of Service

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.

7.3 Recovery Policy

Key recovery policy is left as an implementation decision.

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.

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.

7.4 Security of Limited Use Shared Secret

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.

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

8 Acknowledgments

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 Web Service Contract

This appendix describes specific instructions for use of the SOAP binding. Ideally the means of authenticating SOAP messages will be specified in the SOAP specification.

If an XML Signature is used the scope of the signature is the <SOAP-ENV:Envelope> element.

A.1 Schemas and Web Service Definition

The following Web Service Definition Language definitions are normative. The Service, and associated Port, elements define a specific implementation and are exemplary only. In this case, a service is located at http://service.xmltrustcenter.org/Test/KeySrvc.asmx.

<?xml version="1.0"?>

<definitions xmlns:s="http://www.w3.org/2000/10/XMLSchema." xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:ds="http://www.w3.org/2000/09/xmldsig#"

xmlns:xkms="http://www.xkms.org/schema/xkms-2001-01-20" targetNamespace="http://www.xkms.org/schema/xkms-2001-01-20" xmlns="http://schemas.xmlsoap.org/wsdl/">

<types>

<s:schema targetNamespace="http://www.xkms.org/schema/xkms-2001-01-20"

attributeFormDefault="unqualified" elementFormDefault="qualified">

<s:import namespace="http://www.w3.org/2000/09/xmldsig#"

schemaLocation="http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/xmldsig-core-schema.xsd"/>

<s:element name="Register">

<s:complexType>

<s:sequence>

<s:element name="Prototype" type="xkms:KeyBindingType"/>

<s:element name="AuthInfo" minOccurs="0">

<s:complexType>

<s:choice>

<s:element name="AuthUserInfo" type="xkms:AuthUserInfoType"/>

<s:element name="AuthServerInfo" type="xkms:AuthServerInfoType"/>

</s:choice>

</s:complexType>

</s:element>

<s:element name="Respond" minOccurs="0" >

<s:complexType>

<s:sequence>

<s:element name="string" type="string" minOccurs="0" maxOccurs="unbounded"/>

</s:sequence>

</s:complexType>

</s:element>

</s:sequence>

</s:complexType>

</s:element>

<s:complexType name="AuthUserInfoType">

<s:sequence>

<s:element name="ProofOfPossession" minOccurs="0">

<s:complexType>

<s:sequence>

<s:element ref="ds:Signature" minOccurs="0"/>

</s:sequence>

</s:complexType>

</s:element>

<s:element name="KeyBindingAuth" minOccurs="0">

<s:complexType>

<s:sequence>

<s:element ref="ds:Signature" minOccurs="0"/>

</s:sequence>

</s:complexType>

</s:element>

<s:element name="PassPhraseAuth" type="string" minOccurs="0"/>

</s:sequence>

</s:complexType>

<s:complexType name="AuthServerInfoType">

<s:sequence>

<s:element name="KeyBindingAuth" minOccurs="0">

<s:complexType>

<s:sequence>

<s:element ref="ds:Signature" minOccurs="0"/>

</s:sequence>

</s:complexType>

</s:element>

<s:element name="PassPhraseAuth" type="string" minOccurs="0"/>

</s:sequence>

</s:complexType>

<s:complexType name="KeyBindingType">

<s:sequence>

<s:element name="TransactionID" type="string" minOccurs="0"/>

<s:element name="Status" type="xkms:AssertionStatus"/>

<s:element name="KeyID" type="uriReference" minOccurs="0"/>

<s:element ref="ds:KeyInfo" minOccurs="0"/>

<s:element name="PassPhrase" type="string" minOccurs="0"/>

<s:element name="ProcessInfo" minOccurs="0">

<s:complexType>

<s:sequence minOccurs="0" maxOccurs="unbounded">

<s:any namespace="##other"/>

</s:sequence>

</s:complexType>

</s:element>

<s:element name="ValidityInterval" type="xkms:ValidityIntervalType" minOccurs="0"/>

<s:element name="KeyUsage" type="xkms:KeyUsageType" minOccurs="0" maxOccurs="unbounded"/>

</s:sequence>

<s:attribute name="Id" type="ID" use="optional"/>

</s:complexType>

<s:simpleType name="AssertionStatus">

<s:restriction base="string">

<s:enumeration value="Valid"/>

<s:enumeration value="Invalid"/>

<s:enumeration value="Indeterminate"/>

</s:restriction>

</s:simpleType>

<s:simpleType name="KeyUsageType">

<s:restriction base="string">

<s:enumeration value="Encryption"/>

<s:enumeration value="Signature"/>

<s:enumeration value="Exchange"/>

</s:restriction>

</s:simpleType>

<s:complexType name="ValidityIntervalType">

<s:sequence>

<s:element name="NotBefore" type="timeInstant" minOccurs="0"/>

<s:element name="NotAfter" type="timeInstant" minOccurs="0" />

</s:sequence>

</s:complexType>

<s:element name="RegisterResult">

<s:complexType>

<s:sequence>

<s:element name="Result" type="xkms:ResultCode"/>

<s:element name="Answer">

<s:complexType>

<s:sequence>

<s:element name="KeyBinding" type="xkms:KeyBindingType"

minOccurs="0" maxOccurs="unbounded"/>

</s:sequence>

</s:complexType>

</s:element>

<s:element name="Private" type="string" minOccurs="0" />

</s:sequence>

</s:complexType>

</s:element>

<s:simpleType name="ResultCode">

<s:restriction base="string">

<s:enumeration value="Success"/>

<s:enumeration value="NoMatch"/>

<s:enumeration value="NotFound"/>

<s:enumeration value="Incomplete"/>

<s:enumeration value="Failure"/>

<s:enumeration value="Refused"/>

<s:enumeration value="Pending"/>

</s:restriction>

</s:simpleType>

<s:element name="Validate">

<s:complexType>

<s:sequence>

<s:element name="Query" type="xkms:KeyBindingType"/>

<s:element name="Respond" minOccurs="0" >

<s:complexType>

<s:sequence>

<s:element name="string" type="string" minOccurs="0" maxOccurs="unbounded"/>

</s:sequence>

</s:complexType>

</s:element>

</s:sequence>

</s:complexType>

</s:element>

<s:element name="ValidateResult">

<s:complexType>

<s:sequence>

<s:element name="Result" type="xkms:ResultCode"/>

<s:element name="Answer" minOccurs="0">

<s:complexType>

<s:sequence>

<s:element name="KeyBinding" type="xkms:KeyBindingType"

minOccurs="0" maxOccurs="unbounded"/>

</s:sequence>

</s:complexType>

</s:element>

</s:sequence>

</s:complexType>

</s:element>

<s:element name="Locate">

<s:complexType>

<s:sequence>

<s:element name="TransactionID" type="string" minOccurs="0"/>

<s:element name="Query">

<s:complexType>

<s:sequence>

<s:element ref="ds:KeyInfo"/>

</s:sequence>

</s:complexType>

</s:element>

<s:element name="Respond" minOccurs="0">

<s:complexType>

<s:sequence>

<s:element name="string" type="string" minOccurs="0" maxOccurs="unbounded"/>

</s:sequence>

</s:complexType>

</s:element>

</s:sequence>

</s:complexType>

</s:element>

<s:element name="LocateResult">

<s:complexType>

<s:sequence>

<s:element name="TransactionID" type="string" minOccurs="0"/>

<s:element name="Result" type="xkms:ResultCode"/>

<s:element name="Answer" minOccurs="0">

<s:complexType>

<s:sequence>

<s:element ref="ds:KeyInfo" minOccurs="0" maxOccurs="unbounded"/>

</s:sequence>

</s:complexType>

</s:element>

</s:sequence>

</s:complexType>

</s:element>

</s:schema>

</types>

</message>

</message>

</message>

</message>

</message>

</message>

</operation>

</operation>

</operation>

</portType>

<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/>

<soap:operation soapAction="http://service.xmltrustcenter.org/Register" style="document"/>

<input>

<soap:body use="literal"/>

</input>

<soap:body use="literal"/>

</output>

</operation>

<soap:operation soapAction="http://service.xmltrustcenter.org/Validate" style="document"/>

<input>

<soap:body use="literal"/>

</input>

<soap:body use="literal"/>

</output>

</operation>

<soap:operation soapAction="http://service.xmltrustcenter.org/Locate" style="document"/>

<input>

<soap:body use="literal"/>

</input>

<soap:body use="literal"/>

</output>

</operation>

</binding>

<http:binding verb="POST"/>

</binding>

<http:binding verb="GET"/>

</binding>

<soap:address location="http://service.xmltrustcenter.org/Test/KeySrvc.asmx"/>

</port>

<http:address location="http://service.xmltrustcenter.org/Test/KeySrvc.asmx"/>

</port>

<http:address location="http://service.xmltrustcenter.org/Test/KeySrvc.asmx"/>

</port>

</service>

</definitions>

A.2 RSA Private Key Data

The following schema is used to specify the public and private parameters of an RSA key pair. The schema elements are identical to those defined in PKCS#1 [PKCS1].

<schema targetNamespace="http://www.xkms.org/schema/xkms-2001-01-20/RSAKeyData"

<element name='Modulus' type='ds:CryptoBinary'

minOccurs='1' maxOccurs='1'/>

<element name='PublicExponent' type='ds:CryptoBinary'

minOccurs='1' maxOccurs='1'/>

<element name='PrivateExponent' type='ds:CryptoBinary'

minOccurs='1' maxOccurs='1'/>

<element name='P' type='ds:CryptoBinary'

minOccurs='0' maxOccurs='1'/>

<element name='Q' type='ds:CryptoBinary'

minOccurs='0' maxOccurs='1'/>

</sequence>

</complexType>

</element>

</schema>

A.3 Encryption Envelope

The following schema MAY be used as an interim substitute for the XML Encryption standard [XML-ENC] currently in development.

<schema targetNamespace="http://www.xkms.org/schema/xkms-2001-01-20/EncInfo"

xmlns="http://www.w3.org/1999/XMLSchema"

xmlns:ds="http://www.w3.org/2000/09/xmldsig">

<element name="KeyAlg" type="ds: String"

minOccurs="1" maxOccurs="1"/>

<element name="EncryptionAlg" type="ds:String"

minOccurs="1" maxOccurs="1"/>

<element name="IV" type="ds:CryptoBinary"

minOccurs="1" maxOccurs="1"/>

<element name="EncryptedData" type="ds:CryptoBinary"

minOccurs="1" maxOccurs="1"/>

</sequence>

</complexType>
</element>

Appendix B Sample Protocol Exchanges

B.1 Tier 1 Example 1

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

Client Request

<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"

xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<soap:Body>

<Query>

<ds:KeyInfo>

<ds:KeyValue>

<ds:RSAKeyValue>

<ds:Modulus>998/T2PUN8HQlnhf9YIKdMHHGM7HkJwA56UD0a1oYq7EfdxSXAidruAszNqBoOqfarJIsfcVKLob1hGnQ/l6xw==</ds:Modulus>

<ds:Exponent>AQAB</ds:Exponent>

</ds:RSAKeyValue>

</ds:KeyValue>

</ds:KeyInfo>

</Query>

<string>KeyName</string>

</Respond>

</Locate>

</soap:Body>

</soap:Envelope>

Server Response

<?xml version="1.0"?>

xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<soap:Body>

<Result>Success</Result>

<ds:KeyInfo>

<ds:KeyValue>

<ds:RSAKeyValue>

<ds:Modulus>998/T2PUN8HQlnhf9YIKdMHHGM7HkJwA56UD0a1oYq7EfdxSXAidruAszNqBoOqfarJIsfcVKLob1hGnQ/l6xw==</ds:Modulus>

<ds:Exponent>AQAB</ds:Exponent>

</ds:RSAKeyValue>

</ds:KeyValue>

<ds:KeyName>Account 1823945 Key 3</ds:KeyName>

</ds:KeyInfo>

</Answer>

</LocateResult>

</soap:Body>

</soap:Envelope>

B.2 Tier 1 Example 2

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

Client Request

<?xml version="1.0"?>

xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<soap:Body>

<Query><ds:KeyInfo><ds:KeyName>Alice Cryptographer</ds:KeyName></ds:KeyInfo></Query>

<string>KeyValue</string>

</Respond>

</Locate>

</soap:Body>

</soap:Envelope>

Server Response

<?xml version="1.0"?>

xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<soap:Body>

<Result>Success</Result>

<Answer> <ds:KeyInfo><ds:KeyValue><ds:RSAKeyValue><ds:Modulus>998/T2PUN8HQlnhf9YIKdMHHGM7HkJwA56UD0a1oYq7EfdxSXAidruAszNqBoOqfarJIsfcVKLob1hGnQ/l6xw==</ds:Modulus><ds:Exponent>AQAB</ds:Exponent></ds:RSAKeyValue></ds:KeyValue><ds:KeyName>Alice Cryptographer</ds:KeyName></ds:KeyInfo>

</Answer>

</LocateResult>

</soap:Body>

</soap:Envelope>

B.3 Tier 2

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

Client Request

<?xml version="1.0"?>

xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<soap:Body>

<Query>

<Status>Valid</Status>

<ds:KeyInfo>

<ds:KeyValue>

<ds:RSAKeyValue>

<ds:Modulus>998/T2PUN8HQlnhf9YIKdMHHGM7HkJwA56UD0a1oYq7EfdxSXAidruAszNqBoOqfarJIsfcVKLob1hGnQ/l6xw==</ds:Modulus>

<ds:Exponent>AQAB</ds:Exponent>

</ds:RSAKeyValue>

</ds:KeyValue>

<ds:KeyName>Account 1823945 Key 3</ds:KeyName>

</ds:KeyInfo>

</Query>

<string>KeyName</string>

<string>KeyValue</string>

</Respond>

</Validate>

</soap:Body>

</soap:Envelope>

Server Response

<?xml version="1.0"?>

xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<soap:Body>

<Result>Success</Result>

<Status>Valid</Status>

<KeyID>http://www.xmltrustcenter.org/assert/20000920-3</KeyID>

<ds:KeyInfo>

<ds:KeyValue>

<ds:RSAKeyValue>

<ds:Modulus>998/T2PUN8HQlnhf9YIKdMHHGM7HkJwA56UD0a1oYq7EfdxSXAidruAszNqBoOqfarJIsfcVKLob1hGnQ/l6xw==</ds:Modulus>

<ds:Exponent>AQAB</ds:Exponent>

</ds:RSAKeyValue>

</ds:KeyValue>

<ds:KeyName>Account 1823945 Key 3</ds:KeyName>

</ds:KeyInfo>

</ValidityInterval>

</KeyBinding>

</Answer>

</ValidateResult>

</soap:Body>

</soap:Envelope>

B.4 Registration of Client Generated Key Pair

Request Message

<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"

xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/1999/XMLSchema"

xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<soap:Body>

<Status>Valid</Status>

<KeyID>mailto:Alice@cryptographer.test</KeyID>

<ds:KeyInfo>

<ds:KeyName>mailto:Alice@cryptographer.test</ds:KeyName>

</ds:KeyInfo>

</ValidityInterval>

<PassPhrase>qfarJIsfcVKLo</PassPhrase>

</Prototype>

<Signature>2PUN8HQlnhf9YI</Signature>

</ProofOfPossession>

<Signature>EfdxSXAidruAszN</Signature>

</AuthKeyBinding>

</AuthUserInfo>

</AuthInfo>

<string>KeyName</string>

<string>KeyValue</string>

</Respond>

</Register>

</soap:Body>

</soap:Envelope>

Server Response

<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"

xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/1999/XMLSchema"

xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<soap:Body>

<Result>Success</Result>

<Status>Valid</Status>

<KeyID>mailto:Alice@cryptographer.test</KeyID>

<ds:KeyInfo>

<ds:KeyValue>

<ds:RSAKeyValue>

<ds:Modulus>998/T2PUN8HQlnhf9YIKdMHHGM7HkJwA56UD0a1oYq7EfdxSXAidruAszNqBoOqfarJIsfcVKLob1hGnQ/l6xw==</ds:Modulus>

<ds:Exponent>AQAB</ds:Exponent>

</ds:RSAKeyValue>

</ds:KeyValue>

<ds:KeyName>mailto:Alice@cryptographer.test</ds:KeyName>

</ds:KeyInfo>

</ValidityInterval>

</KeyBinding>

</Answer>

</RegisterResult>

</soap:Body>

</soap:Envelope>

B.5 Registration of server generated key

Request

<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"

xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/1999/XMLSchema"

xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<soap:Body>

<Status>Valid</Status>

<KeyID>mailto:Alice@cryptographer.test</KeyID>

<ds:KeyInfo><ds:KeyName>mailto:Alice@cryptographer.test</ds:KeyName></ds:KeyInfo>

</ValidityInterval>

<PassPhrase>qfarJIsfcVKLo</PassPhrase>

</Prototype>

<Signature>EfdxSXAidruAszN</Signature>

</AuthKeyBinding>

</AuthServerInfo>

</AuthInfo >

<string>KeyName</string>

<string>KeyValue</string>

<string>Private</string>

</Respond>

</Register>

</soap:Body>

</soap:Envelope>

Service Response

<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"

xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/1999/XMLSchema"

xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<soap:Body>

<result>Success</result>

<Status>Valid</Status>

<KeyID>mailto:Alice@cryptographer.test</KeyID>

<ds:KeyInfo>

<ds:KeyValue>

<ds:RSAKeyValue>

<ds:Modulus>998/T2PUN8HQlnhf9YIKdMHHGM7HkJwA56UD0a1oYq7EfdxSXAidruAszNqBoOqfarJIsfcVKLob1hGnQ/l6xw==</ds:Modulus>

<ds:Exponent>AQAB</ds:Exponent>

</ds:RSAKeyValue>

</ds:KeyValue>

<ds:KeyName>mailto:Alice@cryptographer.test</ds:KeyName>

</ds:KeyInfo>

</ValidityInterval>

</KeyBinding>

</Answer>

<Private>IsfcVKLob1hGnQ/l6xw</Private>

</RegisterResult>

</soap:Body>

</soap:Envelope>

Appendix C Immediate Binding

This appendix describes a means of expressing X-KISS and X-KRSS messages without reference to the SOAP protocol or an equivalent. This is an optional feature. Implementations may implement this but are considered fully compliant with XKMS if they do not.

Messages may be layered on a MIME compliant transport protocol such as HTTP or MIME using the following header descriptor.

Content-Type: application/x-xkms+xml; charset="utf-8"

In HTTP the POST method is used to exchange a request and response.

The collected XML schema specification is:

<?xml version="1.0"?>

<schema targetNamespace="http://www.xkms.org/schema/xkms-2001-01-20"

xmlns:xkms="http://www.xkms.org/schema/xkms-2001-01-20"

xmlns:ds="http://www.w3.org/2000/09/xmldsig#"

xmlns="http://www.w3.org/2000/10/XMLSchema"

attributeFormDefault="unqualified" elementFormDefault="qualified">

<import namespace="http://www.w3.org/2000/09/xmldsig#"

schemaLocation="http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/xmldsig-core-schema.xsd"/>

</choice>

</complexType>

</element>

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</restriction>

</simpleType>

</restriction>

</simpleType>

</sequence>

</complexType>

<element name="KeyBinding" type="xkms:KeyBindingType"

minOccurs="0" maxOccurs="unbounded"/>

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</element>

</restriction>

</simpleType>

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</element>

<element name="KeyBinding" type="xkms:KeyBindingType"

minOccurs="0" maxOccurs="unbounded"/>

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</element>

</schema>

Appendix D References

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

[RFC-2104] Krawczyk, H., Bellare, M. and R. Canetti, HMAC: Keyed Hashing for Message Authentication, IETF RFC 2104, February 1997.

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

[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

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

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

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

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

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

[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

Microsoft, Verisign, WebMethods hereby grant to the W3C, a perpetual, nonexclusive, non-sublicensable, non-assignable, royalty-free, worldwide right and license under any copyrights in this contribution to copy, publish and distribute the contribution, as well as a right and license of the same scope to any derivative works prepared by the W3C and based on, or incorporating all or part of the contribution.

Microsoft, Verisign, WebMethods further agree that, upon submission of this contribution to the W3C, Microsoft, Verisign, WebMethods will grant to any party a royalty-free license on other reasonable and non-discriminatory terms under Microsoft's applicable intellectual property rights essential to implement and use the technology proposed in this contribution in products that comply with this contribution, but only for the purpose of complying with this contribution. Microsoft, Verisign, WebMethods expressly reserve all other rights it may have in the material and subject matter of this contribution. The licensing commitments made hereunder do not include any license for implementation of other published specifications developed elsewhere but referred to in this contribution.

This contribution is being provided "AS IS", and MICROSOFT, VERISIGN and WEBMETHODS EXPRESSLY DISCLAIM ANY AND ALL WARRANTIES REGARDING THIS CONTRIBUTION, INCLUDING ANY WARRANTY THAT THIS CONTRIBUTION DOES NOT VIOLATE THE RIGHTS OF OTHERS OR IS FIT FOR A PARTICULAR PURPOSE.

XML Key Management Specification (XKMS)

W3C Note 30 March 2001

2.1 Tier 0: <ds:RetrievalMethod> Processing

2.2 Tier 1 Locate Service

3.1.5 <Respond>

5.1.1 <AuthInfo>

6.1.2 <KeyBindingAuth>