Revocation bitfield #1444

Open
opened 2019-03-20 09:17:13 +01:00 by PeterSurda · 0 comments
PeterSurda commented 2019-03-20 09:17:13 +01:00 (Migrated from github.com)

If a BM address is used for long-term authentication, there is a need to revoke it in case it gets compromised. Obviously, it is easy to create a new one, but there also should be a way to indicate to the user that an old address shouldn't be used.

The easiest way, in my opinion, is to add a new bitfield to an address, say BITFIELD_REVOKED, which can be turned on but not off (there needs to be some additional protection in the code so that simply editing keys.dat won't turn it off). The UI would then signal to the sender that they shouldn'd use it.

  • Bitfield deifnition and a coresponnding variable in keys.dat
  • UI for turning it on with warning and confirmations
  • UI for showing (on the owner side) that an address is revoked, similarly to how disabled addresses are grayed out
  • after revoked, a new pubkey object should be sent immediately, not only after the old one expires
  • Protection against turning it off in BMConfigParser
  • Protection against turning it off in some other way
  • objectProcessor should handle the bitfield and flag entries in the addressbook (may require additional colums in addressbook table). It should also protect the flag/bitfield from being turned off after it is on
  • messagelist should change background color for messages from revoeked addresses (maybe only after revocation date?)
  • Send tab should complain or perhaps even grey out the send button if a revoked address is used
  • Autoreply?
  • some other things I'm missing?
If a BM address is used for long-term authentication, there is a need to revoke it in case it gets compromised. Obviously, it is easy to create a new one, but there also should be a way to indicate to the user that an old address shouldn't be used. The easiest way, in my opinion, is to add a new bitfield to an address, say BITFIELD_REVOKED, which can be turned on but not off (there needs to be some additional protection in the code so that simply editing keys.dat won't turn it off). The UI would then signal to the sender that they shouldn'd use it. - [ ] Bitfield deifnition and a coresponnding variable in keys.dat - [ ] UI for turning it on with warning and confirmations - [ ] UI for showing (on the owner side) that an address is revoked, similarly to how disabled addresses are grayed out - [ ] after revoked, a new pubkey object should be sent immediately, not only after the old one expires - [ ] Protection against turning it off in BMConfigParser - [ ] Protection against turning it off in some other way - [ ] objectProcessor should handle the bitfield and flag entries in the addressbook (may require additional colums in addressbook table). It should also protect the flag/bitfield from being turned off after it is on - [ ] messagelist should change background color for messages from revoeked addresses (maybe only after revocation date?) - [ ] Send tab should complain or perhaps even grey out the send button if a revoked address is used - [ ] Autoreply? - [ ] some other things I'm missing?
This repo is archived. You cannot comment on issues.
No Milestone
No project
No Assignees
1 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Bitmessage/PyBitmessage-2024-08-21#1444
No description provided.