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