📅 Original date posted:2014-09-12 📝 Original message:Are there any ...

Aaron Voisine [ARCHIVE] /

npub18gj…nkzl

2023-06-07 15:25:42

in reply to nevent1q…tuwu

📅 Original date posted:2014-09-12
📝 Original message:Are there any circumstances where the payment request object might be
served over a different domain than the CNAME of the object's signer?

BIP72 states "Bitcoin wallets must support fetching PaymentRequests
via http and https protocols;". If the request object is signed by the
owner of the domain, then the worst an attacker who doesn't have the
signing key can do is replace the request with another validly signed
request intended for someone else, but that could be the attacker's
own product order, tricking someone else into paying for it.

Should BIP72 require that signed payment requests be from the same
domain, and also require https?

Aaron

Aaron Voisine
breadwallet.com

On Fri, Sep 12, 2014 at 9:31 AM, Mike Hearn <mike at plan99.net> wrote:
> Putting aside the question of necessity for a moment, a more efficient
> approach to this would be;
>
> Add another marker param like &s to the end of the URL
> Add another field to PaymentRequest that contains an ECC signature
> calculated using the public key that hashes to the address in the URI
> Upgraded wallets look for the additional param and if it's there, expect to
> find the PaymentDetails signed with the address key. PKI signing of course
> is still useful to provide an actual identity for receipts, display on
> hardware wallets, dispute mediation etc.
>
> This adds only a few characters to a normal backwards-compatible QR code,
> and is not hard to implement.
>
>
> On Fri, Sep 12, 2014 at 5:37 PM, Mike Hearn <mike at plan99.net> wrote:
>>>
>>> That way we leave up to implementers to experiment with different
>>> lengths and figure out what the optimum is
>>
>>
>> Ah, that's a good suggestion if we do go this way.
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

Author Public Key

npub18gjvug29c4yg46lmplq38e75gg6wn5mn8taytckcsr4jt8p74h3s5knkzl

Seen on

wss://relay.nostr.band

Show more details

Published at

2023-06-07 15:25:42

Kind type

1 Short Text Note

Event JSON

{ "id": "310a236b61ae583e31d2d0bd39d6cfd9ba426f1613b2050bd267ed6e65b0e856", "pubkey": "3a24ce2145c5488aebfb0fc113e7d44234e9d3733afa45e2d880eb259c3eade3", "created_at": 1686151542, "kind": 1, "tags": [ [ "e", "5045235f447739204820462b94c541446b82ef26097d3889eeeed0767ae1d197", "", "root" ], [ "e", "033a3cb851b85a3687dec1262cb156d429841007ec3b2999356abfae2ac3c53c", "", "reply" ], [ "p", "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2" ] ], "content": "📅 Original date posted:2014-09-12\n📝 Original message:Are there any circumstances where the payment request object might be\nserved over a different domain than the CNAME of the object's signer?\n\nBIP72 states \"Bitcoin wallets must support fetching PaymentRequests\nvia http and https protocols;\". If the request object is signed by the\nowner of the domain, then the worst an attacker who doesn't have the\nsigning key can do is replace the request with another validly signed\nrequest intended for someone else, but that could be the attacker's\nown product order, tricking someone else into paying for it.\n\nShould BIP72 require that signed payment requests be from the same\ndomain, and also require https?\n\nAaron\n\nAaron Voisine\nbreadwallet.com\n\n\nOn Fri, Sep 12, 2014 at 9:31 AM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e Putting aside the question of necessity for a moment, a more efficient\n\u003e approach to this would be;\n\u003e\n\u003e Add another marker param like \u0026s to the end of the URL\n\u003e Add another field to PaymentRequest that contains an ECC signature\n\u003e calculated using the public key that hashes to the address in the URI\n\u003e Upgraded wallets look for the additional param and if it's there, expect to\n\u003e find the PaymentDetails signed with the address key. PKI signing of course\n\u003e is still useful to provide an actual identity for receipts, display on\n\u003e hardware wallets, dispute mediation etc.\n\u003e\n\u003e This adds only a few characters to a normal backwards-compatible QR code,\n\u003e and is not hard to implement.\n\u003e\n\u003e\n\u003e On Fri, Sep 12, 2014 at 5:37 PM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e That way we leave up to implementers to experiment with different\n\u003e\u003e\u003e lengths and figure out what the optimum is\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Ah, that's a good suggestion if we do go this way.\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Want excitement?\n\u003e Manually upgrade your production database.\n\u003e When you want reliability, choose Perforce\n\u003e Perforce version control. Predictably reliable.\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=157508191\u0026iu=/4140/ostg.clktrk\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e", "sig": "77f61644ec0f9e8170fcd695e7dbe700271b11b598f621b5f15af2097a89b8fb5afa014b4a83878aeb28f8a4ca304e252203fec03a30b394a38724cc93e81b48" }