(http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/).XML-Signature Syntax and Processing (XML signature) is a specification that defines XML syntax and processing rules to sign and verify digital signatures for digital content. The specification was developed jointly by the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF).
XML signature does not introduce new cryptographic algorithms. WebSphere Application Server - Express uses XML signature with existing algorithms such as RSA, HMAC, and SHA1. XML signature defines many methods for describing key information and enables a new method to be defined.
XML cannonicalization (c14n) is often needed when you use XML signature. Information can be represented in various ways within serialized XML documents. For example, although their octet representations are different, the following examples are identical:
C14n is a process used to cannonicalize XML information. Select an appropriate c14n algorithm because the information that is cannonicalized is dependent upon this algorithm. One of major c14n algorithms, Exclusive XML Canonicalization, canonicalizes the character encoding scheme, attribute order, namespace declarations and so on. The algoritm does not canonicalize whitespace outside tags, namespace prefixes, or data type representation. For more information, see Exclusive XML Canonicalization (http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/).
XML Signature in Web Services Security-Core
The Web Services Security-Core (WSS-Core) specification defines a standard way for SOAP messages to incorporate an XML Signature. You can use almost all of th XML signature features in WSS-Core except enveloped signature and enveloping signature. However, WSS-Core has some recommendations such as exclusive canonicalization for the c14n algorithm and some additional features such as SecurityTokenReference and KeyIdentifier.
By including XML Signature in SOAP messages, the following goals are realized:
Message integrity
A message receiver can confirm that attackers or accidents have not altered parts of the message after they were signed by a key.
Authentication
You can assume that a valid signature is proof of possession. If a message has a digital certificate that is issued by a certificate authority and a signature in the message is validated successfully by a public key in the certificate, it is a proof that the signer has the corresponding private key. The receiver can authenticate the signer by checking the trustworthiness of the certificate.
XML signature in the current implementation
XML signature is supported in Web services security, however, an API is not available. The current implementation has many hard-coded behaviors and has some user-operable configuration items. To configure the client for digital signature, see Configure the client for response digital signature verification. To configure the server for digital signature, see Configure the server for request digital signature verification.
Security considerations
In a replay attack, an attacker taps the lines, receives a signed message, and then returns the message to the receiver. In this case, the receiver receives the same message twice and might process both of them if the signatures are valid. It can cause damage to the receiver if the message is a claim for money. If you have the signed generation time stamp and the signed expiration time in a message replay attacks may be reduced.
However, this is not a complete solution. A message must have a nonce value to prevent these attacks and the receiver must reject a message that contains a processed nonce. The current implementation does not provide a standard way to generate and check nonces in messages. Applications should handle nonces (such as serial numbers) and they should be signed.