<unnamed>

Public Key

npub13lftpp7g0zz6pjhvjhqqlka53e358xctk4c4fzr52yywt5cqhkvqe273cc

Profile Code

nprofile1qqsgl54ssly83pdqetkftsq0mw6guc6rnv9m2u253p69zz896vqtmxqprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv2ngy9v

Publishing to

relay.snort.social

Last Notes

2023-06-07 15:25:43 UTC

- reply

📅 Original date posted:2014-09-12
📝 Original message:On 12 Sep 2014, at 20:43 , bitcoin-development-request at lists.sourceforge.net wrote:
> Specifically relevant here:
> http://security.stackexchange.com/questions/34796/truncating-the-output-of-sha256-to-128-bits.
>
> If you're going to truncate though, why not just leave the amount of
> bits up the the person generating the QR code? The client simply takes
> the hash prefix (any length up to full 256-bits) and makes sure it's a
> strict prefix of the actual hash of the payment request.
If you do so, please make sure the length of the hash is included in the PaymentDetails/PaymentRequest. If someone parses the URI and doesn’t have an authenticated way of knowing the expected length of the hash, a MITM attacker can just truncate the hash to lower security.
/Mark

2023-06-07 15:25:40 UTC

- reply

📅 Original date posted:2014-09-12
📝 Original message:On 12 Sep 2014, at 11:55 , bitcoin-development-request at lists.sourceforge.net wrote:
> The hash is meant to link the trust anchor (e.g. the QR code) to the
> payment request message in a secure way. This will solve the problem
> several apps are comparing address+amount fields as a workaround
> instead, preventing some advanced BIP70 usecases. When these apps read a
> matching hash, they need not compare any of the other fields.
Sounds like a good plan.
Do you have a list (possibly incomplete) of apps that perform this kind of checking? We’re currently working with some parties in a supply chain to allow a consumer payment on a retail website to automatically pay supply chain parties, the way BIP70 allows with multiple outputs on a transaction. This behaviour would prohibit this use case.
/Mark

2023-06-07 15:24:27 UTC

- reply

📅 Original date posted:2014-07-30
📝 Original message:On 28 Jul 2014, at 15:32 , Mike Hearn <mike at 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?

2023-06-07 15:24:27 UTC

- reply

📅 Original date posted:2014-07-28
📝 Original message:On 28 Jul 2014, at 14:46 , Mike Hearn <mike at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140728/c9a8b502/attachment.html>

2023-06-07 15:24:26 UTC

- reply

📅 Original date posted:2014-07-27
📝 Original message: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

2023-06-07 15:24:26 UTC

- reply

📅 Original date posted:2014-07-28
📝 Original message: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 at 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140728/d55f07f6/attachment.html>