search

e-clearing-net / OCHP

Open Clearing House Protocol
http://ochp.eu
MIT License
50 stars 33 forks source link

Extend EmtId in order to support end2end encryption / additional data #44

Open the-infinity opened 4 years ago

the-infinity commented 4 years ago

At the moment EmtId has an instance field with an maximum of 512 chars. If it comes to secure token which are part of a PKI + have signatures or with other cryptographic verifications, this is not enough. This issue gets worse if it comes to end2end encryption (because strings will get longer in this case).

The easiest way of solving this is to extend the instance field to 2048 or even 4096 chars. Another idea would be to add an optional field meta with 2048 or 4096 chars which could be used to store additional data like PKIs + signatures or end2end encrypted.

Background: this will get quite relevant if it comes to the ongoing standardisation process of secure RFID tokens - and it is already an issue when it comes to direct payment by EMV based cards.

simonschllng commented 4 years ago

We should discuss how to implement the secure tokens. I suppose to make a workshop for it.

ahzf commented 4 years ago

I think it will not make any sense to send public keys + certificates. It would lead to GDPR issues anyway. What you want to store is the result of some authentication verification that you also know the private key. And this can be much shorter.

the-infinity commented 4 years ago

For validation purposes I think it's a good idea to give the ability to send the signature and the public key. And if you want to do end2end encryption of any token data (for example because you want to respect GDPR) you have longer strings anyway (which you can't split up in different fields because they are encrypted).

So I think extending the max string length does no harm, nobody has to use it, but it makes things like end2end encryption possible. And for any further details / fields, I think it's a good idea to make a workshop as @simonschllng suggested.