Invoices/Payments/Receipts proposal discussion

[metacoin]

I think non-repudiation and other technical side-effects of integrating this protocol with CA signed messages are secondary to the issue at hand.

It is clear that some users of this forum are uncomfortable with the implementation of any solution introducing "centralized" or "trusted" 3rd parties into the Satoshi client. Even though there exists the option to never use this feature, the precedent that's being set is worrisome.

[piotr_n]

Isn't there something like a certificate revocation mechanism, that basically makes your PC to connect to the CA each time you want to use a cert?

[Carlton Banks]

All these "you"s are the person sending the payments request, are they not?

The use of x.509 in the payment protocol is for non-repudiation (which many secure communications channels don't provide, including SSL).

The repudiation issue highlights my concerns, not because websites can send unsolicited payment requests as you allude to, but because the requester is in control of what and how it is sent, not just the circumstances under which they send. You addressed this with an unqualified assertion that:

with one [a secure communications channel] your usage of the payment protocol is secure from privacy or theft attacks even if the x.509 certs aren't secure.

The qualitative security of this secure communications channel is not established my mere virtue of your description of it being suggestively absolute. This is just not a way to establish confidence that such statements are correct.

[Mike Hearn]

But there were several mentions of alternative ways to mitigate MITM problem in this very thread. Is none of them valid ? (I will cite the previous mentions from this thread):

- "Rivest's Interlock Protocol can prevent a man in the middle from altering your communications while allowing you to communicate at all.  At most, he is then reduced to an eavesdropper or able to engage a denial-of-service attack".
- "Bitcoin already has a solid public key infrastructure in that each and every coin is controlled by a public/private key pair.  If you know who owns a coin, you can compose a message to them and encrypt it using that coin's public key".
- "ZRTP: For people seeking trustless key exchange algorithm: it has been already invented (i.e. you can avoid MITM attack without relying on PKI) - ZRTP could be easily adapted to bitcoin payments, changing SAS authentication string to PIN , for example, as it can be only 16 bit number. However, you would have to trust the merchant not to scam you".

Correct. None of them are valid. The interlock protocol does not do what the proposer thinks it does. Read the wikipedia page on it. It's a neat idea but it does not provide authentication. If there's a MITM sitting between you and the merchant, that MITM can rewrite traffic at will.

Bitcoin does not have a public key infrastructure. Using public keys does not mean the same thing as being a PKI. The "infrastructure" part means, how do you know the public key you have corresponds to the entity you think you're communicating with? The last part is tricky because "who you think you're communicating with" is a human, language-based concept, but cryptography works in terms of long random numbers. That's why we need certificates, to join those two worlds.

ZRTP is a method of triggering a Diffie-Hellman key exchange over a VoIP connection. It also isn't any form of authentication mechanism. If you use RedPhone or similar then the assumption is you read out the words you see on your screen, and that the other side checks that the words are the same. It's a neat idea based on the assumption is that a man-in-the-middle like the NSA can't forge your voice. It obviously doesn't work if the two parties don't already know what the other persons voice sounds like, so it's useless for securing a call to (say) a merchant, where you never talked to the salesperson before.

Like Gregory says, authentication and identity are just really hard problems. If you think you found a neat way to avoid all that overhead and hassle by browsing around on Wikipedia, you're probably wrong. Otherwise browser makers would be all over it by now.

[Mike Hearn]

Isn't there something like a certificate revocation mechanism, that basically makes your PC to connect to the CA each time you want to use a cert?

There's a standard protocol for that but AFAIK most systems don't use it, because it would make the revocation servers a central point of failure for the entire web. Typically certs that get revoked (it's rare) end up in a hard-coded list in the browser source code, so they can be checked locally.

Anyway, all the revocation server does is look up the cert in a list and say "yep! it's revoked!". Your browser is free to ignore this and some of them will let you do so. Revocation is really a non issue, CA's don't have any real power to take back a cert they issued beyond issuing a new statement saying, "whoops our bad". And normally this is not controversial (i.e. the SSL keys were stolen).

[piotr_n]

Anyway, all the revocation server does is look up the cert in a list and say "yep! it's revoked!". Your browser is free to ignore this and some of them will let you do so. Revocation is really a non issue, CA's don't have any real power to take back a cert they issued beyond issuing a new statement saying, "whoops our bad". And normally this is not controversial (i.e. the SSL keys were stolen).

Well, the issue is that when I ask the relocation server for a validity of a certain cert, it gets my IP.

[gmaxwell]

I think non-repudiation and other technical side-effects of integrating this protocol with CA signed messages are secondary to the issue at hand.

It's not a "technical side effect" it's what it does. If you don't care about non-repudiation then you don't need to care x.509 certificates in the payment protocol at all.

I'm struggling at trying to figure out your understanding of the payment protocol world. Are you under the impression that CAs would sign payment requests or control private keys? Thats not the case.  Only the requester and the requestee will see the payment requests.  If x.509 is used its used so that when you receive a payment request signed by a particular party your client (and anyone you show the payment request to) can use their certificate to validate that the request was signed by the right party.

The repudiation issue highlights my concerns, not because websites can send unsolicited payment requests as you allude to, but because the requester is in control of what and how it is sent, not just the circumstances under which they send. You addressed this with an unqualified assertion that:

I'm afraid I'm not following you here.

I addressed your concern by saying that it's the requester who controls how non-repudiation is provided and it's the requester who suffers if the non-repudiation is insecure. (Because the consequence of insecure non-repudiation is that a customer can produce cryptographic evidence that vendor ripped them off when they didn't really)

with one [a secure communications channel] your usage of the payment protocol is secure from privacy or theft attacks even if the x.509 certs aren't secure.

The qualitative security of this secure communications channel is not established my mere virtue of your description of it being suggestively absolute. This is just not a way to establish confidence that such statements are correct.

I have no comment on the "qualitative security" of the channel. It's entirely outside of the payment protocol, and you must have it even before a payment request can exist since you'll need to use it to negotiate the request (e.g. to do your shopping). The payment protocol doesn't provide it. Obvious readily available options today include: SSL (with its various limitations), http+tor onion URLs (though how you know you have the right site is another question), or exchanging gpg signed and encrypted payment requests.

Well, the issue is that when I ask the relocation server for a validity of a certain cert, it gets my IP.

AFAIK the payment protocol stuff does not support OCSP. I suspect that it probably shouldn't.

[Mike Hearn]

Well, the issue is that when I ask the relocation server for a validity of a certain cert, it gets my IP.

Yes, back when OCSP was designed, that didn't seem to be a big deal. Wallets don't use it anyway.

You could theoretically design a new version of OCSP that used oblivious set intersection, so although the server would see your IP, it would not see what your query was and thus would learn nothing beyond "someone behind this IP wanted to know the status of some certificate", which isn't a very useful piece of information to have. Or you could query via Tor, etc.

But as I said, revocation is rare. Browsers just have a hard-coded list, and wallets would probably end up the same, if they ever needed to revoke a cert for some reason. Then there's no server at all. Nice and simple.

[metacoin]

It's not a "technical side effect" it's what it does. If you don't care about non-repudiation then you don't need to care x.509 certificates in the payment protocol at all.

I'm struggling at trying to figure out your understanding of the payment protocol world. Are you under the impression that CAs would sign payment requests or control private keys? Thats not the case.  Only the requester and the requestee will see the payment requests.  If x.509 is used its used so that when you receive a payment request signed by a particular party your client (and anyone you show the payment request to) can use their certificate to validate that the request was signed by the right party.

It's a shame my first sentence didn't make any sense, because now I can't edit it. Damn. That's what I get for having 3 hours of sleep and coming in to work early...

I understand what the CA's role is and how the payment protocol works.

I was simply outlining the fact that despite there being a good use-case for this update as well as very small or no technical side-effects, people here are against setting the precedent of implementing code into Bitcoin which necessarily relies on a "trusted" 3rd party, even if that feature is optional.

[Mike Hearn]

It would be great if we could be purists about everything Bitcoin-related being totally zero trust, always, but there often isn't any technical way to do that. That's why we've ended up with centralised exchanges and so on. Some people even use third party wallets or payment processors.

If you believe you found a way to provide the features the PKI provides, except with no third parties, then go right ahead and show us how (in a new thread please). In the absence of such a breakthrough, we roll with the best we've got, which is a protocol in which anyone can sign keys for anyone else, along with a bunch of companies who do a professional job of it "out of the box".

[Carlton Banks]

The repudiation issue highlights my concerns, not because websites can send unsolicited payment requests as you allude to, but because the requester is in control of what and how it is sent, not just the circumstances under which they send. You addressed this with an unqualified assertion that:

I'm afraid I'm not following you here.

I addressed your concern by saying that it's the requester who controls how non-repudiation is provided and it's the requester who suffers if the non-repudiation is insecure. (Because the consequence of insecure non-repudiation is that a customer can produce cryptographic evidence that vendor ripped them off when they didn't really)

Well, you in fact addressed a different concern, one that I do not share. The notional concern that you are talking about is that of generating a proof that a given payment request was instantiated at the users end, such that a webmerchant cannot be accused of sending unsolicited requests to pay.


I will be agonisingly clear. The recipient of a payments request has no way of knowing that a request will be initiated, unless they analyse the code behind every event triggering piece of interface on every payments form on every website they use, every time they use it. The website can choose various ways of utilising the Payments Protocol, for instance using the CA or self-signing. This is all a consequence of the directionality of the request itself. Logically, it can only ever come from the requester. Payee will never request payment from themselves using the Payments Protocol.

Therefore I cannot know whether my personal details are to be signed by a CA until after the event has taken place. This is a concern. If you are saying that this is not a correct description, and that the message is communicated directly between user and merchant using SSL, then please be more explicit in confirming this.

If you're saying that the non-repudiative proof is the only information signed by the CA, then please be more explicit in confirming this.

with one [a secure communications channel] your usage of the payment protocol is secure from privacy or theft attacks even if the x.509 certs aren't secure.

The qualitative security of this secure communications channel is not established my mere virtue of your description of it being suggestively absolute. This is just not a way to establish confidence that such statements are correct.

I have no comment on the "qualitative security" of the channel.

Your own text (bolded) does not constitute such a comment?

[piotr_n]

Well, the issue is that when I ask the relocation server for a validity of a certain cert, it gets my IP.

Yes, back when OCSP was designed, that didn't seem to be a big deal. Wallets don't use it anyway.

Wallets don't use it, but isn't it like: wallets use OpenSSL that uses parent certificates installed in the OS, and it is the OpenSSL+OS that eventually asks the revocation server, without leaving the wallet any control over the actual process?

Sorry - it might be a stupid question, I don't know how it works, so just asking.

[ShadowOfHarbringer]

@gmaxwell, @Gavin Andresen, @Mike Hearn

I have run out of time and Brain-CPU cycles that can be used for this particular discussion, but judging by preliminary analysis of the topic I will (logically) assume you are right.

However i will be closely watching the run of events - If you were wrong, the truth will come out eventually.

[gmaxwell]

I will be agonisingly clear.

Your agonizing clarity is failing me. Sorry.

Therefore I cannot know whether my personal details are to be signed by a CA until after the event has taken place.

Huh. This appears to be word salad. There is no CA signing of any part of a payment request itself. None at all.

Why don't you try to explain to me step by step how you think it works and I'll point out where we are occupying alternative universes.

The only signed data is the request to pay, which is signed by the merchant (when used, it's optional), and the merchants own credentials which are part of a certificate he sends (if he is doing the optional signing).

The notional concern that you are talking about is that of generating a proof that a given payment request was instantiated at the users end, such that a webmerchant cannot be accused of sending unsolicited requests to pay.

No. I'm not talking about that at all.

Nothing stops you from sending unsolicited requests to pay.

A payment request is like an invoice, it forms an agreement "I'll send you the things listed on the payment request, if you pay this amount to these scriptpubkeys." the request can be signed so that you known who its from, and the signature is non-reputable so that if they don't make good on the deal you can show someone the payment request (and the transactions in the blockchain) as evidence that an agreement existed and you kept up your side of the deal.

[Peter Todd]

@gmaxwell, @Gavin Andresen, @Mike Hearn

I have run out of time and Brain-CPU cycles that can be used for this particular discussion, but judging by preliminary analysis of the topic I will (logically) assume you are right.

However i will be closely watching the run of events - If you were wrong, the truth will come out eventually.

Indeed, why bits of the truth will come out every time those sneaky devs do a git push! 

[Carlton Banks]

Therefore I cannot know whether my personal details are to be signed by a CA until after the event has taken place. This is a concern. If you are saying that this is not a correct description, and that the message is communicated directly between user and merchant using SSL, then please be more explicit in confirming this.

If you're saying that the non-repudiative proof is the only information signed by the CA, then please be more explicit in confirming this.

The only signed data is the request to pay, which is signed by the merchant (when used, it's optional), and the merchants own credentials which are part of a certificate he sends (if he is doing the optional signing).

There we are, that's better! If you want to answer the questions I have asked you, but in the form of a response to some other part of the dialog, then I can add the clarity myself by bringing the two together via cut and paste. It makes the conversation appear less intransigent to those that are following it. Why don't you want to answer the question directly? Why is it necessary to use personal sleights in your indirect answer?

The notional concern that you are talking about is that of generating a proof that a given payment request was instantiated at the users end, such that a webmerchant cannot be accused of sending unsolicited requests to pay.

No. I'm not talking about that at all.

Nothing stops you from sending unsolicited requests to pay.

A payment request is like an invoice, it forms an agreement "I'll send you the things listed on the payment request, if you pay this amount to these scriptpubkeys." the request can be signed so that you known who its from, and the signature is non-reputable so that if they don't make good on the deal you can show someone the payment request (and the transactions in the blockchain) as evidence that an agreement existed and you kept up your side of the deal.

My apologies, but you were incomplete in the way that you described your non-repudiative case, the subject of the repudiation was ambiguous. The above more than satisfys a complete description.

"Word salad" is an expression that's used to describe sentences that are logically and/or grammatically obtuse. My sentence made sense, but didn't describe a situation accurately. A little less haughty, please, you are being impolite.

[gmaxwell]

"Word salad" is an expression that's used to describe sentences that are logically and/or grammatically obtuse. My sentence made sense, but didn't describe a situation accurately. A little less haughty, please, you are being impolite.

I'm earnestly confused here— honest to god derpy look on my face confused—, I'm not trying to be snippy or anything at all like that. What you were saying made so little sense to me that I am concerned that I am mis-parsing your english. Your sentenced was, indeed, grammatically sound but ducks inverted my rutabaga.

Talking to someone confused about something, who is loudly angry as a result of the confusion, and is not following a clarification in part because of their anger can be a little frustrating to deal with... but in this case I'm not even frustrated because I can't actually figure out what y'all are thinking.  It's just mystifying to me.

I suspect that you have a very incorrect model in your head of how this stuff works, what the goal is, and what the consequences are... but I can't quite figure out how.  CAs seeing payment requests is basically a martian comment, as it has no semblance to how CAs work (much less how payment requests work), so I know something is wrong. I think I'm reasonably skilled with helping people through misunderstandings, but to do so I first need the start of an idea about what the confused person is thinking.

What I've found works when people have unclear complaints about Bitcoin is I suggest we roleplay.  You are the attacker out to harm people. Tell me what you'll do and what you'll get out of it, and I'll "defend" by telling you why your attack fails (or ask for clarifications for 'attacks' that are too non-specific).

[Carlton Banks]

I see. Your content seems rather concentrated around the way I'm saying something, or the internal workings of my mind, projecting emotional states onto me, or simply diverting from a coherent direction of discourse. I think we'll leave it there, you're appearing to be manipulative as well as impolite.

[Carlton Banks]

Sry for butting in again, how much will the affect the size of the block chain?

It won't. The messages are sent directly between the user and the merchant/service that is sending the payment requests, then stored locally, presumably by both the user and the merchant/service.

[johnyj]

Most of the devs I know have a habit: They must do something every day 

But I tends to believe, upon certain maturity level, the more you try to improve it, the worse it gets. Raised level of complexity will reduce the robustness and flexibility of the system and result in more compatibility problem and customer confusion. A good approach is to be always prepared, but do NOTHING when it is not necessary

Although nothing is done, this wait and prepare action is high valuable and worth getting paid