021-exchange-key-continuity.rst (2882B)
1 DD 21: Exchange Key Continuity 2 ############################## 3 4 :Design status: Accepted 5 :Implementation status: Partial 6 :DD shepherd: TBD 7 :Historical contributors: Florian Dold 8 :First published: 2021-05-25 9 :Last substantive change: 2021-05-25 10 :Implementation evidence: taler-typescript-core (2024-01-16) 11 :Normative references: :doc:`048-wallet-exchange-lifecycle`, :doc:`065-exchange-base-url-migration`, :doc:`../wallet/wallet-core` 12 13 .. warning:: 14 15 The direct-trust/auditor model in this document is historical, and wallets 16 now support controlled exchange base-URL migration as specified in DD65. 17 Those parts of the body are non-normative. 18 19 Summary 20 ======= 21 22 This design document discusses what happens if 23 an exchange's master public key ever changes. 24 25 Motivation 26 ========== 27 28 The exchange master public key is an offline signing key. While this makes 29 compromise of this key less likely, it makes it more likely that this key is 30 lost. 31 32 The wallet (and merchants) must handle such a scenario where the 33 exchange deploys a new master public key. 34 35 Proposed Solution 36 ================= 37 38 When wallets or merchants specify that they directly trust 39 an exchange, the trust record must always explicitly mention 40 a base URL and a master public key. 41 42 An exchange **should** have a single, canonical base URL. 43 However, an exchange that's reachable over different base URLs 44 should still be handled gracefully. 45 46 Wallet 47 ------ 48 49 We generally assume that the base URL of an exchange stays constant. Wallets 50 support controlled base-URL migration as specified in DD65. 51 52 A ``/keys`` response with an unknown exchange master public key is only 53 accepted if the exchange is audited by a trusted auditor or the wallet 54 has an exchange trust record with the advertized master public key. 55 56 Denomination records explicitly store which master public key 57 signed them. 58 59 Merchant 60 -------- 61 62 When coins are deposited, the wallet only specifies the base URL 63 for the respective exchange, but not the master public key of the exchange. 64 The merchant **must** always 65 resolve the URL to the current master public key, 66 and decide whether to accept the exchange based only 67 on the master public key. That is, a merchant 68 may not reject an exchange because the wallet is not 69 specifying what the merchant believes to be the 70 canonical base URL. 71 72 73 Alternatives 74 ============ 75 76 * The wallet could treat each (base URL, master pub) pair as a 77 separate exchange. This, however, does not work in practice, 78 since the exchange with the new public key should still accept 79 deposits and refreshes of coins with denominations signed by the 80 old key. 81 82 83 Discussion / Q&A 84 ================ 85 86 * Does the current merchant backend have support 87 for changing master public keys of exchanges trusted 88 via the auditor? Or does the code base make the assumption 89 that one merchant base URL corresponds to only one master 90 public key?