- Public Key Infrastructure Basics
- XKMS Evolution
- XKMS Service Specifications
- XKMS Architecture
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
XKMS Service Specifications
XKMS, in turn, consists of two major service specifications:
XML Key Information Service Specification (XKISS)
XML Key Registration Service Specification (XKRSS)
Let's explore XKISS and XKRSS in detail.
XML Key Information Service Specification (XKISS)
XKISS defines the protocol for a client Web service application to communicate with an XKMS-compatible service provider—to identify, verify, and bind the public key information. This key information is made available to the client service, usually by means of the <ds: KeyInfo> element, embedded or transmitted along with the confidential XML document, from a sender Web service. (I discussed including the <ds: KeyInfo> optional element in my articles on XML encryption and XML digital signatures.) A sample <ds: KeyInfo> section is shown in Figure 1.
)
Figure 1 XML public key information.
As discussed previously, all XKMS-compliant services provide key location and validation service. All XKISS does is to bring in a standard methodology and protocols for communicating between this XKMS service and a client service. Standardization enables service providers, as well as clients, to be independent of proprietary calls. Thus, XKISS enables the delegation of a complex piece of work in securing Web service communications to third-party service providers.
Another interesting advantage XKISS brings to applications is that the client service can be blissfully unaware of the underlying PKI implementation details. For example, the information contained within <ds: KeyInfo> may be referring to a specific PKI specification (for example, X.509). Now, the client need not worry about specific details of X.509 because it communicates only through the standard XKISS protocol, which is a level above X.509. The original sender of the message may even change his PKI to something different in the future, yet the client may not be affected at all! This is because the key information processing is the responsibility of the service provider, not the end user!
XML Key Registration Service Specification (XKRSS)
XKRSS defines the protocol for clients to register public key information with the XKMS-compatible service providers. Clients of XKRSS are possessors of authentic public and private keys who want to enable other parties to establish private communications with them by making use of their public keys.
During registration, the public key information is often tied to the key owner by means of a name, identification tags, and other attributes, if necessary. Once a key is registered, it can be used in conjunction with XKISS and other related Web services.
An earlier section discussed how XKISS enables the processing of the <ds: KeyInfo> element by a third-party service provider. To process the keys, the service provider obviously needs to ensure the authenticity of the key and then bind the key with relevant identification. XKRSS supports these operations by defining standard protocols for registering key information with the service provider.
The generation of public and private keys should be completed at the client's end before the registration process. Alternatively, the client can delegate the service to generate a public and private key pair. The obvious advantage of the second approach is that the responsibility of maintaining a private key goes with the service provider; the disadvantage is the fact that the private key information is now also exposed to the service provider.
Apart from key registration, XKRSS also supports key replacement, invalidation, and revocation.