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.

Registration

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.

xkms:AuthInfo

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.