14.1 The Key Information Service | Secure XML: The New Syntax for Signatures and Encryption

This section gives an overview of the Key Information Service Specification (X-KISS). See Figures 14-1 and 14-2.

Figure 14-1. Signature key information service flow

graphics/14fig01.gif

Figure 14-2. Encryption key information service flow

graphics/14fig02.gif

It is a particular goal of X-KISS to relieve clients of the need to do the following:

Understand the complex non-XML syntax and semantics of various certificate types such as X.509v3
Retrieve and understand information from various directory systems
Perform revocation status determination
Construct and understand trust chains

This specification will enable less capable devices, such as handheld personal digital assistants or cell phones, to more easily make use of XML Security based on complex public key infrastructures. In exchange, such devices generally surrender the ability to enforce their own trust policies. Instead, they get the trust policy of the key information service they elect to use.

14.1.1 X-KISS Services

XKMS defines three levels (tiers) of key information service. It mentions the possibility of higher-level services, such as those dealing with long-term trust relationships or the status of trust assertions, but leaves their specification to others.

Retrieval Method

The lowest (Tier 0) is simply the ability to use the xmldsig:RetrievalMethod type of xmldsig:KeyInfo. This ability allows the application to retrieve the object pointed to by a URL. [XMLDSIG] recommends that implementation be able to at least handle "http:" scheme URLs. An XKMS service does not actually provide this level, so why the XKMS document lists this ability isn't completely clear.

Locate Service

The next level of service (Tier 1) retrieves and provides information concerning keys. As described later in this chapter, a request message includes a query that uses xmldsig:KeyInfo to indicate what the client knows about the key and a section in which the client specifies the information it wants. For example, a client might know only the key name and want the key value. Alternatively, it might have an X.509v3 certificate but wish to use the XKMS service to parse this certificate and extract the key value and key name.

The Locate Service provides no trust assertion. It does not perform such trust actions as checking for revocation.

Validate Service

The highest-level service (Tier 2) provides the same services of the Locate Service as well as assurance, within the service's trust policy, of the validity and binding between provided or returned data items and the identified key.

For example, a client could provide a key name and value and obtain a trusted assertion that the key value was bound to that key name. Alternatively, it could provide a certificate chain, including an end-user certificate, and receive in return the key name, key value, a trusted binding between them, and confidence that neither that certificate nor any higher-level certificates in the chain was revoked.

14.1.2 Locate Service

The Locate Service accepts an xmldsig:KeyInfo element to specify the public key for a particular query. It returns one or more xmldsig:KeyInfo elements that relate to the same key. The xkms:Respond element (see Section 14.2) specifies the elements to be returned.

 Schema Definition: <element name="Locate">    <complexType>       <sequence>          <element name="Query" type="xmldsig:KeyInfo"/>          <element name="Respond" >             <complexType>                <sequence>                   <element name="string"                            type="string"                            minOccurs="0"                            maxOccurs="unbounded"/>                </sequence>             </complexType>          </element>       </sequence>    </complexType> </element>

The schema for the response from an XKMS key information service follows:

 Schema Definition: <element name="LocateResult">    <complexType>       <sequence>          <element name="Result" type="xkms:ResultCode"/>          <element name="Answer" >             <complexType>                <all>                   <element name="xmldsig:KeyInfo"                            type="xmldsig:KeyInfo"                            minOccurs="0"                            maxOccurs="unbounded"/>                </all>             </complexType>          </element>       </sequence>    </complexType> </element>

When XKMS is wrapped in SOAP, all xkms:ResultCode values other than Success, Incomplete, and NoMatch are returned as SOAP Fault elements with a fault code of "Server" (changed in the current draft of SOAP to "Receiver"). The XKMS implementation defines the structure of the SOAP detail element.

14.1.3 Validate Service

Using the Validate Service, a client can request an assertion of the binding between an xmldsig:KeyInfo element and other data such as an identifier. The request includes an xkms:KeyBinding model for the assertion requested.

xkms:ValidityInterval

This element specifies the time limits on the validity of the assertion. Its schema follows:

 <complexType name="ValidityInterval">    <sequence>       <element name="NotBefore" type="timeInstant"/>       <element name="NotAfter" type="timeInstant"/>    </sequence> </complexType>

NotBefore is the time at which validity starts.
NotAfter is the time just before which validity stops.

You can omit either or both values, in which case the end of the time interval remains unspecified. If you omit both, you are purporting to ask about an assertion for all time.

xkms:KeyId

A KeyID specifies a URI identifier for the key. It differs from the KeyName, which need not be a URI. If the KeyID is a URL, a binding is asserted between the key and the address and protocol specified. For example, a KeyID in a Prototype or Query element specifying the "https:" or "mailto:" scheme indicates an intention to use the specified key with the given protocol.

The KeyID element has the following schema:

 <element name="KeyID" type="string" minOccurs="0"/>

xkms:KeyUsage

KeyUsage specifies the general types of usage for which the key is intended. If no KeyUsage is given, all uses are permitted. Its schema follows:

 <simpleType name="KeyUsageValue" base="string">    <enumeration value="Encryption"/>    <enumeration value="Signature"/>    <enumeration value="Exchange"/> <!-- key exchange --> </simpleType> <element name="KeyUsage">    <complexType>       <all>          <element name="string" type="xkms:KeyUsageValue"                   minOccurs="0" maxOccurs="unbounded"/>       </all>    </complexType> </element>

xkms:ProcessInfo

The ProcessInfo element can provide processing information associated with a key binding. It is optional, and clients should treat it as opaque. Its schema follows:

 <element name="ProcessInfo" type="string" minOccurs="0"/>

xkms:PassPhrase

The PassPhrase element contains a MAC (hash) function output value encoded in base-64. For further information, see Section 14.4.1.

xkms:KeyBinding, xkms:Query, and xkmx:Prototype

The KeyBinding element asserts a binding between data elements that relate to a public key, including KeyName, KeyValue, and X509Data elements. The service asserts this binding by sending a KeyBinding to the client.

The Query and Prototype elements have the same schema as KeyBinding:

 <complexType name="KeyBinding">    <sequence>       <element name="Status"                type="xkms:BindingStatus"/>       <element name="KeyID" type="string"                             minOccurs="0"/>       <element name="KeyInfo" type="xmldsig:KeyInfo"/>       <element name="PassPhrase" type="string"                                  minOccurs="0"/>       <element name="ProcessInfo" type="string"                                  minOccurs="0"/>       <element name="ValidityInterval"                type="xkms:ValidityInterval"/>       <element name="KeyUsage" type="xkms:KeyUsage"            minOccurs="0" maxOccurs="unbounded"/>    </sequence> </complexType>

Request Message

A Request message consists of a Validate element, whose schema is as follows:

 <element name="Validate">   <complexType>     <all>       <element name="query" type="xkms:KeyBinding"/>       <element name="respond">         <complexType>           <all>             <element name="string" type="s:string"                      minOccurs="0"                      maxOccurs="unbounded"/>           </all>         </complexType>       </element>     </all>   </complexType> </element>

"Query" is a single KeyBinding structure that is to be completed and validated.
"Respond" is a sequence of identifiers that specifies data elements requested by the client; they are returned in the response as defined in Section 14.2.

Response Message

A Response message consists of a ValidateResponse element, whose schema follows:

 <element name="ValidateResult">   <complexType>     <all>       <element name="Result" type="xkms:ResultCode"/>       <element name="Answer" >         <complexType>           <sequence>             <element name="KeyBinding"                      type="xkms:KeyBinding"                      minOccurs="0" maxOccurs="unbounded"/>           </sequence>         </complexType>       </element>     </all>   </complexType> </element>

"Answer" is a sequence of KeyBinding elements that contain the results of the validation. If no results are found, the sequence is empty and the ResultCode NoMatch is returned.

The response message includes a ResultCode, as defined in Section 14.2.