XML Key Information Service Specification
|
The X-KISS protocol supports two services, locate and validate. Both services answer queries of the form “What are the public key credentials that I should to communicate with X using protocol Y?” The difference between the services is that the locate service may return information that has not been validated as trustworthy by the service. A validate service must only return information that is considered trustworthy in accordance with a specific trust policy.
Locate
A locate service functions like a directory. It is the responsibility of the client to validate all information returned by the locate service. A locate service may filter the information it returns to ensure that only information that is trustworthy is returned, but it is not required to do so. A locate service may be operated in a trustworthy manner, but a client using the service must not rely on the machine operating the service being secure.
As a result of these restrictions, a locate service is typically used for distributing signed credentials such as X.509 certificates or PGP key signing information that are authenticated by a third party.
A locate request contains one QueryKeyBinding that identifies the key binding for which information is request.If the locate operation is successful the response contains one or more UnverifiedKeyBinding elements. These elements are shown in Table 8-6.
| Request Element | Description |
|---|---|
| QueryKeyBinding | Template that identifies the key binding requested |
| Response Element | Description |
| UnverifiedKeyBinding | Key binding information returned by the locate service |
| Tip | The XKMS locate function was designed as a replacement for the directory services traditionally associated with PKIs. The XKMS locate function is designed to support the exact query functionality required by a PKI-enabled application and as a result is considerably simpler to implement than configuring an LDAP or X.500 directory for the same purpose. |
| Caution | Information provided by locate should not be relied on without first verifying it. This may be done by either forwarding the response data to a trusted XKMS validate service or by performing the appropriate certificate chain validation rules. |
Example 8-1: Sending an Encrypted E-mail
Alice wants to send an encrypted e-mail to Bob whose e-mail address is bob@xyz.newcorp.com. To do this, she must find Bob’s certificate. Her e-mail client makes an XKMS locate request for Bob’s e-mail encryption certificate to the XKMS locate service of Bob’s company (don’t worry about how Alice finds this service; we will discuss this later on). The e-mail client then performs PKIX certificate chain validation to decide whether Bob’s certificate is trustworthy and, if this is the case, sends the encrypted e-mail to Bob. This is shown in the illustration.
| Note | In XKMS 2.0, the e-mail application identifies the security protocol (S/MIME) and e-mail address explicitly. In the XKMS 1.0 specification, the e-mail address is specified as a URL (mailto:bob@xyz,newcorp.com), which required the service to try to guess which security protocol the client intended to use. |
Example 8-2: Building Trust Paths in a Complex PKI
Delegating the problem of finding trust paths to an XKMS service allows a simple client to access the functions of a very complex and sophisticated PKI—for example, the federal bridge CA currently being established by the U.S. federal government. Initial proposals for a PKI to support the U.S. government agencies ran into interminable political arguments as various agencies argued over who should be “in charge.” This led to a proposal for a “bridge CA” that allows the various agencies to communicate securely without ceding authority or recognition to another agency. Each agency is the “root of trust” for its own PKI. The individual agencies each recognize and are recognized by the bridge CA as a peer.
The following illustration shows a (somewhat simplified) example of using the bridge CA. Alice works for the Executive Office of the President (EOP) while Bob works for the National Security Agency (NSA). Alice and Bob both regard the agency they work for as their root of trust. So to send an encrypted e-mail to Bob, Alice’s e-mail client must find the trust path from the EOP CA through the bridge CA, and the NSA CA to Bob (shown in bold arrows). To send an encrypted reply, Bob’s e-mail client must find the trust path from the NSA root through the bridge CA, to the EOP CA, and then to Alice.
This process becomes complex, especially when considering the larger problem of bridging the U.S. government PKI to the PKIs maintained by other governments (for example, allies in NATO), universities, suppliers, and so forth. XKMS hides this complexity from the application, allowing the application programmer to ignore the issue of how to navigate the various bridges to discover the trust path necessary to allow the communication to be secured.
Validate
A locate service does not provide any assurance that the key binding information it returns is trustworthy. A service of this type is useful for locating signed credentials such as certificates but still requires the client to do a substantial amount of work to check that the credential is valid and trustworthy.
The validate service provides all the functions of locate but returns a trusted key binding that has been validated in accordance with the policy of the validate service.
A validate request contains one QueryKeyBinding that identifies the key binding for which information is requested. If the operation is successful, the response contains one or more KeyBinding elements.
These elements are shown in Table 8-7.
| Request Element | Description |
|---|---|
| QueryKeyBinding | Template that identifies the key binding requested |
| Response Element | Description |
| KeyBinding | Key binding information returned by the validate service |
The illustration shows an example of using a validation service in a corporate supply chain application. The Web Services administered by the sales and support departments both receive signed requests from customers that must be verified before the operations requested are performed. The sales and support machines forward the credentials provided in the request signatures to a local validate service that decides whether they are valid with respect to the corporate trust policy.
Centralizing the credential validation in this way allows the management of this task to be separated from the management of the sales and support functions. This might allow the sales or support functions to be outsourced to a service provider while still allowing the enterprise full control over the criteria used to evaluate credentials. Management of the XKMS validate service might also be outsourced to another third party, which might provide additional services such as insuring the individual transactions against fraudulent credential use.
A validate service is a trusted service. In computer security terms, a service is trusted if compromise of the trusted service could result in harm to the users or applications that rely upon it.
A trusted system is not necessarily a trustworthy system. A bank vault is a trusted system if it is used to store large quantities of money; however, it is not a trustworthy system if the combination lock is set to an easily guessed combination such as 1234. The steps required to make a system trustworthy depend on the degree of harm that could result from a compromise. Compromise of a PKI is likely to result in a very considerable degree of harm, so an XKMS validate service is likely to require a very substantial degree of physical security, network security, and operational security.
| Note | The need for particular care when returning trusted information is the reason that XKMS defines two separate services. Applications using a locate serve are required to validate the information returned before they rely on it. Because of this, a locate service may be operated in environments which lack the physical and information security precautions essential to the validate service. |
| Caution | An application should only trust information from a validate service if the validate service has previously been identified as trustworthy. |
Using the VeriSign TSIK to Perform Locate and Validate
The locate and validate services may be used from a Java program, using the VeriSign TSIK as follows:
-
Create an XMLTransportSOAP object for the URL of the service
-
Create an instance of the XKMSLocate or XKMSValidate object
-
Send the request to the XKMS object using the send() method
-
Process the response
The following code fragment shows an example of using the TSIK to locate the certificate corresponding to the specified key name using the VeriSign test service:
public static void Locate (String keyName, KeyPair signingKey) throws IOException, XKMSException, NoSuchAlgorithmException, InvalidKeySpecException, Exception { service = "http://interop-xkms.verisign.com/xkms/Acceptor.nano"; XmlTransport transport = new XmlTransportSOAP(new URL(service)); String responses[] = {XKMSLocate.KeyName, XKMSLocate.X509Cert}; XKMSLocate locate = new XKMSLocate(keyName, responses, signingKey); XKMSLocateResponse response = locate.send(transport); System.out.println("Response status is " + response.getStatus()); if (response.getStatus()) { System.out.println("KeyInfos is " + response.getXKMSKeyInfos()); } } Configuration Options
XKMS locate and validate services may be used in combination. A credential may be obtained from any number of untrusted locate services and then presented to a validate service for verification.
XKMS services may be combined in a referral configuration or a chained configuration. In the referral configuration, the client first makes a query to a locate service and then forwards the information to the validate service itself (see the following illustration).
In the chained service model, the validate service performs the locate query on behalf of the client (see the following illustration). The chained service model moves all the decision-making tasks from the client and is therefore more generally applicable.
Locating X-KISS Locate Services
So far we have discussed the use of X-KISS services to locate untrusted key binding information and hinted at the fact that there are likely to be many locate services in use. How, then, is a client meant to find the right locate service to direct a particular query to?
A possible solution would be to use a Web Services directory such as UDDI. This only postpones the issue, however, because it is very likely that there will be multiple UDDI services.
What is really needed is a way to use the Domain Name System (DNS) to translate Internet names into addresses, to advertise the existence of an XKMS service for a DNS domain. A recently defined extension to DNS called the SRV record does just that.
| Caution | The DNS system as currently deployed is insecure and so an application should not place any significant degree of trust in information received from DNS, including SRV records. The security of DNS will be greatly improved when the DNS Security specification being developed by the IETF is widely deployed. |
The following illustration shows an example of using the SRV record to locate an XKMS service. In order to send a message to bob@xyzcorp.com, Alice’s e-mail client first uses the DNS system to look up the SRV record that specifies the address of the XKMS service for XYZ Corp, which in this case is pki1.xyzcorp.com.
Trusting X-KISS Validate Services
A validate service is a trusted service. In order to rely on the information supplied by the validate service, it must be authenticated in some way. This leads to the question of how the client validates the authentication key of the validate service.
At present, the deployed XKMS services typically use an X.509 certificate to authenticate messages from the service. This solution is clearly not optimal, however, because one of the objectives of XKMS is to allow clients to make use of a PKI without having to manage X.509 certificates.
At present, there is no standards group addressing this problem; however, a research paper outlining a possible solution has been published, and it is likely that a working group will be formed as soon as the XKMS 2.0 specification is completed.
XML Key Registration Service Specification
The X-KRSS protocol is used to establish and manage public key credentials. X-KRSS supports four services—register, recover, reissue, and revoke—which together allow the lifecycle of the public key credential to be managed from initial creation through to expiry or revocation.
Just as the X-KISS service allows applications to issue queries for any type of PKI credential through the abstract XKMS key binding concept, X-KRSS allows an application to manage any type of credential through the same key binding concept. Managing key bindings rather than the credentials themselves allows the application to be independent of the underlying PKI.
For example an e-mail client might register a public key to be used with S/MIME secure e-mail. The register service might then, in turn, create a certificate so that other S/MIME users could send encrypted mail to the user but the client itself need not be aware that this took place.
Authentication
Management of public keys requires a strong means of identifying the party requesting the particular operation. If Bob is going to trust the information registered with the service as Alice’s public key, the service had better provide some degree of assurance that the key really does belong to Alice. Similarly if a service receives a request from “Alice” requesting that her information be modified in some way, or possibly revoked, the service had better first check that “Alice” really is the Alice intended.
This type of authentication problem is, of course, precisely the type of application for which PKI would normally be the solution. There is a problem however, Alice cannot be expected to use a public key to authenticate her first request for a public key. For this reason X-KRSS provides two basic means of authenticating requests, by means of a digital signature and by means of a one time use pass phrase. A digital signature is used for all requests made by operators or administrators who are managing another user’s keys. The one time use pass phrase is used to identify the user in circumstances such as initial registration, where the user does not yet have a public key established.
A one time use pass phrase is similar to a password except that, as the name implies, it is intended to be used only once. As such it does not matter whether it is easy to remember or not. The one time use pass phrase is issued “out of band”, that is outside the channels that are described by the XKMS specification. The security of the out of band communication method will largely determine the strength of authentication achieved.
The strongest form of authentication for normal use would be for the administrator of the register service to meet the applicant in person and verify their identity by means of government-issued documents such as a driver’s license and passport. This level of authentication is not usually practical, however, and so in large enterprises where “in-person” authentication is required, the task of authentication is typically delegated to either managers or secretaries.
In many applications, however, it is perfectly acceptable to simply send the pass phrase to the registrant by e-mail. While the e-mail might be intercepted and read on its way to the intended user, knowing the pass phrase would only allow the attacker to register a bogus key pair for the user, it would not allow the attacker to fool the user into using the bogus key pair, nor would it allow the attacker to obtain the private key. It is very likely that the attack will be quickly discovered since the legitimate recipient of the pass phrase will be unable to register a key.
In addition the revoke service has its own additional form of authentication which is used exclusively for revocation operations.
Register
The first step in the life cycle of a key binding is registration. The client specifies the information it wants to bind to a public key. The client may ask the register service to generate the public key pair to be registered or cause the public key pair to be generated itself.
For example, Alice wants to use S/MIME to secure her e-mail. She meets the administrator of the register service in person and is handed a one time use pass phrase in a sealed envelope. When she returns to her desk, she tells her client to register a new key pair and enters the pass phrase for authentication. The register service verifies that the pass code is the same one that the administrator issued to Alice, and if the match is correct, the key binding is generated and registered.
| Tip | When designing an authentication mechanism for an XKMS register service, consider how the user might be authenticated with the minimum of inconvenience. |
Client Key Generation
Client-side key generation avoids the need for the private key to be disclosed to the register service and is therefore to be preferred whenever possible. Client-side key generation is particularly desirable in applications where the user is going to use the private key to sign documents and might be tempted to claim that a service that had access to the key during registration had secretly copied the key and then used it to make unauthorized signatures.
Service Key Generation
In some cases client-side key generation is impossible or impractical. Increasingly, private keys are being embedded in hardware devices such as smartcards, network interface devices, and CPUs during manufacture. Most devices are not capable of generating public key pairs in a time short enough to be acceptable to the operators of the assembly lines.
| Tip | Many PKI applications use separate keys for signing and encryption even though public key algorithms such as RSA allow the same key to serve both purposes. Separating the cryptographic uses of the key allows the encryption key to be escrowed without requiring the signing key to be escrowed. It is also good cryptographic practice, providing protection against certain types of cryptographic protocol attack. |
Using the Register Service
A register request contains a prototype for the key binding to be issued, an authentication element and in the case of a client-side generated key pair, a proof of possession element. The proof of possession element prevents an attacker from registering another person’s public key in their name, which would allow them to claim that documents signed by the genuine key holder were theirs. If the register operation is successful, the response contains the key binding(s) that resulted, and in the case of a service-generated key pair, the encrypted private key. These elements are shown in Table 8-8.
| Request Element | Description |
|---|---|
| PrototypeKeyBinding | Specifies the key binding to be registered |
| Authentication | Additional information used to authenticate the request |
| ProofOfPossession | Proof that the request was authorized by the party that holds the private key corresponding to the specified public key |
| Response Element | Description |
| KeyBinding | A key binding resulting from or changed by the requested operation |
| PrivateKey | Encrypted private key parameters of a service-generated key pair |
-
If the key generation is client-side, generate the public key pair.
-
Create an XMLTransportSOAP object for the URL of the service.
-
Create an instance of the XKMSRegister object.
-
Send the request to the XKMS object using the send method.
-
Process the response.
The following code fragment shows an example of using the TSIK to locate the certificate corresponding to the specified key name using the VeriSign test service:
public static void RegisterServiceKey(String keyName, String authCode, String revocationCode) throws IOException, XKMSException, NoSuchAlgorithmException, InvalidKeySpecException, Exception { service = "http://interop-xkms.verisign.com/xkms/Acceptor.nano"; XmlTransport transport = new XmlTransportSOAP(new URL(service)); XKMSKeyData data = new XKMSKeyData(new XKMSKeyName(keyName)); XKMSAuthInfo authInfo = new XKMSAuthInfo(revocationCode, authCode); XKMSRegister register = new XKMSRegister(data, authInfo); XKMSRegisterResponse response = register.send(transport); System.out.println("Response status is " + response.getStatus()); if (response.getStatus()) { System.out.println("The key name is " + response.getKeyName()); System.out.println("The public key is " + response.getPublicKey()); System.out.println("The private key is " + response.getPrivateKey()); } }
Recover
PKI allows the confidentiality of data to be protected using ciphers so strong that it would take millions of years to decrypt it using the most powerful techniques in the public cryptanalytic literature. This creates something of a problem if an important data file is encrypted and the private key required to decrypt it is lost for any reason. A key recovery system stores a copy of the private key with a key escrow agent during registration so that it can be recovered if necessary.
| Tip | Even if you do not intend to support the use of a key recovery system in your application, you should carefully consider the consequences of losing a private key and if necessary provide the user with some other means of backing up their private key by themselves such as by storing it on a floppy disk. |
In practice, there are many reasons why recovery of a private key may be necessary. The private key may have been stored in a smartcard or other hardware device that has become lost or broken. The private key may have been encrypted using a pass phrase that the user has forgotten, or the user may have died or been incapacitated for some reason, or the user might withhold the pass phrase out of malice or for purposes of extortion.
Governments in some countries have also promoted mandatory use of key recovery systems in which the key escrow agent is either the government itself or a contractor acting on behalf of the government. Proposals of this nature have raised many questions as to the trustworthiness, in this respect, of governments in general and certain governments in particular. While such public policy considerations are outside the scope of this book, it is important to consider that the civil liberties issues raised by government-mandated key escrow do not eliminate the need for some form of key recovery in PKI deployments intended to support encryption of stored data.
The X-KRSS recover service can only recover private keys if they have been previously escrowed. The necessary key escrow would typically be performed by an X-KRSS register service using the service-generated key option. XKMS does not provide a mechanism for escrow of client-generated keys.
Using the Recover Service
The recover service is very similar to the register service except that the request is made with respect to a preexisting key binding association rather than creating a new one. The user sends an authenticated request to the recover service, which then returns either a refusal or an encrypted private key.
A recover request specifies the key pair to be recovered by means of a key binding element and contains an authentication element. If the recovery operation is successful, the response contains the key binding(s) whose status was changed by the revoke operation and the recovered private key in an encrypted form. These elements are shown in Table 8-9.
| Request Element | Description |
|---|---|
| KeyBinding | Specifies the key binding to be issued or reissued |
| Authentication | Additional information used to authenticate the request |
| Response Element | Description |
| KeyBinding | A key binding resulting from or changed by the requested operation |
| PrivateKey | Encrypted private key parameters of a service-generated key pair |
Reissue
Once a key binding is registered, it may require periodic updating from time to time. This function is supported by the X-KRSS reissue operation.
Although the key binding associations used by XKMS have no predetermined lifespan, the credentials issued by the underlying PKI may. For example, all X.509 certificates contain two date fields—notBefore and notAfter—which define the validity interval of the certificate. An XKMS client that needs access to the renewed certificate may obtain it by means of the reissue request.
Using the Reissue Service
The reissue service is very similar to the register service except that the request is made with respect to a preexisting key binding association rather than creating a new one. The user sends an authenticated request to the reissue service, which returns either a refusal or the reissued key binding information.
A reissue request contains the same information that is provided in a register request, the key binding to be reissued, an authentication element, and a proof of possession for the private key. If the operation is successful, the response contains the reissued key binding. These elements are shown in Table 8-10.
| Request Element | Description |
|---|---|
| KeyBinding | Specifies the key binding to be reissued |
| Authentication | Additional information used to authenticate the request |
| ProofOfPossession | Proof that the request was authorized by the party that holds the private key corresponding to the specified public key |
| Response Element | Description |
| KeyBinding | A key binding resulting from or changed by the requested operation |
Revoke
The X-KRSS revoke service revokes a previously registered key binding association and any cryptographic credentials that are associated with it. Revoking a key binding association means that it is no longer considered trustworthy and that it should no longer be relied upon by applications.
A key binding association may be revoked for many reasons: the private key may have been disclosed or otherwise compromised, it may be discovered that a mistake was made during the authentication process and the credential was issued to an impostor, or the user may simply have changed jobs so that the statements made in the credential are no longer valid.
Using the Revoke Service
To use the revoke request, the client sends a revoke request that identifies the key bindings to be revoked. The service must determine whether the request comes from a party authorized to revoke the key binding.
In most cases, the key holder is one of the parties authorized to revoke their key binding in case they compromise the private key by disclosing it or losing a hardware token it might be stored on. This raises the same problem we saw in the registration service—how to authenticate a user who has lost control of their private key.
XKMS addresses this problem by allowing the user to specify a special revocation identifier when the key binding is registered. The revocation request is then authen- ticated using the corresponding revocation code. The revocation code and revocation code identifier are generated using a one-way hash function so that the revocation code identifier can be calculated from the revocation code, but not vice versa.
For example, if the original revocation pass phrase was “Have A Banana,” the revocation code would be H1 (“haveabanana”) and the revocation code identifier would be H2 (H1(“haveabanana”) ) where H1 and H2 are both one-way functions.
In addition, there would usually be other parties authorized to revoke a key binding, such as a system administrator. In these cases, the revocation request would typically be authenticated by means of a digital signature created using the private key of the party requesting the revoke operation.
A revoke request specifies the key binding to be revoked and contains either an authentication element or a revocation code. If the revoke operation is successful, the response contains one or more key bindings that reflect the changed status. These elements are shown in Table 8-11.
| Request Element | Description |
|---|---|
| KeyBinding | Specifies the key binding to be reissued |
| Authentication | Additional information used to authenticate the request |
| RevocationCode | The revocation code value that generates the revocation code identifier value specified during registration |
| Response Element | Description |
| KeyBinding | A key binding resulting from or changed by the requested operation |
|
