Copyright ©2001 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
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).
This is an editors copy and has no official status whatsoever.
This is the third draft of the "XML Key Management Specification
(XKMS)" specification from the XML Key Management Working
Group (Activity
Statement).
This version attempts to capture the consensus resulting from the
December 9th 2001 face-to-face meeting and subsequent discussion on the list.
However, it does contain points which are still under discussion or not well
specified. The Working Group will try to use a new namespace when changes
in its syntax or processing are substantive. However, this namespace might be
reused (prior to reaching Candidate Recommendation) by subsequent drafts in
such a way as to cause instances using the namespace to become invalid or to
change in meaning or affect the operation of existing software. Requests for
a more stringent level of namespace stability should be made to the Working
Group.
Publication of this document does not imply endorsement by the W3C
membership. This is a draft document and may be updated, replaced or
obsoleted by other documents at any time. It is inappropriate to cite a W3C
Working Draft as anything other than a "work in progress." A list of current
W3C working drafts can be found at http://www.w3.org/TR/.
Please send comments to the editor (<pbaker@verisign.com>) and cc: the working group mailing list www-xkms@w3c.org (archive)
Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page in conformance with W3C policy.
To be generated
To be generated
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-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.
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.
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:
This specification uses XML Schemas [XML-schema] to describe the content model.
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]:
"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)"
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."
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 conventionsClient
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.
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
| Prefix | Specification | Schema |
| XML Schema | http://www.w3.org/2001/XMLSchema | |
| ds | XML Signature | http://www.w3.org/2000/09/xmldsig# |
| xenc | XML Encryption | http://www.w3.org/2001/04/xmlenc# |
| xkms | XKMS | http://www.w3.org/2002/03/xkms# |
These namespaces are declared in the XKMS schema as follows:
<?xml version="1.0"?>
<schema targetNamespace="http://www.w3.org/2002/03/xkms#"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:xkms="http://www.w3.org/2002/03/xkms#"
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 5 1st April 2002
</documentation>
</annotation>
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:
In the case of an encryption operation:
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.
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.
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).
Figure 1: Substitution of the <ds:KeyInfo> element as a message is passed amongst processors
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.
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.
Figure 3: Locate Service Provides Name Resolution
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.
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:
<Locate>
<Query>
<ds:KeyInfo>
<ds:RetrievalMethod
URI="http://www.PKeyDir.test/Certificates/01293122"
Type="http://www.w3.org/2000/09/xmldsig#X509Data"/>
</ds:KeyInfo>
</Query>
<Respond>
<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:
<LocateResult>
<Result>Success</Result>
<Answer>
<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. )
The client is attempting to send an encrypted XML document and requires the public key encryption parameters of the recipient.
Request:
<Locate>
<Query>
<ds:KeyInfo>
<ds:KeyName>Alice Cryptographer</ds:KeyName>
</ds:KeyInfo>
</Query>
<Respond>
<string>KeyName</string>
<string>KeyValue</string>
</Respond>
</Locate>
Response:
<LocateResult>
<Result>Success</Result>
<Answer>
<ds:KeyInfo>
<ds:KeyName>Alice Cryptographer</ds:KeyName>
<ds:KeyValue>...</ds:KeyValue>
</ds:KeyInfo>
</Answer>
</LocateResult>
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 4).
Figure 4: Validate Service Provides Key Validation
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:
<Validate>
<Query>
<Status>Valid</Status>
<ds:KeyInfo>
<ds:KeyName>...</ds:KeyName>
<ds:KeyValue>...</ds:KeyValue>
</ds:KeyInfo>
</Query>
<Respond>
<string>KeyName</string>
<string>KeyValue</string>
</Respond>
</Validate>
Response:
<ValidateResult>
<Result>Success</Result>
<Answer>
<KeyBinding>
<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>
<NotBefore>2000-09-20T12:00:00</NotBefore>
<NotAfter>2000-10-20T12:00:00</NotAfter>
</ValidityInterval>
</KeyBinding>
</Answer>
</ValidateResult>
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.
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
All XKMS messages MUST specify the protocol version number. If a service receives a request that specifies an unsupported protocol version the service must return the MajorResult code VersionMismatch in the response.
The protocol version number consists of two integers that represent the major and minor version numbers. Future versions of the XKMS specification SHALL specify a higher version number as follows:
Services that receive a request that contains a MajorVersion number that is not supported MUST return the MajorResult code VersionMismatch.
Security enhancements MAY be applied to control the following risks:
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.
XKMS messages MAY be layered on a secure transport protocol such as SSL/TLS [TLS] or employ payload authentication as defined in this document. If at some future data payload authentication is specified as a part of the XML Protocol this means of authentication is preferred.
[Must/Should text for above]
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.
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.
The means by which the client determines that the signing key is trustworthy is outside the scope of this specification. Possible mechanisms include:
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.
[Issue = how to specify digest of the request in the response, this should probably be done via an XML Signature authenticated attribute?]
An XKMS service MAY at its option protect against replay attacks by means of a two phase protocol:
In the first phase the requestor presents the request and the service responds the MajorResult value Represent and presents a nonce.
In the second phase the requestor represents the original request together with the nonce.
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.
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:
nonce = time + serial + M ( time + serial , k )
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.
The service may prevent replay attacks completely by tracking the serial numbers for which responses have already been given.
The following sections summarize the message processing steps taken by both parties in each of the message
The processing steps specified for the single phase case are performed with the following exceptions:
The processing steps specified for the single phase case are performed with the following exceptions:
The processing steps specified for the single phase case are performed with the following exceptions:
The processing steps specified for the single phase case are performed with the following exceptions:
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 enveloping mode. The scope of the signature is the element derived from the MessageAbstractType abstract type.
- MajorVersion [Required]
- The protocol major version number, for this version of the XKMS protocol the major version number is 2.
- MinorVersion [Required]
- The protocol minor version number, for this version of the XKMS protocol the minor version number is 0.
- 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
The following schema defines the <MessageAbstractType> element:
<complexType name="MessageAbstractType" abstract="true">
<sequence>
<element ref="ds:Signature" minOccurs="0"/>
</sequence>
<attribute name="MajorVersion" type="positiveInteger" use="required"/>
<attribute name="MinorVersion" type="integer" use="required"/>
<attribute name="Service" type="anyURI" use="required"/>
<attribute name="Nonce" type="ds:CryptoBinary" use="optional"/>
</complexType>
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.
The following schema defines the <RequestAbstractType> element::
<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="optional"/>
<attribute name="OriginalRequestID" type="ID" use="optional"/>
<attribute name="ResponseLimit" type="integer" use="optional"/>
</extension>
</complexContent>
</complexType>
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].
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.
The following identifiers are defined:
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] |
| Pending | The requestor can accept the MajorResult code Pending | |
| Represent | The requestor can accept the MajorResult code Represent |
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 following schema defines the <RespondWith> element::
<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>
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.
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
The following mechanisms are defined:
| Protocol | URI | Identifier | Description |
|---|---|---|---|
| SMTP | rfc822 | mailto: | Notification by email. The content of the email is outside the scope of this specification |
| HTTP | TBS | http:// | Notification by HTTP GET. The content of the request is outside the scope of this specification |
The following schema defines the <PendingNotification> element and PendingNotificationType type:
<element name="PendingNotification" type="xkms:PendingNotificationType"/>
<complexType name="PendingNotificationType">
<attribute name="Mechanism" type="anyURI" use="required"/>
<attribute name="Identifier" type="anyURI" use="required"/>
</complexType>
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.
The following schema defines the PendingRequest element and PendingRequestType type:
<element name="PendingRequest" type="xkms:PendingRequestType"/>
<complexType name="PendingRequestType">
<complexContent>
<extension base="xkms:RequestAbstractType">
<attribute name="ResponseID" type="ID" use="required"/>
</extension>
</complexContent> </complexType>
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 [Required]
- 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.
If the MajorResult value has the value Represent the nonce attribute MUST be present and MUST NOT be the empty string.
The following schema defines the ResultAbstractType abstract type:
<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="ID" use="required"/>
<attribute name="ResponseID" type="ID" use="required"/>
</extension>
</complexContent>
</complexType>
The following ResultMajor codes are defined:
| Code | Description |
|---|---|
| Success | The operation succeeded. |
| VersionMismatch | The service does not support the protocol version specified in the request. |
| Sender | An error occurred that was due to the message sent by the sender. |
| Receiver | An error occurred at the receiver. |
| Sender | The operation was queued for future processing. |
| Represent | The service has not acted on the request which must be represented with the specified nonce in accordance with the two phase protocol |
| Pending | The request has been accepted for processing and the service will return the result asynchronously |
The ResultMajor codes Success, VersionMismatch, Sender and Receiver are Final, that is the protocol has completed when the code is returned. The ResultMajor codes Represent and Pending are not Final and indicate that further processing is necessary to receive the result.
The following ResultMinor codes are defined:
| Code | Possible Major Codes | Description |
|---|---|---|
| NoMatch | Success, Receiver |
No match was found for the search prototype provided. |
| TooManyResponses | Success, Receiver |
The request resulted in the number of responses exceeding the ResponseLimit value specified in the request |
| Incomplete | Success | Only part of the information requested could be provided. |
| Failure | Sender, Receiver | The operation failed for unspecified reasons. |
| Refused | Sender, Receiver | The operation was refused. |
| NoAuthentication | Sender | The operation was refused because the necessary authentication information was incorrect or missing. |
Note that certain ResultMinor codes such as NoMatch may be returned in a response with a ResultMajor code of Success or Receiver depending on the naut
The following schema defines the MajorResultCodeEnumType and MinorResultCodeEnumType type:
<simpleType name="MajorResultCodeEnumType">
<restriction base="QName">
<enumeration value="Success"/>
<enumeration value="VersionMismatch"/>
<enumeration value="Sender"/>
<enumeration value="Receiver"/>
<enumeration value="Represent"/>
<enumeration value="Pending"/>
</restriction>
</simpleType>
<simpleType name="MinorResultCodeEnumType">
<restriction base="QName">
<enumeration value="NoMatch"/>
<enumeration value="NotFound"/>
<enumeration value="Incomplete"/>
<enumeration value="Failure"/>
<enumeration value="Refused"/>
</restriction>
</simpleType>
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.
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:
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.
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.
<simpleType name="AssertionStatus">
<restriction base="string">
<enumeration value="Valid"/>
<enumeration value="Invalid"/>
<enumeration value="Indeterminate"/>
</restriction>
</simpleType>
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.
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.
The following schema defines the <LocateRequest> element:
<element name="LocateRequest" type="xkms:LocateRequestType"/>
<complexType name="LocateRequestType">
<complexContent>
<extension base="xkms:RequestAbstractType">
<sequence>
<element ref="xkms:KeyInfoQuery"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="KeyInfoQuery" type="ds:KeyInfoType"/>
The request message contains a <LocateResult> element
- <ds:KeyInfo> [Any Number]
- A <ds:Keyinfo>element that matches the criteria specified in the corresponding request.
The following schema defines the <LocateResult> element:
<element name="LocateResult" type="xkms:LocateResultType"/>
<complexType name="LocateResultType">
<complexContent>
<extension base="xkms:ResultAbstractType">
<sequence>
<element ref="ds:KeyInfo" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
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.
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.
- <Status> [Required]
- The status of the key binding which may be valid, invalid or indeterminate.
- <ds: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
- ID [Optional]
- Identifier of the key binding.
- Reason [Any Number]
- Reason
[Make status an attribute? how about some others?]
The following schema defines the <KeyBinding> element and the KeyBindingType type. The <Query> and <Prototype> elements share the KeyBindingType definition.
<element name="KeyBinding" type="xkms:KeyBindingType"/>
<complexType name="KeyBindingType">
<sequence>
<element ref="xkms:Status"/>
<element ref="ds: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"/>
</sequence>
<attribute name="ID" type="ID" use="optional"/>
</complexType>
The <status> element :specifies the status of the key binding which may be valid, invalid or indeterminate.
TBS precise meanings wrt Validity Interval
Move status enumeration here
The following schema defines the <Status> element:
<element name="Status" type="xkms:AssertionStatus"/>
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.
The following schema defines the <PassPhrase> element and the PassPhraseValueType type:
<element name="PassPhrase" type="xkms:PassPhraseValueType"/>
<simpleType name="PassPhraseValueType">
<restriction base="base64Binary"/>
</simpleType>
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.
The following schema defines the <ProcessInfo> element and the ProcessInfoType type:
<element name="ProcessInfo" type="xkms:ProcessInfoType"/>
<complexType name="ProcessInfoType">
<sequence minOccurs="0" maxOccurs="unbounded">
<any namespace="##other"/>
</sequence>
</complexType>
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
All dateTime values MUST fully specify the date.
The NotBefore and NotOnOrAfter attributes are optional. If the value is omitted it is unspecified. If the NotBefore attribute is unspecified the assertion is valid on any date up to but excluding the date specified in the NotOnOrAfter attribute . If the NotOnOrAfter attribute is unspecified the assertion is valid from the NotBefore attribute 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 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
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.
The following schema defines the <ValidityInterval> element:
<element name="ValidityInterval" type="xkms:ValidityIntervalType"/>
<complexType name="ValidityIntervalType">
<attribute name="NotBefore" type="dateTime"/>
<attribute name="NotOnOrAfter" type="dateTime"/>
</complexType>
The <KeyUsage> element specifies one or more intended uses of the key. If no <KeyUsage> is specified all uses are permitted.
- 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
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 schema defines the <KeyUsage> element:
<element name="KeyUsage" type="xkms:KeyUsageType"/>
<simpleType name="KeyUsageType">
<restriction base="QName">
<enumeration value="Encryption"/>
<enumeration value="Signature"/>
<enumeration value="Exchange"/>
</restriction>
</simpleType>
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.
TBS table of application Identifiers,
| Protocol | Application URI | Subject |
| S/MIME | mailto: | |
| SSL/HTTPS | https:// | |
| IPSEC |
The following schema defines the <UseKeyWith> element:
<element name="UseKeyWith" type="xkms:UseKeyWithType"/>
<complexType name="UseKeyWithType">
<attribute name="Application" type="anyURI"/>
<attribute name="Identifier" type="anyURI"/>
</complexType>
For this version of the spec I have left the Identifier field as a URI, this should be replaced by the any construct so that there can be application specific data types.
The <Reason> element is used to specify a string that specifies a reason for a particular assertion status.
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.
The status aspects are defined in the table below. For convenience the equivalent X509 processing steps are given:
Reason |
Description |
X.509 Equivalent |
|
|---|---|---|---|
| Valid | Invalid | ||
IssuerTrust |
The assertion issuer is considered to be trustworthy by the Trust service. |
Certificate path anchored by trusted root successfully constructed |
Certificate path could not be constructed to a trusted root |
Status |
The Trust service has affirmatively verified the status of the assertion with an authoritative source |
Certificate status validated using CRL or OCSP |
Certificate status returned revoked or suspended. |
ValidityInterval |
The requested time instant was within the validity interval of the assertion |
The certificate chain was valid at the requested time instant. |
The requested time instant was before or after the certificate chain validity interval |
Signature |
Signature on signed data provided by the client in the <ds:Keyinfo> element (e.g. X509Data element) was successfully verified. |
Certificate Signature verified |
Certificate Signature verification failed |
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.
The following schema defines the <Reason> element and the ReasonCodeType type:
<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>
The validate request message contains a <ValidateRequest> element:
- <KeyBindingQuery> [Required]
- A single KeyBinding structure that is to be completed and validated.
The following schema defines the <ValidateRequest> element:
<element name="ValidateRequest" type="xkms:ValidateRequestType"/>
<complexType name="ValidateRequestType">
<complexContent>
<extension base="xkms:RequestAbstractType">
<sequence>
<element ref="xkms:KeyBindingQuery"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="KeyBindingQuery" type="xkms:KeyBindingType"/>
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.
The following schema defines the <ValidateResult> element and the ValidateResultType type.
<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>
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.
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.
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 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.
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.
Figure 5: Registration of a KeyBinding
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 contains the following <Register> element:
<Register>
<Prototype Id="keybinding">
<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>
<PassPhrase>Pass</PassPhrase>
</Prototype>
<AuthInfo>
<AuthUserInfo>
<ProofOfPossession>
<ds:Signature URI="#keybinding"
[RSA-Sign (KeyBinding, Private)] />
</ProofOfPossession>
<KeyBindingAuth>
<ds:Signature URI="#keybinding"
[HMAC-SHA1 (KeyBinding, Auth)] />
</KeyBindingAuth>
</AuthUserInfo>
</AuthInfo>
<Respond>
<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:
<RegisterResult>
<Result>Success</Result>
<Answer>
<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>
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.
<Register>
<Prototype Id="keybinding">
<Status>Valid</Status>
<KeyID>mailto:Alice@cryptographer.test</KeyID>
<KeyInfo>
<ds:KeyInfo>
<ds:KeyName>mailto:Alice@cryptographer.test</ds:KeyName>
</ds:KeyInfo>
</KeyInfo>
<PassPhrase>Pass</PassPhrase>
</Prototype>
<AuthInfo>
<AuthServerInfo>
<KeyBindingAuth>
<ds:Signature URI="#keybinding"
[HMAC-SHA1 (Prototype, Auth)] />
</KeyBindingAuth>
</AuthServerInfo>
</AuthInfo>
<Respond>
<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:
<RegisterResult>
<Result>Success</Result>
<Answer>
<KeyBinding>
<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>
<KeyBinding>
</Answer>
<Private> Base64 ( 3DES ( RSAPrivate, Enc)) </Private>
</RegisterResult>
Where:
Enc = HMAC-SHA1 ("024837", 0x4)
RSAPrivate =
<RSAKeyPair>
<ds:Modulus>998/T2PUN8HQlnhf9YIKdMHHGM7HkJwA56UD0a1oYq7EfdxSXAidr
uAszNqBoOqfarJIsfcVKLob1hGnQ/l6xw </ds:Modulus>
<PublicExponent>AQAB</PublicExponent>
<PrivateExponent>whatever</PrivateExponent>
<P>whatever</P>
<Q>whatever</Q>
</RSAKeyPair>
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.
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.
Alice requests reissue of her previously issued RSA key pair for her email address.
The X-KRSS request message contains the following <Reissue> element:
<Reissue>
<Prototype Id="keybinding">
<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>
<PassPhrase>Pass</PassPhrase>
</Prototype>
<AuthInfo>
<AuthUserInfo>
<ProofOfPossession>
<ds:Signature URI="#keybinding"
[RSA-Sign (KeyBinding, Private)] />
</ProofOfPossession>
<KeyBindingAuth>
<ds:Signature URI="#keybinding"
[HMAC-SHA1 (KeyBinding, Auth)] />
</KeyBindingAuth>
</AuthUserInfo>
</AuthInfo>
<Respond>
<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:
<ReissueResult>
<Result>Success</Result>
<Answer>
<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>
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.
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:
<Register>
<Prototype Id="keybinding">
<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>
<AuthInfo>
<AuthUserInfo>
<ProofOfPossession>
<ds:Signature URI="#keybinding"
[RSA-Sign (KeyBinding, Private)] />
</ProofOfPossession>
</AuthUserInfo>
</AuthInfo>
<Respond>
<string>KeyName</string>
<string>KeyValue</string>
</Respond>
</Register>
The service responds that the key binding has been revoked:
<RequestResult>
<Result>Success</Result>
<Answer>
<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>
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.
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:
<Register>
<Prototype>
<Status>Indeterminate</Status>
<KeyID>mailto:Alice@cryptographer.test</KeyId>
<ds:KeyInfo>
<ds:KeyName>mailto:Alice@cryptographer.test</ds:KeyName>
</ds:KeyInfo>
</Prototype>
<AuthInfo>
<PassPhraseAuth>Auth</PassPhraseAuth>
</AuthInfo>
<Respond>
<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:
<RegisterResult>
<Answer>
<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 = "
<RSAKeyPair>
<ds:Modulus>998/T2PUN8HQlnhf9YIKdMHHGM7HkJwA56UD0a1oYq7EfdxSXAidr
uAszNqBoOqfarJIsfcVKLob1hGnQ/l6xw</ds:Modulus>
<PublicExponent>AQAB</PublicExponent>
<PrivateExponent>whatever</PrivateExponent>
<P>whatever</P>
<Q>whatever</Q>
</RSAKeyPair>"
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.
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.
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.
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.
The following schema defines the <Authentication> element:
<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>
The <PassPhraseAuthentication> contains a plaintext limited use shared secret that is used to authenticate the request.
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.
The following schema defines the <PassPhraseAuthentication> element:
<element name="PassPhraseAuthentication" type="string"/>
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.
The following schema defines the <KeyBindingAuthentication> element:
<element name="KeyBindingAuthentication" type="xkms:KeyBindingAuthenticationType"/>
<complexType name="KeyBindingAuthenticationType">
<sequence>
<element ref="ds:Signature"/>
</sequence>
</complexType>
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.
The following schema defines the <ProofOfPossession> element:
<element name="ProofOfPossession" type="xkms:ProofOfPossessionType"/>
<complexType name="ProofOfPossessionType">
<sequence>
<element ref="ds:Signature"/>
</sequence>
</complexType>
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
The following schema defines the <Private> element:
<element name="Private" type="xkms:PrivateType"/>
<complexType name="PrivateType">
<sequence>
<element ref="xenc:EncryptedData"/>
</sequence>
</complexType>
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.
The following schema defines the <RegisterRequest> element:
<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"/>
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
- <Private> [Optional]
- The values of the private key parameters of a private key generated by the Registration Service
The following schema defines the <RegisterResult> element:
<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:Private" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
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.
The following schema defines the <ReissueRequest> element:
<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>
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
The following schema defines the <ReissueResult> element:
<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>
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.
The following schema defines the <RevokeRequest> element:
<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>
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
[Status will be Invalid if successful]
The following schema defines the <RevokeResult> element:
<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>
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.
The following schema defines the <RecoverRequest> element:
<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>
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.
- <Private> [Optional]
- The values of the private key parameters of the recovered private key
The following schema defines the <RecoverResult> element:
<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:Private" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
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.
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
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 following schema defines the <RSAKeyPair> element:
<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>
</schema>
Implementations SHOULD consider the following security issues.
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:
Freshness tokens MAY be encoded as XML Signature Properties.
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.
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.
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.
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).
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.
<?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 5 1st April 2002
</documentation>
</annotation>
<complexType name="MessageAbstractType" abstract="true">
<sequence>
<element ref="ds:Signature" minOccurs="0"/>
</sequence>
<attribute name="MajorVersion" type="positiveInteger" use="required"/>
<attribute name="MinorVersion" type="integer" use="required"/>
<attribute name="Service" type="anyURI" use="optional"/>
<attribute name="TransactionID" type="ID" use="optional"/>
<attribute name="Nonce" type="ds:CryptoBinary" use="optional"/>
</complexType>
<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="optional"/>
<attribute name="OriginalRequestID" type="ID" use="optional"/>
<attribute name="ResponseLimit" type="integer" use="optional"/>
</extension>
</complexContent>
</complexType>
<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>
<element name="PendingNotification" type="xkms:PendingNotificationType"/>
<complexType name="PendingNotificationType">
<attribute name="Mechanism" type="anyURI" use="required"/>
<attribute name="Identifier" type="anyURI" use="required"/>
</complexType>
<element name="PendingRequest" type="xkms:PendingRequestType"/>
<complexType name="PendingRequestType">
<complexContent>
<extension base="xkms:RequestAbstractType"/>
</complexContent>
</complexType>
<complexType name="ResultAbstractType" abstract="true">
<complexContent>
<extension base="xkms:MessageAbstractType">
<attribute name="ResultMajor" type="QName"
use="required"/>
<attribute name="ResultMinor" type="QName" use="required"/>
</extension>
</complexContent>
</complexType>
<simpleType name="MajorResultCodeEnumType">
<restriction base="QName">
<enumeration value="Success"/>
<enumeration value="VersionMismatch"/>
<enumeration value="Sender"/>
<enumeration value="Receiver"/>
<enumeration value="Represent"/>
</restriction>
</simpleType>
<simpleType name="MinorResultCodeEnumType">
<restriction base="QName">
<enumeration value="NoMatch"/>
<enumeration value="NotFound"/>
<enumeration value="Incomplete"/>
<enumeration value="Failure"/>
<enumeration value="Refused"/>
<enumeration value="Pending"/>
</restriction>
</simpleType>
<!-- XKISS Basic Types -->
<simpleType name="AssertionStatus">
<restriction base="string">
<enumeration value="Valid"/>
<enumeration value="Invalid"/>
<enumeration value="Indeterminate"/>
</restriction>
</simpleType>
<!-- XKISS Locate -->
<element name="LocateRequest" type="xkms:LocateRequestType"/>
<complexType name="LocateRequestType">
<complexContent>
<extension base="xkms:RequestAbstractType">
<sequence>
<element ref="xkms:KeyInfoQuery"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="KeyInfoQuery" type="ds:KeyInfoType"/>
<element name="LocateResult" type="xkms:LocateResultType"/>
<complexType name="LocateResultType">
<complexContent>
<extension base="xkms:ResultAbstractType">
<sequence>
<element ref="ds:KeyInfo" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!-- XKISS Validate-->
<element name="KeyBinding" type="xkms:KeyBindingType"/>
<complexType name="KeyBindingType">
<sequence>
<element ref="xkms:Status"/>
<element ref="ds: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"/>
</sequence>
<attribute name="ID" type="ID" use="optional"/>
</complexType>
<element name="Status" type="xkms:AssertionStatus"/>
<element name="PassPhrase" type="xkms:PassPhraseValueType"/>
<simpleType name="PassPhraseValueType">
<restriction base="base64Binary"/>
</simpleType>
<element name="ProcessInfo" type="xkms:ProcessInfoType"/>
<complexType name="ProcessInfoType">
<sequence minOccurs="0" maxOccurs="unbounded">
<any namespace="##other"/>
</sequence>
</complexType>
<element name="ValidityInterval" type="xkms:ValidityIntervalType"/>
<complexType name="ValidityIntervalType">
<attribute name="NotBefore" type="dateTime"/>
<attribute name="NotOnOrAfter" type="dateTime"/>
</complexType>
<element name="KeyUsage" type="xkms:KeyUsageType"/>
<simpleType name="KeyUsageType">
<restriction base="QName">
<enumeration value="Encryption"/>
<enumeration value="Signature"/>
<enumeration value="Exchange"/>
</restriction>
</simpleType>
<element name="UseKeyWith" type="xkms:UseKeyWithType"/>
<complexType name="UseKeyWithType">
<attribute name="Application" type="anyURI"/>
<attribute name="Identifier" type="anyURI"/>
</complexType>
<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>
<element name="ValidateRequest" type="xkms:ValidateRequestType"/>
<complexType name="ValidateRequestType">
<complexContent>
<extension base="xkms:RequestAbstractType">
<sequence>
<element ref="xkms:KeyBindingQuery"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="KeyBindingQuery" type="xkms:KeyBindingType"/>
<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>
<!-- XKRSS -->
<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>
<element name="PassPhraseAuthentication" type="string"/>
<element name="KeyBindingAuthentication"
type="xkms:KeyBindingAuthenticationType"/>
<complexType name="KeyBindingAuthenticationType">
<sequence>
<element ref="ds:Signature"/>
</sequence>
</complexType>
<element name="ProofOfPossession" type="xkms:ProofOfPossessionType"/>
<complexType name="ProofOfPossessionType">
<sequence>
<element ref="ds:Signature"/>
</sequence>
</complexType>
<element name="Private" type="xkms:PrivateType"/>
<complexType name="PrivateType">
<sequence>
<element ref="xenc:EncryptedData"/>
</sequence>
</complexType>
<!-- Register -->
<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"/>
<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:Private" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!-- Reissue -->
<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>
<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>
<!-- Revoke -->
<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>
<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>
<!-- Recover -->
<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>
<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:Private" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<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>
</schema>
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.
TBS
This example shows the formatting of the X-KISS request and response for the first example in section 2.2 above.
Request Message
TBS
TBS
This example shows the formatting of the X-KISS request and response for the second example in section 2.2 above.
Request Message
TBS
Server Response
TBS
This example shows the formatting of the X-KISS request and response for the example in section 2.2.1 above.
Request Message
TBS
Server Response
TBS
Request Message
TBS
Server Response
TBS
Request Message
TBS
Server Response
TBS
[CSP] C. A. R. Hoare
[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/
[TLS] TBS
[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/
TBS