To create a digital signature:
1. Apply the transform or transforms to the data object to be signed. Transforms are applied in the order they are specified.
2. Calculate the message digest of the output of the transforms.
3. Create a reference element that includes the URI of the data object (optional), the transforms used, the digest algorithm, and the digest value. As many refer- ence elements as needed may be created. This occurs if one signature covers several nodes of the document.
4. Create the SignedInfoelement. Include the SignatureMethod, the Canonicalization- Method, and the references previously generated.
5. Apply the CanonicalizationMethodto SignedInfo.
6. Use the algorithms specified by SignatureMethodto create the signature. This usually means applying a message digest algorithm to the canonicalized SignedInfo and then signing the resulting digest.
7. Create the Signatureelement that contains the SignedInfo, the SignatureValue,
KeyInfo(if needed), and Object(if needed).
8. Note that a different canonicalization algorithm or message digest algorithm can be applied to each referenced element.
To verify a signature:
1. Canonicalize the SignedInfoelement according to the CanonicalizationMethod
specified in SignedInfo.
2. For each reference element, obtain the data object referenced. 3. Process each data object according to the specified transforms.
4. Digest the result according to the digest algorithm specified for the referenced element. Compare the result with the value stored in the corresponding refer- ence element. If the two are not equal, the verification fails.
5. Obtain the necessary keying information. It may be available in KeyInfo, or it may have been preplaced.
6. Apply the signature method using the previously obtained key to confirm the
SignatureValueover the canonicalized SignedInfoelement.
Example
The following code fragment is an example of an XML signature. This is called a detached signature because it is not part of the document being signed. Signa- tureMethod specifies the signature algorithm and the message-digesting algorithm, DSA and SHA-1, respectively. That XML Canonicalization used to transform the input is also specified. The actual data being signed is identified by the URI attribute of Ref- erence. In this case, there is only oneReferenceelement, and it identifies a separate doc- ument called order. The message digest applied to the document, SHA-1, and the transformation, XML Canonicalization, applied to the document are child elements of reference. DigestValuecontains the SHA-1 message digest of the order. SignatureValueis calculated based on SignedInfo. Finally, the DSA public key, that can be used to verify the signature, is appended. Note that if there were several data items being signed, each of them could have its own canonicalization and message digest algorithms. The signature itself could also be calculated using a different message digest algorithm. Our simple example uses only the public key for verification rather than a public key certificate. This provides minimal security for the signature format, since the receiver of the SOAP message has no way to verify that the holder of the key is the expected individual. If the overhead of a PKI is not acceptable, a better way to handle this is to preplace the public key with the receiver and reference the key in the message.
<Signature xmlns=”http://www.w3.org/2000/09/xmldsig#”> <SignedInfo> <CanonicalizationMethod Algorithm=”http://www.w3.org/TR/2001/REC- xml-c14n-20010315”/> <SignatureMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#dsa- sha1”/> <Reference URI=”http://www.mycompany.com/order/”> <Transforms> <Transform Algorithm=”http://www.w3.org/TR/2001/REC-xml- c14n-20010315”/> </Transforms> <DigestMethod Algorithm=”http://www.w3.org/2000/09/xmldsig#sha1”/> <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference> </SignedInfo> <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>
<KeyInfo> <KeyValue> <DSAKeyValue> <P>...</P><Q>...</Q><G>...</G><Y>...</Y> </DSAKeyValue> </KeyValue> </KeyInfo> </Signature>
Issues
There are several topics for consideration when implementing a digital signature sys- tem for Web Services.
Signature syntax vs. semantics. The XML Signature Recommendation deals with the syntax and technical process for creating an XML digital signature. Signa- tures have a meaning from a legal and business point of view. It is important to consider what need the signature meets and then ensure that the signature is being applied to the appropriate parts of the document to satisfy the need. For instance, we may want a secure signature to authorize charging $50 for two shirts. In this case, the signature must cover the charge account number, the amount, and the two shirts. This prevents the account number and the amount from being reused in a different context. In addition, the signature should also include a unique identifier, which will not be used again, to protect against pos- sible replay attacks.
Out-of-band agreements between the signer and the verifier. The XML Signa- ture Recommendation is very flexible and allows many parameters to be omit- ted from the signature. For instance, KeyInfois optional. For the most part, we consider this flexibility a positive feature. However, leaving information out of the signature means that there can be problems with signature verification at a later time or if the verifier changes. In general, including signature parameters in the signature element is preferable.
Choice of algorithms and key lengths. XML Signature does not mandate the use of particular algorithms or key lengths. It is the user’s responsibility to ensure that the right choices are made. The system implementer should carefully con- sider how long the signature must be retained and the preferred algorithm, and then decide on the appropriate key length.
Application in SOAP. XML Signature specifies encryption for XML documents. It does not describe how XML Signature data and structures are implemented within the SOAP message structure.