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.
14.3.1 X-KRSS ServiceThe 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 RevocationA 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 RecoveryA 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 MessagesThis section summarizes key registration messages. RegistrationThe 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:AuthInfoThe 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 MessageA 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>
Response MessageA 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>
14.3.3 Bulk Registration ServicesManufacturers 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. |