Re: [Taler] transaction state/history; fulfillment

[Christian Grothoff]

On 01/07/2016 09:02 PM, Florian Dold wrote:
> On 01/07/2016 08:28 PM, Christian Grothoff wrote:
>> I don't think offer from the merchant becomes any less binding, it
>> should be just as binding as before, as once the consumer
>> accepted&paid, the merchant cannot go back on the offer.  Adding a
>> signature by the merchant really just makes it easier for the
>> customer to prove that he did indeed accept&pay on time, without
>> needing the help of the mint. Regardless, the key issue here is
>> that there is no acceptable PKI for the merchants to make such
>> signatures meaningful, so we certainly cannot require this
>> _always_.
> 
> There might not be a PKI, but we *always* have a merchant public key
> in the contract right now anyways.

Yes, but that key is only used to enable the merchant to refund the
contract and to query the mint for when/how the payment was executed.
That is fine, as whoever created the contract can just make up a key here.

But the merchant's signature on the contract is legally worthless:
anyone can just make up any public key here. The only thing that helps
is that you got the contract via a trustworthy channel (i.e. TLS or NFC)
from a trustworthy store (as evidenced by DNS or physical visit).

>> And even in the cases where there is a PKI, this gets really messy
>> to implement (try hacking the backend to take the server's private
>> TLS keys to sign the contract, and then hack the wallet to grab the
>> server's public TLS keys to verify the contract, and store the
>> certificate chain; yes, it can be done, but it's MESSY.).
> 
> I'm not saying it's easy, but it's probably not as hard as you make it
> out to be in that paragraph.  Essentially we could couple the Taler
> merchant key pair to the existing TLS PKI by having a /merchant/keys
> page that is delivered over TLS and simply gives the wallet the Taler
> merchant key(s). 

Nope, doesn't suffice, as the customer can always claim that key X was
the merchant key, and the merchant can claim he was using a different
key Y.  TLS does not give us something where we could go to court and
definitively prove that we downloaded X from site Z at time T.  If that
were the case, you could just keep that information for the "200 OK"
from the merchant.

> That doesn't sound too messy to me (of course TLS is
> a mess, but that's out of our scope here).
> 
>> So let's leave something to handle a special corner case that is
>> optional + messy for Taler 2.0.
> 
> I'm all for keeping things simple, but I don't think having this one
> extra signature by the merchant (just with the same key that was used
> in the contract) complicates things too much.  Am I missing some
> complication here?

Yes, you oversimplify what it'd take to abuse the X.509 PKI here.

> While I agree that we might leave the merchant PKI to Taler 2.0, I do
> think that we should still have the fulfillment signature, and leave
> it for future extensions to couple/integrate it to/with some PKI.

Well, we could add a fulfillment sig as you propose based on the
merchant key, and then just clarify that it is legally useless
until/unless the merchant pub is properly authenticated via some PKI,
and that the wallet currently doesn't even support that.  That's fine,
easy to do and would minimize the changes if we later do add some kind
of PKI support for merchants.

> Especially since it doesn't cost us a lot now, but the cost of
> migrating the protocol later might be quite high.

As long as we document that this is in preparation for a future
extension and not meaningful today.

> What is the harm in having the fulfillment signature right now, which
> might be ignored by current wallets, but that might be used by future
> wallets that provide merchant PKI support?

Just need to clarify the limitations in the documentation. Otherwise, I
agree that it's so simple that it shouldn't hurt.

signature.asc
Description: OpenPGP digital signature