Published on: 2014-03-02T16:14:43+00:00
In a 2014 email exchange between Andreas Schildbach and Mike Hearn, concerns were raised about the deployment of a new extension for Bitcoin Improvement Proposal 70 (BIP70). Schildbach believed it was too early to implement the extension widely and questioned whether multiple Public Key Infrastructures (PKIs) could be used at once. Hearn explained that the proposal did not allow for multiple PKIs and clarified that the extension specialized and extended the existing PKI. He also argued against keeping the fix local to X.509, stating that it would sacrifice backwards compatibility.The proposed extension aims to address issues with payment processors and security risks by allowing identity delegation. It suggests creating an extended certificate that would be added to the X509Certificates message in the PaymentRequest. This new certificate would be signed by both the SSL certificate of the payment processor and their delegated ECDSA key. The proposed implementation includes an option for maximum security, where the merchant can set short expiry times on the certificates and upload a new one at the end of each period. This ensures faster resealing in case of payment processor compromise. The proposal also explores alternatives, such as using the User-Agent field or creating the extension certificate as an X.509 cert, but ultimately recommends a unique format to ensure safety.In the email conversation, Dev Random raises concerns about the technical expertise required for small businesses or individuals to perform delegation signature. One solution proposed is to create a simple GUI app that allows them to produce the ExtendedCert file, which can then be sent to the payment processor. However, for small businesses without a CA cert, there are currently no ideal solutions available. Another idea discussed is the possibility of a scheme where a merchant can be namespaced under the payment processor, requiring just one additional field - the merchant identifier. However, the exact definition of the "merchant identifier" is left unresolved. The suggestion of payment processors becoming certificate authorities themselves is also mentioned, with BitPay as an example. However, this would require significant setup and raises questions about the verification process.The current user interface (UI) may not effectively alert users to potential issues with payment processing due to a lack of authenticated fields beyond the memo field available to payment processors. One solution proposed is to include a certificate viewer in the UI, allowing advanced users to inspect the certificate for additional fields. However, this may only benefit advanced users, and there may be difficulties in getting certificate authorities to sign certificates with arbitrary data. It is considered undesirable for users to have to make special requests to their certificate authorities.In another email exchange, Mike Hearn expresses concerns about the security risks associated with payment processors that allow open signups. He warns that hackers could sign up for a payment processor under false identities and swap out payment requests, leading to potential fraud. To address this, he suggests embedding additional information in payment requests, such as specific fields defined in an extension, to be shown reliably in the user interface. The proposal faces difficulties in getting certificate authorities to allow additional fields in certificates, so a simpler solution is suggested: having a single field containing a delimited key/value string (in JSON format) that can be shown as additional lines of labeled text in the UI.The lack of identity delegation in BIP70 poses challenges for payment processors like BitPay and Coinbase, as they have to sign payment requests as themselves, resulting in a confusing UI for users. Mike Hearn proposes a simple extension that allows the creation of an extended certificate, which is similar to X.509 certificates but simpler and Bitcoin-specific. The ExtensionCert message includes an ECDSA public key from the payment processor, signature, and expiry time fields. The merchant can be namespaced under the payment processor, giving the user the correct name in the wallet UI. The memo field can optionally indicate the purpose of the cert. Dev Random suggests a solution for small businesses or individuals without technical expertise, where the payment processor certifies that the merchant generated the invoice directly on their system. The proposal emphasizes the importance of security and simplicity, considering alternatives like using the User-Agent field or creating an X.509 cert but deeming them less safe.The implementation of BIP70 highlights the need for identity delegation, which is not included in version 1. Payment processors face challenges in signing payment requests as themselves, leading to confusion in the user interface. The proposed solution involves creating an extended certificate specific to Bitcoin, called the "extension certificate." This certificate includes the ECDSA public key of the payment processor and is signed using an SSL private key. It is added to the X509Certificates message provided by the payment processor. The PaymentRequest then contains two signature fields: one using the SSL cert of the payment processor and another using the delegated ECDSA key. The proposal also addresses cases where there is no X.509 cert available and explores alternatives to customize the PaymentRequest based on client capabilities.
Updated on: 2023-08-01T07:45:08.881966+00:00