Line 20 begins the Key Value block and identifies the namespace that we will use — <KeyInfo
xmlns=”http://www.w3.org/2000/09/xmldsig#”>. The Key Value block, <KeyValue> <RSAKeyValue>
</RSAKeyValue> </KeyValue>, is where the Web service requester supplies the Web service provider
with the information they need in order to obtain the key needed to validate the signature. In our
message, the KeyValue element contains the requester’s public key, which will be used to validate
the signature. We have chosen to use an asymmetric RSA (named after the three inventors, Rivest,
Shamir, and Adleman) key-based approach in order to meet our non-repudiation requirement.
The use of the RSA key scheme assures our Web service provider that the message was in the
same form that it was received, and it was signed by the owner of the extracted digital certificate. If
the recomputed digest matches the decrypted digest from the SOAP message, the service provider
is able to verify the integrity of the message. By logging the message before any processing is done
(the log is implemented as the first Apache Axis handler in the handler chain), the Web service
provider can prove that the message in question was sent by whomever signed the message and
that it was received unmodified from the form in which is was sent.
RSAKeyValue elements have two fields:
The RSA scheme uses large prime numbers to construct the key pairs. The Modulus is the product
of two large prime numbers. Each pair shares the Modulus, but each also has a specific exponent.
The RSA Laboratories’ Frequently Asked Questions About Today’s Cryptography, Version 4.1
document (see Resources) describes how the Modulus and the Exponent are created:
“Take two large primes, p and q, and compute their product n = pq; n is the modulus. Choose a
number, e, less than n and relatively prime to (p - 1)(q - 1), which means that e and (p - 1)(q - 1)
have no common factors except 1. Find another number d such that (ed - 1) is divisible by (p - 1)(q
- 1). The values e and d are called the public and private exponents, respectively. The public key is
the pair (n, e); the private key is (n, d).”
The service requester digitally signs the message with their private key. On the service provider
side, the signature is verified using the requester’s public key. Since the service requester signs the
message with a private, asymmetric key, the service provider is assured that the only organization
that could have signed the message is the holder of the private key.
The next section of the Key Info block is the digital certificate itself as indicated by the <X509Data>
element. The digital certificate is used to identify the sender of the message in the way a user ID is
used to identify the user of Web and enterprise applications. The first element in this block of data
identifies the organization that signed the certificate. This is typically the certificate authority. In our case, that information has been replaced with generic information: