14.3 The Key Registration Service

This section gives an overview of the Key Registration Service Specification (X-KRSS). It is just as important as the key information service. Securely entering the proper information and bindings is obviously critical to providing correct information, although storing a key binding probably occurs less often than retrieving it.

Table 14-2. XKMS Respond Strings
String Element(s) Description
KeyName xmldsig:KeyName Key name
KeyValue xmldsig:KeyValue Public key parameters
X509Cert xmldsig:X509Data X.509v3 certificate authenticating the specified key
X509Chain xmldsig:X509Data[1] X.509v3 certificate chain authenticating the specified key
X509CRL xmldsig:X509Data X.509v2 certificate revocation list
OCSP xmldsig:X509Data OCSP token authenticating the X.509v3 certificate [RFC 2560]
RetrievalMethod xmldsig:RetrievalMethod Retrieval method information
MgmtData xmldsig:MgmtData (Use not recommended; see Chapter 13)
PGP xmldsig:PGPData PGP certificate
PGPWeb xmldsig:PGPData[1] Collection of PGP certificates
SPKI xmldsig:SPKIData[1] SPKI certificates
Multiple   Requests multiple answers if available
Private   Requests the encrypted private key

[1] This element may occur multiple times.

14.3.1 X-KRSS Service

The key registration service uses an all-purpose Register operation. A public key, possibly the corresponding private key, and information bound to are present in the xkms:KeyBinding element. The policies stating to whom information will be given, including such sensitive issues as to whom to release a private key for key recovery if the server generated the key pair and retained the private key, are implementation dependent. Also implementation dependent is which public key infrastructure or types of certificates a key registration service supports or to which it is linked.

Key Revocation

A registration service may permit clients to revoke previously registered assertions. This task is accomplished by sending a registration request in which the status is specified as "Invalid." Service policy dictates what authentication is required with such a request.

Key Recovery

A registration service that has generated a public/private key pair for a client must return the private key (encrypted) at that time. It may also permit the client to obtain the private key later by submitting a similar registration request. The service policy dictates what authentication is required for such a request and what, if any, additional steps (e.g., invalidating the key binding) the service might take.

14.3.2 X-KRSS Register Messages

This section summarizes key registration messages.


The client specifies a prototype KeyBinding element as the heart of a registration request. The information in that element may be incomplete, in which case the server is asked to fill in missing information before registering the binding. For example, the server would generally generate a name if no key name is provided; it might also generate a public/private key pair if none is provided.


The AuthInfo element contains data that authenticate the request. Such data might include a proof that the client possesses the private key corresponding to the public key being registered. The exact content depends on the algorithms in use and the party generating the public/private key pair. You use the AuthUserInfo element if the client generates the key pair; you use the AuthServerInfo element if the server generates the key pair.

 <element name="AuthInfo" minOccurs="0">    <complexType>       <choice>          <element name="AuthUserInfo"                   type="xkms:AuthUserInfoType"/>          <element name="AuthServerInfo"                   type="xkms:AuthServerInfoType"/>       </choice>    </complexType> </element> 
Request Message

A request message consists of the Register element, which has the following schema:

 <element name="Register">   <complexType>     <sequence>       <element name="KeyBinding"                type="xkms:KeyBindingType"/>       <element name="AuthInfo" minOccurs="0">         <complexType>           <choice>             <element name="AuthUserInfo"                      type="xkms:AuthUserInfoType"/>             <element name="AuthServerInfo"                      type="xkms:AuthServerInfoType"/>           </choice>         </complexType>       </element>       <element name="Respond" minOccurs="0" >         <complexType>           <sequence>             <element name="string" type="string"                      minOccurs="0"                      maxOccurs="unbounded"/>           </sequence>         </complexType>       </element>     </sequence>   </complexType> </element> 
  • The KeyBinding structure specifies elements that the client requests be registered.

  • AuthInfo provides information that authenticates the request.

  • Respond (see Section 14.2) provides a sequence of identifiers that specify data elements that the client requests be returned in the response.

Response Message

A RegisterResult element constitutes a response message. It has the following schema:

 <element name="RegisterResult">   <complexType>     <sequence>       <element name="Result" type="xkms:ResultCode"/>       <element name="Answer" >         <complexType>           <all>             <element name="KeyBinding"                      type="xkms:KeyBinding"                      minOccurs="0"                      maxOccurs="unbounded"/>           </all>         </complexType>       </element>       <element name="Private" type="string" />     </sequence>   </complexType> </element> 
  • KeyBinding specifies the key binding that was registered by the service, if present.

  • Private conveys additional information provided by the server, such as values for private key parameters generated by the registration service. (See Section 14.4.2.)

  • Both KeyBinding and Private are optional.

14.3.3 Bulk Registration Services

Manufacturers of equipment with built-in keys or certificates, such as smart card or cable modem makers, need some way to register large amounts of key information efficiently. The X-KRSS protocol described previously does not handle this need efficiently. To satisfy this goal a bulk key registration protocol, currently called XBULK, is under development.

Secure XML(c) The New Syntax for Signatures and Encryption
Secure XML: The New Syntax for Signatures and Encryption
ISBN: 0201756056
EAN: 2147483647
Year: 2005
Pages: 186

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net