How XKMS Distributes and Registers Public Keys

The XML Key Management Specification (XKMS) is a standard designed to simplify the integration of Public Key Infrastructure (PKI) with XML-based web services. Instead of requiring client applications to handle complex PKI tasks—such as parsing certificates, verifying certificate revocation lists (CRLs), and building trust chains—XKMS offloads these responsibilities to a centralized trust server. It uses standard XML messaging protocols (typically over SOAP) to handle the distribution, validation, and registration of public keys through two primary sub-protocols: the XML Key Information Service Specification (X-KISS) and the XML Key Registration Service Specification (X-KRSS).

Key Distribution and Validation via X-KISS

X-KISS defines how applications obtain and validate public keys to verify digital signatures or encrypt XML documents without implementing native PKI logic. It operates using two main message pairs:

• Locate Service: When a client processes an XML Signature containing a ds:KeyInfo element that lacks sufficient public key details (such as a name or certificate identifier), it sends an XML <LocateRequest> to the XKMS service. The XKMS server resolves the identifier and returns a <LocateResult> containing the complete public key and associated binding details formatted as XML.
• Validate Service: To confirm that a key is currently valid and trusted, the client sends a <ValidateRequest>. The XKMS trust server handles the complex backend verification—querying Certificate Authorities (CAs), checking expiration dates, and verifying CRLs or OCSP responses. The server then responds with a <ValidateResult>, returning a simple assertion confirming whether the key is valid, invalid, or indeterminate.

Public Key Registration and Lifecycle via X-KRSS

X-KRSS handles the lifecycle management of public key pairs, enabling clients to register, update, and revoke keys through standardized XML messages.

• Registration (<RegisterRequest>): A client generates a public/private key pair locally (or requests server-side generation) and sends the public key along with proof of possession and identity attributes inside an XML payload. The XKMS server processes the request, binds the public key to the provided identity within the underlying PKI or directory service, and returns a <RegisterResult>.
• Reissue (<ReissueRequest>): When a key or associated certificate is near expiration, or when user attributes change, the client submits a reissue request to update the binding without repeating the full initial registration process.
• Revocation (<RevokeRequest>): If a private key is compromised or an identity is decommissioned, the client submits an authenticated revocation message. The XKMS server coordinates with the underlying CA to invalidate the key binding.
• Recovery (<RecoverRequest>): For systems configured with server-side key generation or key escrow, an authorized user can securely retrieve a lost private key through an XML-based recovery exchange.

XML Message Flow

Every XKMS operation follows a straightforward request-response model encoded in standard XML schema. A client creates an XML document representing the operation, embeds authentication and integrity mechanisms (such as XML Signature or shared-secret authentication), and transmits it over HTTP/SOAP. The XKMS trust server acts as a gateway between the lightweight XML application layer and traditional enterprise security infrastructure, translating XML requests into PKI operations and returning standardized XML responses.