This section describes some of the cryptographic algorithms (or lack thereof) that are supported by XKMS and related XML elements. Clearly, a client must be assured that any response it receives which appears to be from an XKMS service actually comes from that service, has not been altered in transit, and is sent in response to the actual request submitted by the client. XKMS leaves the method of achieving such assurances up to the application, but recommends that it be built on one of the following:
In general, to avoid circularity, all of these choices require some preinstalled keying information at the client or a shared secret between the client and server as described later in this section. 14.4.1 Shared Secret DataAs part of an initial, bootstrap, or recovery operation, it is frequently necessary to provide some limited-use, one-time pass phrase or the like for human input. In some cases, this pass phrase will be read over a telephone line. XKMS policy states that when such strings are used, they must be encoded as XML, all space and control characters must be removed, and all upper case Latin-1 alphabetic ("A" to "Z") characters must be converted to lowercase characters [XKMS]. Other characters, included accented characters, are neither removed nor converted. Keying material is derived from shared secret data such as a pass phrase using HMAC with a one-byte key, as listed in Table 14-3.
xkms:PassPhraseAuth ElementThe PassPhraseAuth element contains a plain text, limited-use, shared secret pass phrase to authenticate a request. It has the following schema: <element name="PassPhraseAuth" type="string" minOccurs="0"/> xkms:KeyBindingAuth ElementYou use the KeyBindingAuth element to authenticate a KeyBinding using a previously established key, possibly one based on a shared secret pass phrase. It provides a signature over the KeyBinding element for the public key being registered. <element name="KeyBindingAuth" minOccurs="0"> <complexType> <sequence> <element ref="xmldsig:Signature" minOccurs="0"/> </sequence> </complexType> </element> 14.4.2 Registration of User-Generated KeysYou use the AuthUserInfoType element type to prove that a client is authorized to register a key. Depending on the server policy, it may contain a KeyBindingAuth element and/or PassPhraseAuth element (both of which were defined earlier) and/or a ProofOfPossession element (defined in this section). The schema for AuthUserInfo follows: <complexType name="AuthUserInfoType"> <sequence> <element name="ProofOfPossession" minOccurs="0"> <complexType> <sequence> <element ref="xmldsig:Signature" minOccurs="0"/> </sequence> </complexType> </element> <element name="KeyBindingAuth" minOccurs="0"> <complexType> <sequence> <element ref="xmldsig:Signature" minOccurs="0"/> </sequence> </complexType> </element> <element name="PassPhraseAuth" type="string" minOccurs="0"/> </sequence> </complexType> xkms:ProofOfPossession ElementThe ProofOfPossession element contains an XML digital signature over a KeyBinding using the private key corresponding to the public key being registered by that KeyBinding. Thus it constitutes proof that someone with knowledge of that private key constructed the KeyBinding. The recipients can satisfy themselves on this point by verifying the ProofOfPossession signature using the public key in the signed KeyBinding. The schema for ProofOfPossession follows: <element name="ProofOfPossession" minOccurs="0"> <complexType> <sequence> <element ref="xmldsig:Signature" minOccurs="0"/> </sequence> </complexType> </element> 14.4.3 Registration of Server-Generated KeysA client uses the AuthServerInfoType when the service generates the keys. Depending on the server policy, the client may be required to provide a KeyBindingAuth and/or PassPhraseAuth element (both of which were defined earlier). The service must return the generated private key to the client in the Private element. See the "RSA Key Pairs" section for information about structure and encryption considerations. The schema for the AuthServerInfoType follows: <complexType name="AuthServerInfoType"> <element name="KeyBindingAuth" minOccurs="0"> <complexType> <sequence> <element ref="xmldsig:Signature" minOccurs="0"/> </sequence> </complexType> </element> <element name="PassPhraseAuth" type="string" minOccurs="0"/> </complexType> RSA Key PairsIf the registration service generates a public/private key pair, it must be able to convey the private key to the client. The schema below is defined for this purpose. The XKMS Note [XKMS] also specifies a method for encrypting this structure for return to the client. This method is not given in this book, as it will likely be replaced by the XML Encryption Recommendation (see Chapter 15). <element name='RSAKeyPair'> <complexType content='elementOnly'> <all> <element name='Modulus' type='xmldsig:CryptoBinary' minOccurs='1' maxOccurs='1'/> <element name='PublicExponent' type='xmldsig:CryptoBinary' minOccurs='1' maxOccurs='1'/> <element name='PrivateExponent' type='xmldsig:CryptoBinary' minOccurs='1' maxOccurs='1'/> <element name='P' type='xmldsig:CryptoBinary' minOccurs='0' maxOccurs='1'/> <element name='Q' type='xmldsig:CryptoBinary' minOccurs='0' maxOccurs='1'/> <element name='DP' type='xmldsig:CryptoBinary' minOccurs='0' maxOccurs='1'/> <element name='DQ' type='xmldsig:CryptoBinary' minOccurs='0' maxOccurs='1'/> <element name='QINV' type='xmldsig:CryptoBinary' minOccurs='0' maxOccurs='1'/> </all> </complexType> </element> |