generating electronic and paper based credit requests
XML Encryption is a specification, governed by a W3C recommendation, that defines how to encrypt the contents of an XML element. Although XML Encryption can be used to encrypt any kind of data, it is nonetheless known as "XML Encryption" because an XML element (either an EncryptedData or EncryptedKey element) contains or refers to the cipher text, keying information, and algorithms.
However, it is beyond the scope of this documentation to explain all details of a encryption or the encryption process. Detailed information about all aspects of encryption can be found at W3C.
|Boundary conditions and critical aspects|
- the encryption is optional!
- if an infoset is encrypted then the public certificate of the recipient must be used and this certificate is applied to the body element.
Here recipient is used in terms of the communication and therefore is defined as the EAN entity given in the transport@to attribute
- the namespace v1 of W3C http://www.w3.org/2001/04/xmlenc must be used- cf. XML Encryption Syntax and Processing
- The encryption algorithm is fixed to PKCS1 (RSA-SHA1) (RFC 2437: RSA Cryptography Specifications)
- The block encryption algorithm is fixed to Triple DES
The generalCreditRequest module does obey all these conditions whenever encryption is "turned on" by setting a public certificate of the "toEAN" entity (cf. IGeneralCreditRequest::SetTransport). This certificate must be in the format "binary DER".
Where do I get this certificate?
The request/response system is self-contained insofar as the generalCreditResponse module (or any other V4.3 module!) extracts the public certificate of a signed response XML infoset and generates 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!