Notes about the signature

XML signatures are digital signatures designed for use in XML transactions. The W3C standard defines a schema for capturing the result of a digital signature operation applied to an infoset. XML signatures add authentication, data integrity, and support for non-repudiation to the data that they sign.
However, it is beyond the scope of this documentation to explain all details of a signature or the signing process. Detailed information about all aspects of signatures can be found at W3C.

Boundary conditions and critical aspects

  • the signature is optional!
  • if an infoset is signed then the private certificate of the sender must be used and this certificate is applied to the payload element. This inherently qualifies for a detached signature.

    In this context sender is used in terms of the communication and therefore is defined as the EAN entity given in the transport@from attribute

  • the URI attribute of the reference element must use a XPointer syntax of the payload element, e.g. <ds:Reference URI="#xpointer(/credit:response/credit:payload)">
  • it is recommended to add the public key via a X509Data element such that a key store can be built at the recipient's site
  • The signature algorithm is fixed to PKCS1 (RSA-SHA1) (RFC 2437: RSA Cryptography Specifications)
  • The digest algorithm is fixed to SHA-1
  • the used canonicalization algorithm must be, the exclusive XML Canonicalization

The generalCreditResponse module does understand these boundary conditions. If the response XML is signed then the module extracts the X509Data element and transforms it to a binary DER format. Using the certificate the signature chain is checked. The IGeneralCreditResponse::GetTransport method returns a binary DER file named X509DER_from_EAN.cer. This is exactly the certificate to use for encrypting a credit (or all other V4.3) request XML infosets!