Fintan Halpenny: 1
rfc: ammend quorum rules
2 files changed, 60 insertions(+), 2 deletions(-)
I'd like to go back and reiterate what my thinking is just so I can
make sure it's clear :)
So we have two TODO items[0]:
---
* [ ] Simplify initialising a multisig identity
> Verification may allow the initial revision to have only one signature,
> regardless of the number of delegations.
* [ ] Quorum overrides for personal ids
> Cross-signing from multiple devices is inconvenient for personal ids.
> Macaroons could be issued which allow to confirm a change using only one
> second factor (HSM, password manager, ..). Or maybe just make the quorum
> threshold configurable.
---
This proposal was aiming to tackle the first one of this list. I can
see three different solutions based off of this conversation.
1. During verification, we ignore the quorum -- configured or
hard-coded -- iff:
a. we are looking at the initial revision
b. it has a single delegation signture
Note that this was what I was proposing in the RFC and implementation.
2. We implement the configurable threshold, where the initial creation
can set the threshold to 1 signature and the threshold is subsequently
updated.
This seems to have the downside that you MUST trust the other
delegates to not change the history during the quorum threshold
update. They only need to change the document and sign it, passing the
threshold of 1. That is, unless I've misunderstood and the update of
the quorum would take immediate effect, which is what you were saying
here:
As Alex reminded us, the threshold is exactly the number of keys an attacker
would need to compromise in order to gain control over the identity history. Any
scheme which permits a threshold of one (i.e. all that are being discussed) is
fairly bad thus, unless that single key is rotated out immediately and then
destroyed. Note that this is not a matter of trust (if you delegate trust to
keys you don't trust, then. Well. Have you tried turning it off and on again?),
but a matter of finality; which is undefined within link.
So, we have gained nothing.
I don't think exchanging signatures oob is bad per-se, as the public keys need
to be exchanged anyway. It would also not require a second transaction. Perhaps
an "experience" can be created around that, which involves comparing random
sequences of emojis or something like that?
Alternatively, I think an explicit threshold > 1 would work too, if the creator
has a second singing device at hand. Observe:
revision = 0
delegates = [A, A', B, C, D]
threshold = 2
signatures = [Sa, Sa']
Where A and A' are in fact controlled by the same person.
Ya, so I think the initial task of making the initialisation process
with multiple delegates easier is not worth it. I think a combination
of the `lnk identities project update` and `lnk sync` commands with
some seeds will be the way to go initially.
So I'll mark this RFC as rejected.
Practically, however, "second factor" signing keys would require supporting
weaker^H^H alternative signature schemes. Which in turn would require
generalising network identity, or else labelling them as second-factor-only. Oh
and baroque encodings. I got a new hammock, perhaps I should try that out right
now.
Why would they require weaker schemes?
Also: blockchains