* [Bitcoin-development] "On behalf of" BIP 70 extension proposal
@ 2014-07-27 6:55 Mark van Cuijk
2014-07-27 19:31 ` Mike Hearn
0 siblings, 1 reply; 8+ messages in thread
From: Mark van Cuijk @ 2014-07-27 6:55 UTC (permalink / raw)
To: bitcoin-development
When I asked a non-tech friend to do a BIP 70 payment using our wallet as a first round of user experience testing, he made the remark the he wanted to do a payment to a merchant, but instead our software shows a payment to “BitPay, Inc.”
This can be problematic for a couple of reasons:
- As a user you don’t need to know and trust individual payment processors. As long as you can identify and authenticate the merchant, you should be able to rely on the merchant’s choice for a payment processor.
- An attacker can become a client of a payment processor, use it to create a PaymentRequest message and send this message to a victim as part of a MITM attack; the victim now thinks he is paying a merchant through the payment processor, but is actually paying the attacker through the payment processor.
I have a proposal that can be transformed into a BIP or into an extension of BIP 70 and adds a way to include merchant identity in the PaymentRequest message and I’d like to see a discussion on this topic.
At this moment, the PaymentRequest message contains a pki_data field with a certificate chain to authenticate the entity that generates the message, which in the above case is the payment processor.
I’m proposing to extends the PaymentRequest message with three more fields:
- payee_pki_type
- payee_pki_data
- payee_mandate
The payee_pki_type and payee_pki_data fields can be of the same format as the pki_type and pki_data fields, except that they authenticate the identity of the merchant, instead of the identity of the payment processor. The payee_mandate fields contains a claim by the merchant, signed using his own private key, that he grants the payment processor the right to collect the payment on his behalf.
The solution is backwards compatible, since existing wallets can ignore these fields. They will not show the identity of the merchant, but keep showing the identity of the payment processor, they are still able to verify the signature in the PaymentRequest message and therefore can complete the payment process.
A wallet that understands this extension, needs to check the validity of both certificate chains when present and also the validity of the mandate. If all is fine, it can now show the identity information from the merchant certificate instead of (or besides) the identity of the payment processor and allow an end user to correctly identify the merchant.
A payment processor supporting this extension may offer it as an optional service to clients. A client that wishes to use this extension needs to obtain his own certificate from a CA and use it to sign a mandate. One potential obstacle is that this process probably needs to be repeated both when the certificate of the merchant or the certificate of the payment processor expires, but we may be able to address that when defining the format of the mandate.
/Mark
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] "On behalf of" BIP 70 extension proposal
2014-07-27 6:55 [Bitcoin-development] "On behalf of" BIP 70 extension proposal Mark van Cuijk
@ 2014-07-27 19:31 ` Mike Hearn
2014-07-28 9:01 ` Mark van Cuijk
0 siblings, 1 reply; 8+ messages in thread
From: Mike Hearn @ 2014-07-27 19:31 UTC (permalink / raw)
To: Mark van Cuijk; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 300 bytes --]
Hi Mark,
This is very similar to a proposal I made some time ago:
https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04053.html
I think the outlines of a design are clear - my proposal and yours don't I
think differ substantially. Someone needs to make it happen though.
[-- Attachment #2: Type: text/html, Size: 548 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] "On behalf of" BIP 70 extension proposal
2014-07-27 19:31 ` Mike Hearn
@ 2014-07-28 9:01 ` Mark van Cuijk
2014-07-28 12:46 ` Mike Hearn
0 siblings, 1 reply; 8+ messages in thread
From: Mark van Cuijk @ 2014-07-28 9:01 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2423 bytes --]
Good to see that it has been discussed, but I see the idea has been postponed. I agree our proposals don’t differ substantially. Besides naming, I think the differences are the algorithms that are used for signing the extended certificate / mandate by the merchant and the way backwards compatibility is handled.
Also taking into consideration the replies on your proposal, I think the following decisions are most important to be made when we make a step back:
What party/system do we want to rely on to verify the identity of the merchant? Options I’ve seen:
- X.509 CAs
- Payment Processors (PP)
- PGP/Bitcoin-based
Which “PKI" do we want to use to identify the merchant (related to the previous question)?
- X.509 certificate
- Merchant identifier
- Twitter handle
Which “PKI” do we want to use to authenticate the PP?
- X.509 certificate
- Extended certificate
My personal opinion:
I’d prefer to stick to the X.509 system for identification of the merchant, even though the system is not perfect. In the case of a webshop transaction, a customer probably already relies on the X.509 system to authenticate the identity of the merchant during the shopping session (HTTPS) in his browser when he transmits his personal data like his address. I’d prefer not to add a competing identification system a customer also needs to rely on, unless that system brings objective improvements and can also be used in the HTTPS session.
I do like the idea coined by Mike that a PP can issue non-SSL certificates for the purpose of merchant identification, as long as a customer is free to determine whether he trusts the PP for this purpose.
Regarding the choice of how to authenticate the PP, I’m a bit undetermined. Disregarding backward compatibility, I think the extended certificate system proposed by Mike is cleaner. However, I don’t like the concept of requiring two separate signatures for old and new clients. Taking backward compatibility in mind, I tend to prefer my proposal.
/Mark
On 27 Jul 2014, at 21:31 , Mike Hearn <mike@plan99•net> wrote:
> Hi Mark,
>
> This is very similar to a proposal I made some time ago:
>
> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04053.html
>
> I think the outlines of a design are clear - my proposal and yours don't I think differ substantially. Someone needs to make it happen though.
>
>
[-- Attachment #2: Type: text/html, Size: 3287 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] "On behalf of" BIP 70 extension proposal
2014-07-28 9:01 ` Mark van Cuijk
@ 2014-07-28 12:46 ` Mike Hearn
2014-07-28 13:06 ` Mark van Cuijk
0 siblings, 1 reply; 8+ messages in thread
From: Mike Hearn @ 2014-07-28 12:46 UTC (permalink / raw)
To: Mark van Cuijk; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]
On Mon, Jul 28, 2014 at 11:01 AM, Mark van Cuijk <mark@coinqy•com> wrote:
> Good to see that it has been discussed, but I see the idea has been
> postponed.
>
I'm not sure postponed is the right word. It wasn't in v1, but many useful
things weren't. It's more like, a bunch of people have to do work to
upgrade this and at the moment they're all busy with other things.
> I do like the idea coined by Mike that a PP can issue non-SSL certificates
> for the purpose of merchant identification, as long as a customer is free
> to determine whether he trusts the PP for this purpose.
>
I don't think I proposed this exactly? It's the other way around - a
merchant issues an extension cert to allow the PP to act on their behalf.
> Regarding the choice of how to authenticate the PP, I’m a bit
> undetermined. Disregarding backward compatibility, I think the extended
> certificate system proposed by Mike is cleaner. However, I don’t like the
> concept of requiring two separate signatures for old and new clients.
> Taking backward compatibility in mind, I tend to prefer my proposal.
>
I'm not sure I understand. Your proposal also has two signatures. Indeed it
must because delegation of authority requires a signature, but old clients
won't understand it.
[-- Attachment #2: Type: text/html, Size: 2070 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] "On behalf of" BIP 70 extension proposal
2014-07-28 12:46 ` Mike Hearn
@ 2014-07-28 13:06 ` Mark van Cuijk
2014-07-28 13:32 ` Mike Hearn
0 siblings, 1 reply; 8+ messages in thread
From: Mark van Cuijk @ 2014-07-28 13:06 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1675 bytes --]
On 28 Jul 2014, at 14:46 , Mike Hearn <mike@plan99•net> wrote:
> I do like the idea coined by Mike that a PP can issue non-SSL certificates for the purpose of merchant identification, as long as a customer is free to determine whether he trusts the PP for this purpose.
>
> I don't think I proposed this exactly? It's the other way around - a merchant issues an extension cert to allow the PP to act on their behalf.
I referred to your idea in https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04076.html which is indeed not the proposal itself.
> Regarding the choice of how to authenticate the PP, I’m a bit undetermined. Disregarding backward compatibility, I think the extended certificate system proposed by Mike is cleaner. However, I don’t like the concept of requiring two separate signatures for old and new clients. Taking backward compatibility in mind, I tend to prefer my proposal.
>
> I'm not sure I understand. Your proposal also has two signatures. Indeed it must because delegation of authority requires a signature, but old clients won't understand it.
I’ll rephrase what I intended to say. In your proposal two signatures need to be computed over the payment request data, one with the key related to the X.509 certificate (for backwards compatibility) and one with the ECDSA public key. On my proposal only one signature needs to be computed over the payment request data using the former key, the same way it happens now.
Indeed there is another signature, which is to authenticate the payment delegation. If you take it into account in the signature count, then your proposal has three signatures.
/Mark
[-- Attachment #2: Type: text/html, Size: 2878 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] "On behalf of" BIP 70 extension proposal
2014-07-28 13:06 ` Mark van Cuijk
@ 2014-07-28 13:32 ` Mike Hearn
2014-07-30 7:54 ` Mark van Cuijk
0 siblings, 1 reply; 8+ messages in thread
From: Mike Hearn @ 2014-07-28 13:32 UTC (permalink / raw)
To: Mark van Cuijk; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 898 bytes --]
>
> I referred to your idea in
> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04076.html
> <https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04076.html> which
> is indeed not the proposal itself.
>
Right, gotcha. Had forgotten about that.
Indeed there is another signature, which is to authenticate the payment
> delegation. If you take it into account in the signature count, then your
> proposal has three signatures.
>
Yes, I see now, you are right. A mandate type system is probably simpler
indeed.
So what now? To be honest my next priority with BIP70 was to formalise the
extensions process, I've been dragging my feet over that because I'm
working on other things. And then after that to knock some heads together
over at BitPay/Coinbase and get them to put useful text in the memo field
instead of random numbers. Baby steps ....
[-- Attachment #2: Type: text/html, Size: 1451 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] "On behalf of" BIP 70 extension proposal
2014-07-28 13:32 ` Mike Hearn
@ 2014-07-30 7:54 ` Mark van Cuijk
2014-07-30 11:34 ` Mike Hearn
0 siblings, 1 reply; 8+ messages in thread
From: Mark van Cuijk @ 2014-07-30 7:54 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
On 28 Jul 2014, at 15:32 , Mike Hearn <mike@plan99•net> wrote:
> So what now? To be honest my next priority with BIP70 was to formalise the extensions process, I've been dragging my feet over that because I'm working on other things. And then after that to knock some heads together over at BitPay/Coinbase and get them to put useful text in the memo field instead of random numbers. Baby steps ....
I can probably pick up writing the proposal.
However, I’m not sure what process to follow. Should I format the proposal as a new BIP or should it become part of BIP.70? How does the extensions process you’re working on going to describe the process?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] "On behalf of" BIP 70 extension proposal
2014-07-30 7:54 ` Mark van Cuijk
@ 2014-07-30 11:34 ` Mike Hearn
0 siblings, 0 replies; 8+ messages in thread
From: Mike Hearn @ 2014-07-30 11:34 UTC (permalink / raw)
To: Mark van Cuijk; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1133 bytes --]
That would definitely be a new BIP.
But firstly it'd make sense to implement it and make sure that the payment
processors intend to use it. Like I said, I wasn't very successful so far
in getting them to make useful memo fields. I'm hoping that once wallets
start actually recording and displaying the memo in their transactions list
that will change.
On Wed, Jul 30, 2014 at 9:54 AM, Mark van Cuijk <mark@coinqy•com> wrote:
> On 28 Jul 2014, at 15:32 , Mike Hearn <mike@plan99•net> wrote:
>
> > So what now? To be honest my next priority with BIP70 was to formalise
> the extensions process, I've been dragging my feet over that because I'm
> working on other things. And then after that to knock some heads together
> over at BitPay/Coinbase and get them to put useful text in the memo field
> instead of random numbers. Baby steps ....
>
> I can probably pick up writing the proposal.
>
> However, I’m not sure what process to follow. Should I format the proposal
> as a new BIP or should it become part of BIP.70? How does the extensions
> process you’re working on going to describe the process?
[-- Attachment #2: Type: text/html, Size: 1528 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-07-30 11:35 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-27 6:55 [Bitcoin-development] "On behalf of" BIP 70 extension proposal Mark van Cuijk
2014-07-27 19:31 ` Mike Hearn
2014-07-28 9:01 ` Mark van Cuijk
2014-07-28 12:46 ` Mike Hearn
2014-07-28 13:06 ` Mark van Cuijk
2014-07-28 13:32 ` Mike Hearn
2014-07-30 7:54 ` Mark van Cuijk
2014-07-30 11:34 ` Mike Hearn
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox