search

Doichain / dapp

Doichan dApp - a Meteor.js implementation of the "Doichain Atomic Double-Opt-In" Protocol
https://www.doichain.org
MIT License
6 stars 6 forks source link

Modify REST-API call "verify" - provide interface for postfix smtp-filter #102

Open silkroadnomad opened 5 years ago

silkroadnomad commented 5 years ago

As described in #101 , the verify call needs to be extended and should check if the local dApp has verifiable local data which have a valid permission (correct signatures) inside the blockchain.

In case the local database doesn't hold nameId and or public_key of Alice, we must either purely rely on the local data or find a way to gather or save public_key of Alice in order to decrypt the signatures inside Doichain. Please lets further discuss this issue here!

Please see https://bounties.doichain.org/ how to apply for Doichain bounties.

silkroadnomad commented 5 years ago

As I found out today, Alice did never send any sender email address to Bob yet. Which is good. So Bob (and any fallback server) didn't really know about which email addresses in detail he his giving the permission. He just signs it. That was a pretty good (and necessary) practice so far.

In case Bob (validator dApp) is the authorized or delegated (Public-Key in DNS-TXT value) send-dApp of Peter (Recipient) it is acceptable that Alice sends the sender email address to Bob (which he can also store in the local dApp).

In case Bob is a fallback server. We don't change the behavior here. Fallback server should not know anything about who receives the permission in order to prevent data leaks.

silkroadnomad commented 5 years ago

Please write Test, which proves that fallback servers do not store any hashes / alice doesn't give any hashes to fallback nodes.

silkroadnomad commented 3 years ago

It is also in dispute if Alice (Send - dApp) should generate a "temporary" Private and PublicKey pair for each recipient which probably just get lost in future. https://github.com/Doichain/meteor-api/blob/master/imports/modules/server/recipients/add.js#L19

It is demonstrated inside the doiContact wallet https://github.com/inspiraluna/doiContacts/blob/master/doi_react_app/src/components/ContactForm.js#L135 that we just could use the PrivateKey of Alice (the requester) directly. This has also the advantage, the publicKey doesn't need to be stored somewhere in a database since its anyways visible in the blockchain transaction!

Further on, we recommend now it could be useful, to use a different NameId for storing the soi permission on the blockchain e/.... So far we were always generating and abusing a PrivateKey which would never sign or encrypt anything: https://github.com/Doichain/js-doichain/blob/master/lib/createDoichainEntry.js#L20

here we'd like to make it more intuitive and encrypt a string containing recipientEmail+senderEmail (as we created the SOI signature here https://github.com/Doichain/js-doichain/blob/master/lib/createDoichainEntry.js#L22) and use this encrypted string as nameId! See: https://github.com/inspiraluna/doiContacts/issues/98