SCDJWS Study Guide: XML Security


Printer-friendly version Printer-friendly version | Send this 
article to a friend Mail this to a friend


Previous Next vertical dots separating previous/next from contents/index/pdf Contents

XML Key Management Specification (XKMS)


Introduction


The XML Key Management Specification (XKMS) defines protocols for Public Key Management services. XKMS is based on a comprehensive, open, and standards based approach to adding trust processing to cryptographic XML applications. XKMS is a foundational specification for secure Web services, enabling Web services to register and manage cryptographic keys used for digital signatures and encryption. The architecture of XKMS has been designed to complement the emerging W3C standards activities in the XML Digital Signature and XML Encryption Working Groups.

Public Key Management

Public Key management includes the creation of a public and private key pair, the binding of this key pair with identity and other attributes, and the representation of this key pair in different formats, such as by key name, digital certificate or key parameters, to give some examples. Public key technology is an essential part of XML Digital Signatures, XML Encryption and other security applications. When signing, the private key is used to sign and the public key is used to verify signatures. When encrypting, the public key is used to encrypt and the private key is used to decrypt.

In either case the private key must be maintained under control of the owner and the public key may be shared with others. XKMS is designed to help manage the sharing of the public key to enable signature verification and encrypting for recipients.

Public Key management usually requires a registration step in which the key pair is generated and some sort of token is issued to associate the public key with the identity and other attributes of the owner. This registration step usually incorporates some sort of due diligence to reduce the risks of associating the public key incorrectly, since people will rely upon the key pair later. Management also includes the ability to revoke the association of information with the key pair should circumstances change, such as the theft of the private key or a change in the owner's attributes (no longer an employee, for example). Likewise, information bound to the key pair may be updated. Traditionally, such bindings were managed using X.509 Digital Certificates, specialized protocols and public key infrastructures. XKMS defines XML message formats to support requests and responses for public key management, including registration, revocation and updates. This eliminates the need for applications to support other specialized public key registration and management protocols.

Once registration is complete, a public key pair may be used for signing and verification or encryption and decryption. The <KeyInfo> element defined in the XML Digital Signature recommendation may be used to provide information to the recipient of a digital signature or encrypted data block about the key needed to process that content. This information may take on a number of different forms, such as a key name, a digital certificate containing the public key, a set of key parameters, or a URI indicating where to obtain the public key. Given the variety of choices for providing information about a key to a recipient, it may be hard for an application to process and locate a key. In addition to the difficulty of anticipating all formats, some, such as X.509 certificates, require special cryptographic code and logic for processing. XKMS provides an XML message format to allow this processing to be performed by a service which will sort through the various options, determine the one that was used, and provide the key information to the recipient in a useful form.

Public Key Infrastructure (PKI)

The comprehensive system required providing public-key encryption and digital signature services are known as a public-key infrastructure.

The purpose of a public-key infrastructure is to manage keys and certificates. By managing keys and certificates through a PKI, an organization establishes and maintains a trustworthy networking environment. A PKI enables the use of encryption and digital signature services across a wide variety of applications.

PKI refers to a set of security services for authentication, encryption, and digital certificate management under which documents are encrypted with a private key and decrypted using a publicly available key accessible to the recipient via a network. PKI differs from private key technology, like Kerberos, in which a single key that is shared by the sender and receiver is used to encrypt and decrypt a message or document.

PKI proves important for e-commerce and Web services. However, one of the obstacles to PKI's wide adoption is that PKI operations such as public key validation, registration, recovery, and revocation are complex and require large amounts of computing resources, which prevents some applications and small devices such as cell phones from participating in PKI-based e-commerce or Web services transactions. XKMS enables an XKMS server to perform these PKI operations. In other words, applications and small devices, by sending XKMS messages over SOAP (Simple Object Access Protocol), can ask the XKMS server to perform the PKI operations. In this regard, the XKMS server provides trust services to its clients in the form of Web services.

XKMS Functions

An XKMS-compliant service supports the following operations:

  • Register: XKMS services can be used to register key pairs for escrow services. Generation of the public key pair may be performed by either the client or the registration service. Once keys are registered, the XKMS-compliant service manages the revocation and recovery of registered keys, whether client- or server-generated. Additional functions are reissue, revoke, and recover.
  • Locate: The Locate service is used to retrieve a public key registered with an XKMS-compliant service. The public key can in turn be used to encrypt a document or verify a signature.
  • Validate: The Validate service is used to ensure that a public key registered with an XKMS-compliant service is valid, and has not expired or been revoked. The validation service can also be used to check attributes against a public key.

These services can be complimented by having cryptographic capabilities on the client, but client crypto is not required. For example, if a client must generate keys, then some crypto code, resident on the client, performs the key generation. However, the client can just as easily have the XKMS service generate the keys that are subsequently managed through the service. For security, however, most client applications generate a keypair, and then register the public key with the CA.

XKMS describes mechanisms that enable XML-aware applications to easily incorporate public-key infrastructure to support digitally signed and/or encrypted XML documents. XKMS defines a Web services interface to a public key infrastructure. This makes it easy for applications to interface with key-related services, like registration and revocation, and location and validation. Most developers will only ever need to worry about implementing XKMS clients. XKMS server components are mostly implemented by providers of public key infrasructure (PKI) providers, such as Entrust, Baltimore and VeriSign. VeriSign, for example, provides an XKMS responder that can be used to register and query VeriSign's certificate store. Even SSL server ID's can be validated in real-time using the XKMS interface.

The Benefits of XKMS

XKMS defines a Web service interface to a public key infrastructure. XKMS provides many benefits. The most important benefits are that XKMS is:

  • Easy to use: The developer-friendly syntax used in XKMS eliminates the necessity for PKI toolkits and proprietary plug-ins. The XKMS specification allows developers to rapidly implement trust features, incorporating cryptographic support for XML digital signatures and XML encryption using standard XML toolkits.
  • Quick to deploy: By simplifying application development, XKMS removes the need to delay PKI deployment because of , and instead, moves the complexity of PKI to server side components. Developers can now focus on their core competency of developing applications rather than the complexities surrounding a PKI deployment.
  • Open: The common XML vocabulary used to describe authentication, authorization, and profile information in XML documents makes XKMS services completely platform, vendor, and transport-protocol-neutral. The XKMS specification has been submitted to the World Wide Web Consortium (W3C) as an open standard for distribution and registration of keys.
  • Ideal for mobile devices: XKMS allow mobile devices to access full-featured PKI through ultra-minimal-footprint client device interfaces.
  • Future-proof: Supports new and emerging PKI developments since the impact of future PKI developments is restricted to server-side components. By restricting the impact of future PKI developments and advancements to the server-side components, XKMS protects developers and applications from becoming incompatible with the latest developments in PKI.

Features of XKMS

The XML Key Management Specification (XKMS) defines three specifications:  These specifications define the XML request and response messages necessary for registering and managing information associated with public keys and for ensuring that security requirements are met.

  • XML Key Registration Service Specification (XKRSS)

XKRSS defines protocols to support the registration of a key pair by a key pair holder. Each of these protocols describes protocol exchanges that consist of a simple request and response exchange with a Trust Service.

The registration service supports the binding of information with a public key pair, either one generated by the server or by the client. The binding associates information with the key pair, creating a <KeyBinding> element. This binding may have a validity period associated with it and may be reissued or revoked. The private key associated with a key binding may also be backed up recovered if the local copy is destroyed (as when an operating system requires reinstallation).

  • XML Key Information Service Specification (XKISS)

XKISS defines protocols to support the processing of Key Information associated with a XML digital signature, XML encrypted data in an XML-aware application. Functions supported include locating required public keys given identifier information, and binding of such keys to identifier information.

The key information service allows a client to request information associated with a <KeyInfo> element. This may include:

    • Locate - Resolve the <KeyInfo> element to return requested key information
    • Validate - Locate key information and provide an assertion on the validity of the binding to the key pair. 

A key information request may specify the form of key information to be returned. For example, it may request that a <KeyName> and <KeyValue> be determined from a <KeyInfo> element. As part of this process, the server may perform validation to assert the validity of the binding to the key.

  • Protocol Bindings

The Protocol Bindings specification defines mechanisms for meeting security requirements, including mechanisms to ensure message confidentiality, integrity, and security. This includes the following definitions:

  • A two phase protocol to avoid replay attacks
  • Pending response protocol
  • Use of payload security
  • Use of transport security such as SSL/TLS
  • Use of Web Services security

Key Concepts

Important points about the XKMS specification are:

  1. This specification defines XML protocol messages to convey key registration and information requests to a trust server and to convey responses from the server. The specification defines a binding of these messages to the XML Protocol (SOAP) and defines the relationships among the messages using the Web Services Definition Language (WSDL).
  2. <ds:KeyInfo> processing is delegated to the trust service by the client, minimizing the complexity of the client. How the trust service is implemented is dependent on the service, but acting as a front-end to a public key infrastructure (PKI) is one possibility.
  3. The XML Key Information Service Specification (XKISS) includes online status functionality equivalent to that in traditional PKI OCSP protocols as part of the Validate functionality.
  4. Registration supports the requirements of smart card manufacturing, including bulk processing and pending responses.>
  5. The specification supports the use of XML Digital Signatures for message integrity and authentication. The specification also defines other authentication mechanisms, support for proof of key ownership and other security functionality.
  6. A Locate or Validate request may include a <KeyInfo> element and <RespondWith> element in the request. The <RespondWith> element is used to specify what the <KeyInfo> element is to be resolved to, possibly more than one item. For example, the request <KeyInfo> might contain an X.509 certificate and the <RespondWith> might indicate that the KeyName and KeyValue are to be returned. Possibilities include KeyName, KeyValue, and Certificate, Certificate Chain (collection of certificates needed to trace a signature back to a trusted party) among the possibilities outlined in the specification.
  7. A <KeyBinding> element is used to associate information with a key. This is what is returned in a Locate or Validate response. Every <KeyBinding> includes a <ValidityInterval> (NotBefore, NotOnOrAfter) and may also include <KeyInfo>, <ProcessInfo> (opaque data), <KeyUsage> and <UseKeyWith> elements.
  8. Key usage definition is deliberately limited to Encryption, Signing and Key Exchange.
  9. A <KeyBinding> <UseKeyWith> element defines which application and application entity the key is intended for. For example, a key may only be appropriate for authentication of an SSL server. In this case, the application is HTTPS, and the identifier is the URL of the server. Applications listed in the specification include S/MIME, HTTPS, SMTP, IPSec, PKIX and others.

Examples

A client might generate a key pair and wish to register it with a trust server, as in this example. (Complete examples are provided with the XKMS specification):

<RegisterRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
                    Service="http://test.xmltrustcenter.org/XKMS"
                    RequestId="hZMRGyATbUL4H7rYOanR6Q=="
                    xmlns="http://www.w3.org/2002/03/xkms#">
    <RespondWith>X509Cert</RespondWith>
    <Prototype Id="tX4Y83grmj/eIVoeYNuTNg==">
        <KeyInfo>
            <ds:KeyValue>
                <ds:RSAKeyValue>
                    <ds:Modulus>
                        zvbTdKsTprGAKJdgi7ulDR0eQBptL...
                    </ds:Modulus>
                    <ds:Exponent>
                        AQAB
                    </ds:Exponent>
                </ds:RSAKeyValue>
            </ds:KeyValue>
        </KeyInfo>
        <KeyUsage>Signature</KeyUsage>
        <UseKeyWith Application="urn:ietf:rfc:2633"
                    Identifier="alice@alicecorp.test" />
    </Prototype>
    <Authentication>
        <ProofOfPossession>
            <ds:Signature>
                signing with the private key demonstrates possession of it
            </ds:Signature>
        </ProofOfPossession>
    </Authentication>
</RegisterRequest>
Example 8 - XKMS Register Request

The server responds with the information requested with <RespondWith>:

<RegisterResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
                Service="http://test.xmltrustcenter.org/XKMS"
                ResultMajor="Success"
                RequestId="hZMRGyATbUL4H7rYOanR6Q=="
                ResponseId="k9gyjDdhLLV1vbF7RzJjIw=="
                xmlns="http://www.w3.org/2002/03/xkms#">
    <KeyBinding Id="LVrJqd26QzO9GWJD0usQwg==">
        <KeyInfo>
           <KeyName>Sally Smith key</KeyName>
        </KeyInfo>
        <KeyUsage>Signature</KeyUsage>
        <UseKeyWith Application="urn:ietf:rfc:2633"
                    Identifier="alice@alicecorp.test" />
    </KeyBinding>
</RegisterResult>
Example 9 - XKMS Register Response

A client could request an identity validation:

<ValidateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
                 xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
                 Service="http://test.xmltrustcenter.org/XKMS"
                 RequestId="zzjmNi9YL+dnkRXzDoqPoQ=="
                 xmlns="http://www.w3.org/2002/03/xkms#">
    <RespondWith>KeyName</RespondWith>
    <RespondWith>KeyValue</RespondWith>
    <RespondWith>Multiple</RespondWith>
    <KeyBindingQuery Id="T/QMi7gGuKCcNWPi120A/w==">
        <KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    certificate encoded as text
                </ds:X509Certificate>
            </ds:X509Data>
        </KeyInfo>
        <KeyUsage>Signature</KeyUsage>
        <UseKeyWith Application="urn:ietf:rfc:2633"
                    Identifier="alice@alicecorp.test" />
    </KeyBindingQuery>
</ValidateRequest>
Example 10 - XKMS Validate Request

The following response indicates that the certificates are valid:

<ValidateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
                xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
                Service="http://test.xmltrustcenter.org/XKMS"
                ResultMajor="Success"
                RequestId="zzjmNi9YL+dnkRXzDoqPoQ=="
                ResponseId="0WeinJVdbyBKruXhiqTscg=="
                xmlns="http://www.w3.org/2002/03/xkms#">
    <KeyBinding Id="m0/p5bekjemI4tV+FPBkig==">
        <KeyInfo>
            <ds:KeyValue>
                <ds:RSAKeyValue>
                    <ds:Modulus>...</ds:Modulus>
                    <ds:Exponent>AQAB</ds:Exponent>
                </ds:RSAKeyValue>
            </ds:KeyValue>
        </KeyInfo>
        <KeyUsage>Signature</KeyUsage>
        <UseKeyWith Application="urn:ietf:rfc:2633"
                    Identifier="alice@alicecorp.test" />
        <Reason>IssuerTrust</Reason>
        <Reason>RevocationStatus</Reason>
        <Reason>ValidityInterval</Reason>
    </KeyBinding>
</ValidateResult>
Example 11 - XKMS Validate Response

XKMS Web Service

With XKMS, the complex PKI tasks are offloaded to a web service using XKMS APIs that uses XML. Verisign’s implementation of XKMS web service is located at, http://interop-xkms.verisign.com/xkms/Acceptor.nano.

The key functionalities of PKI, exposed by the XKMS web service includes:

  • Registering the signing key pair
  • Locating the public key
  • Validating the key
  • Key revocation
  • Key recovery

These authentication functions will reside in web servers that can be accessed from web-based programs that use the XML language. By allowing the XML application developer to delegate trust decisions to specialized processors, XKMS shields XML client implementation from the complexity of the underlying PKI. A simple configuration of the XKMS web service is illustrated in the figure  below.
http://www.cswl.com/whiteppr/tech/xkms.html

As you can see in the above picture, XML is primarily used in communicating with XKMS web service. One can write one’s own APIs as long as the XML interface to the XKMS web service is kept. For e.g. generating a key pair, securely storing it, creating a certificate, traversing and verifying certificate chains, checking whether a certificate has been revoked etc., is currently done with vendor-specific APIs. Microsoft CAPI, RSA BSAFE, Xcert Xuda, Java Security package etc., all have their own APIs and certificate and key stores and certificate servers. XKMS introduces an XML standard into their operation.

Summary

XKMS stands for the XML Key Management Specification and consists of two parts: XKISS (XML Key Information Service Specification) and XKRSS (XML Key Registration Service Specification). XKISS defines a protocol for resolving or validating public keys contained in signed and encrypted XML documents, while XKRSS defines a protocol for public key registration, revocation, and recovery. The key aspect of XKMS is that it serves as a protocol specification between an XKMS client and an XKMS server in which the XKMS server provides trust services to its clients (in the form of Web services) by performing various PKI (public key infrastructure) operations, such as public key validation, registration, recovery, and revocation on behalf of the clients.

XKMS defines a Web services interface to a public key infrastructure. This makes it easy for applications to interface with key-related services, like registration and revocation, and location and validation. Most developers will only ever need to worry about implementing XKMS clients. XKMS server components are mostly implemented by providers of public key infrasructure (PKI) providers, such as Entrust, Baltimore and VeriSign. VeriSign, for example, provides an XKMS responder that can be used to register and query VeriSign's certificate store. Even SSL server ID's can be validated in real-time using the XKMS interface.

XKMS is a foundational specification for secure Web services, enabling Web services to register and manage cryptographic keys used for digital signatures and encryption.

When combined with WS-Security, XKMS makes it easier than ever for developers to deploy enterprise applications in the form of secure Web services available to business partners beyond the firewall.

With XKMS, developers can integrate authentication, digital signature, and encryption services, such as certificate processing and revocation status checking, into applications in a matter of hours - without the constraints and complications associated with proprietary PKI software toolkits.


Reference


Getting Started With XML Security
Securing Web Services using XKMS
What is a PKI?
<? XML Tust Center />


Glossary


  • Public Key

    A number associated with a particular entity (for example, an individual or an organization). A public key is intended to be known to everyone who needs to have trusted interactions with that entity.

  • Private Key

    A number that is supposed to be known only to a particular entity. That is, private keys are always meant to be kept secret. A private key is always associated with a single public key.

  • Digital Signature

    A string of bits that is computed from some data (the data being "signed") and the private key of an entity. The signature can be used to verify that the data came from the entity.

    Like a handwritten signature, a digital signature has many useful characteristics:

    • Its authenticity can be verified, via a computation that uses the public key corresponding to the private key used to generate the signature.
    • It cannot be forged, assuming the private key is kept secret.
    • It is a function of the data signed and thus can't be claimed to be the signature for other data as well.
    • The signed data cannot be changed; if it is, the signature will no longer verify as being authentic.
  • Cryptography Algorithm

    An algorithm used to help ensure one or more of the following:

    1. the confidentiality of data
    2. authentication of the data sender
    3. integrity of the data sent
    4. nonrepudiation; a sender cannot deny having sent a particular message

      A digital signature algorithm provides some of these characteristics. Also see message digest algorithms. Digital signature and message digest algorithms are available in JDK 1.1.

      A separate release (Java Cryptography Extensions) will provide APIs and algorithms related to encryption and decryption.

      • Encryption

        The process of taking data (called cleartext) and a short string (a key) and producing ciphertext, which is data meaningless to a third-party who does not know the key.

      • ecryption

        The inverse of encryption; the process of taking ciphertext and a short key string, and producing cleartext.

      • Certificate

        A digitally signed statement from one entity, saying that the public key of some other entity has some particular value. If you trust the entity that signed a certificate, you trust that the association in the certificate between the specified public key and another particular entity is authentic.

      • Message Digest Algorithm (or One-Way Hash Function)

        A function that takes arbitrary-sized input data (referred to as a message) and generates a fixed-size output, called a digest (or hash). A digest has the following properties:

        • It should be computationally infeasible to find another input string that will generate the same digest.
        • The digest does not reveal anything about the input that was used to generate it.

        Message digest algorithms are used to produce unique and reliable identifiers of data. The digests are sometimes called the "digital fingerprints" of data.

        Some digital signature algorithms use message digest algorithms for parts of their computations.

        Some digital signature systems compute the digest of a message and digitally sign the digest rather than signing the message itself. This can save a lot of time, since digitally signing a long message can be time-consuming.

      • Engine Class

        The term engine class is used in the Java Security API to refer to a class that provides the functionality of a type of cryptography algorithm. The Security API defines a Java class for each engine class. For example, there is a MessageDigest class, a Signature class, and a KeyPairGenerator class. Users of the API request and utilize instances of these engine classes to carry out corresponding operations. A Signature instance is used to sign and verify digital signatures, a MessageDigest instance is used to calculate the message digest of specified data, and a KeyPairGenerator is used to generate pairs of public and private keys suitable for a specified algorithm.

        An engine class provides the interface to the functionality of a specific type of algorithm, while its actual implementations (from one or more providers) are those for specific algorithms. The Signature engine class, for example, provides access to the functionality of a digital signature algorithm. The actual implementation supplied in a Signature subclass could be that for any kind of signature algorithm, such as SHA-1 with DSA, SHA-1 with RSA, or MD5 with RSA.

      • Provideri

        Implementations for various algorithms in Java Security are provided by Cryptography Package Providers. Providers are essentially packages that implement one or more engine classes for specific algorithms. For example, the Java Development Kit's default provider, named "SUN", supplies implementations of the DSA signature algorithm and of the MD5 and SHA-1 message digest algorithms. Other providers may define their own implementations of these algorithms or of other algorithms, such as one of the RSA-based signature algorithms or the MD2 message digest algorithm.



Previous Next vertical dots separating previous/next from contents/index/pdf Contents

  |   |