+

Search Tips   |   Advanced Search

XML digital signature


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 spec was developed jointly by the World Wide Web Consortium (W3C) and the IETF.

There is an important distinction between V5.x and Version 6 and later applications. The information in this article supports Version 5.x applications only that are used with WAS V6.0.x and later. The information does not apply to V 6 and later applications.

XML signature does not introduce new cryptographic algorithms. WAS uses XML signature with existing algorithms such as RSA, HMAC, and SHA1. XML signature defines many methods for describing key information and enables the definition of a new method. XML canonicalization (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 canonicalize XML information. Select an appropriate c14n algorithm because the information that is canonicalized is dependent upon this algorithm. One of the major c14n algorithms, Exclusive XML Canonicalization, canonicalizes the character encoding scheme, attribute order, namespace declarations, and so on. The algorithm does not canonicalize white space outside tags, namespace prefixes, or data type representation.

 

XML signature in the WS-Security-Core spec

The WS-Security-Core (WSS-Core) spec defines a standard way for SOAP messages to incorporate an XML signature. Use almost all of the 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. The KeyIdentifier is the value of the SubjectKeyIdentifier field within the X.509 certificate.

See on the KeyIdentifier, see “Reference to a Subject Key Identifier” within the OASIS WS-Security X.509 Certificate Token Profile documentation. By including XML signature in SOAP messages, the following are realized:

Message integrity

A message receiver can confirm that attackers or accidents have not altered parts of the message after these parts are signed by a key.

Authentication

We can assume that a valid signature is proof of possession. A message with a digital certificate issued by a certificate authority and a signature in the message that is validated successfully by a public key in the certificate, is 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 WS-Security, however, an API (API) is not available. The current implementation has many hardcoded behaviors and has some user-operable configuration items. To configure the client for digital signature, see Set the client for response digital signature verification: Verifying the message parts. To configure the server for digital signature, see Set the server for request digital signature verification: Verifying the message parts.

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. Processing both messages can cause damage to the receiver if the message is a claim for money. If we have the signed generation time stamp and the signed expiration time in a message replay, attacks might 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. In WAS, V 5.1, nonce is supported in username tokens only. The username token profile contains concrete nonce usage scenarios for username tokens. Applications handle nonces (such as serial numbers) and they need to be signed.


Subtopics


Signing parameter settings

 

Related tasks


Set the client for response digital signature verification: verifying the message parts
Set the client for response digital signature verification: choosing the verification method
Set the server for request digital signature verification: Verifying the message parts
Set the server for request digital signature verification: choosing the verification method
Secure Web services for V5.x applications based on WS-Security

 

Related information


Exclusive XML Canonicalization