The Signature Method
The next step involved in creating the digest is tracking and specifying the actual method used to create the signature (denoted by the <> element). After the canonical version of the XML is derived, the data that is part of the <> element desires to be converted into the actual signature value (and placed in the "SignatureValue" element). The "SignatureMethod" element specifies the algorithm that will be used for this operation.
The algorithm which is used to create the signature and, finally, the signature itself, are specified in the "SignatureMethod" tag and "SignatureValue" tag:
In this example segment, when the receiver gets the message, the signature is decrypted using the sender’s public key, the verified digest, and by verifying the sender’s signature. Who has to provide the Key information? In the following listing, the " KeyInfo " element holds the decryption key:
Here note that the XML signature doesn’t address trust of such key information. Then it is responsibility of whom? Generally, the application has to determine how trustworthy the key is. But for there is another way to verify that the supplied decryption key does belong to the sender, there is little point to the process. Anyone could intercept the message, change its contents, regenerate a public/private key pair, and re-sign the document. This will assert the public key belongs to the sender. This is the place; where the digital certificates come into the picture.
The certificate contains the binding between the identity of the public key’s owner and the key itself. For example, if the is omitted, the recipient is likely to identify the key that will be used, based on the application context. This type of issue is addressed in the XKMS specification, which is discussed in the later. Using XKMS or another PKI infrastructure, the recipient of the message can obtain the digital certificate, extract the public key from it, and verify that this key does belong to the sender.
