Verify Signature of TPP with QSEALC

[ranganapeiris]

Hi mate,

In this repository, do you have the functionality to verify the signature of a TPP (Third Party Payment Provider) given I got the public signing certificate (QSEALC)?

Because in our PSD2 compliant API's we want to verify the ownership of the request with the signature of TPP (TPP have to send a signed body for POST requests as a header).

Regards Rangana

[yuriylesyuk]

right now there is no certificate validation code or checks, even that the problem was defined at day one of this project.

It is not hard to add a code that validates the path. for example, see here https://docs.oracle.com/javase/8/docs/technotes/guides/security/certpath/CertPathProgGuide.html#BuildingClasses

buuut. in a generic sense, the validation process is non-trivial combination of different checks. see here:

https://en.wikipedia.org/wiki/Certification_path_validation_algorithm

our PSD2 compliant API's we want to verify the ownership of the request with the signature of TPP

that's the tricky part. right now there is no consensus of PSD2/OB specifications what the check would comprise. To implement everything possible would be a lot of work without proper justifications.

For example, for ocsp checks, some companies set up their own ocsp responder cache for production, some use crls to cache it, some use nginx or other server to execute path validation checks...

It is hard to capture useful common functionality.

I am happy to collaborate with you to add the code if you have specific functional requirements and a set of test cases.

[acobat]

Hi @yuriylesyuk and @ranganapeiris

I think @ranganapeiris talking about the QSEAL signature validation on incoming data, in the Berlin Group you have to sign with QSEAL (we have QSEAL \ QWAC) certificates, and with help of QSEAL you will sign the incoming JSON payload data, and hash of that data, that were signed, will be validated on other side with QSEAL public key of that TPP:

The "signature" parameter is a base 64 encoded digital signature, as described in RFC 4648 [RFC4648], Section 4. The client uses the algorithm and headers signature parameters to form a canonicalised signing string. This signing string is then signed with the key associated with keyId and the algorithm correspondingto algorithm. The signature parameter is then set to the base 64 encoding of the signature.

Example data: { "instructedAmount": {"currency": "EUR", "amount": "123"}, "debtorAccount": {"iban": "DE2310010010123456789"}, "creditor": {"name": "Merchant123"}, "creditorAccount": {"iban": "DE23100120020123456789"}, "remittanceInformationUnstructured": "Ref Number Merchant" }

Then, you need to base64 this:

eyAgICANCiAgICJpbnN0cnVjdGVkQW1vdW50IjogeyJjdXJyZW5jeSI6ICJFVVIiLCAiYW1vd W50IjogIjEyMyJ9LA0KICAgImRlYnRvckFjY291bnQiOiB7ImliYW4iOiAiREUyMzEwMDEwMD EwMTIzNDU2Nzg5In0sDQogICAiY3JlZGl0b3IiOiB7Im5hbWUiOiAiTWVyY2hhbnQxMjMifSw NCiAgICJjcmVkaXRvckFjY291bnQiOiB7ImliYW4iOiAiREUyMzEwMDEyMDAyMDEyMzQ1Nj c4OSJ9LA0KICAgInJlbWl0dGFuY2VJbmZvcm1hdGlvblVuc3RydWN0dXJlZCI6ICJSZWYgT nVtYmVyIE1lcmNoYW50Ig0KfQ==

Finally, SHA-256 of the request body is F9li3V7yu8S/QKVOhWiiiqJBhGMVId8UGZ4sBRVPkok=in Base64 ('17D962DD5EF2BBC4BF40A54E8568A28AA24184631521DF14199E2C05154F9289' in hexadecimal representation).

In the request it will look like: Digest: SHA256=ZuYiOtZkVxhjWmwTO5lOpsPevUNMezvk6dfb6fVhebM= Signature: keyId="SN=9FA1,CA=D-TRUST%20CA%202-1%202015,O=DTrust%20GmbH,C=DE",algorithm="rsa-sha256", headers="Digest X-Request-ID PSU-ID TPP-Redirect-URI Date", signature="Base64(RSA-SHA256(signing string))" TPP-Signature-Certificate: TPP's_eIDAS_Certificate

So I guess @ranganapeiris asking if there's such functionality on other side for validating the hash with Digest.