Published on: 2014-03-02T18:18:18+00:00
In an email thread, Jeremy Spilman raised concerns about the use of third-party root certificates as a form of positive feedback for signed payment requests in cryptographic currency. He questioned the necessity of external certificates and their potential impact on security. Spilman proposed that if a payment is signed by the ECDSA private key it's being sent to, it should be marked with a green background. He also suggested implementing a signing fee extension or a compile-time option to disable this feature for small businesses. The email thread concluded with a quote advising against picking fights with influential individuals or trying to buy hackers.In another email conversation on the Bitcoin-development mailing list, Wladimir proposed a green stamp watermark for future BIP standards to differentiate signed requests. However, Jeremy Spilman pointed out the challenge of differentiating unsigned payment requests since they lack an "origin". The best way to distinguish signed requests, according to Spilman, is by prominently displaying the Merchant string in the green part of the stamp. The rest of the content would be displayed as normal, and a blank "Pay To" line would indicate the absence of a certificate. Saivann was suggested to potentially assist with graphics work for this.Continuing the email conversation, Wladimir and the recipient discussed the difficulty of differentiating unsigned payment requests due to the lack of an "origin" or referrer. If a request has a certificate, the Common Name (CN) becomes the "Pay To" string displayed for the merchant. Without a certificate, the most effective way to differentiate signed requests is by prominently displaying the Merchant string. The green display should only show the "Pay To" line, while the rest remains as content. An empty "Pay To" line would indicate the absence of a certificate.Another email exchange among Bitcoin developers focused on bug (#3628) and pull request (#3684) regarding negative feedback for missing or invalid signatures. It was agreed that treating invalid and unsigned payment requests equally would be ideal since the cost to an attacker is the same. The recommendation was made to test the pull request for improved payment request reporting. There was also discussion about making the difference between invalid and unsigned requests more noticeable to end users. Additionally, implementing a measure similar to HTTP Strict Transport Security for payment protocols was suggested to prevent signature stripping attacks in the future. However, the challenge of identifying the "origin" for unsigned payment requests was raised, and it was proposed that the server serving the payment requests could provide an HSTS-like header to only accept signed payment requests from them.Currently, signed payment requests are indicated by a green background, while unsigned requests have no background. Requests with a certificate but missing or invalid signatures also lack the green background. A bug (#3628) and pull request (#3684) have been opened to introduce negative feedback in the form of a yellow background for requests with missing or invalid signatures. However, there is a debate on whether this should be implemented in bitcoind. Concerns have been raised that if an attacker can avoid negative feedback by stripping the signature and setting pki_type to none, there may not be a security benefit in differentiating badly signed payment requests from unsigned ones. As a result, it is suggested that the root problem may lie in the positive feedback (green background) not being noticeable enough to the end user. Furthermore, there is ongoing discussion about implementing a measure similar to HTTP Strict Transport Security for payment protocols to mitigate signature stripping attacks, which merchants may be interested in as an extension field.
Updated on: 2023-08-01T07:46:21.476862+00:00