radicle-link: rfc: ammend quorum rules v1 PROPOSED

Fintan Halpenny: 1
 rfc: ammend quorum rules

 2 files changed, 60 insertions(+), 2 deletions(-)
#762550 nixos-latest.yml failed
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
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
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.
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








Also: blockchains
Export patchset (mbox)
How do I use this?

Copy & paste the following snippet into your terminal to import this patchset into git:

curl -s https://lists.sr.ht/~radicle-link/dev/patches/32420/mbox | git am -3
Learn more about email & git

[PATCH radicle-link v1] rfc: ammend quorum rules Export this patch

Propose to change the quorum rules to allow for identities to be
created with multiple delegations and be considered verified.

Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>

A short RFC to ammend the quorum rules for creating an identity with
multisig and consider it verified.

Published-as: https://github.com/FintanH/radicle-link/tree/patches/rfc%2Fsimplify-multisig-identity%2Fv1

 docs/rfc/0703-simplify-multisig-identity.adoc | 53 +++++++++++++++++++
 docs/spec/sections/identities.adoc            |  9 +++-
 2 files changed, 60 insertions(+), 2 deletions(-)
 create mode 100644 docs/rfc/0703-simplify-multisig-identity.adoc

diff --git a/docs/rfc/0703-simplify-multisig-identity.adoc b/docs/rfc/0703-simplify-multisig-identity.adoc
new file mode 100644
index 00000000..6c47f85c
--- /dev/null
+++ b/docs/rfc/0703-simplify-multisig-identity.adoc
@@ -0,0 +1,53 @@
= RFC: Simplify Multisig Identity Creation
Fintan Halpenny <fintan.halpenny@gmail.com>
:revdate: 2022-05-20
:revremark: draft
:toc: preamble

* Author: {author_1}
* Date: {revdate}
* Status: {revremark}

== Motivation

The current situation for creating an identity document allows
multiple delegates to be specified up-front, but the document will not
be verified until all those delegates reach a quorum. Thus, a new
identity will only be considered a verified document if and only if
it is created with a single delegate where the local operator is the
delegate themselves.

To allow an identity to be considered verified upon creation with
multiple delegates, it is necessary to ammend our definition of an
initial quorum.

== Terminology and Conventions

The key words "`MUST`", "`MUST NOT`", "`REQUIRED`", "`SHALL`", "`SHALL NOT`",
"`OPTIONAL`" in this document are to be interpreted as described in <<RFC2119>>
and <<RFC8174>> when, and only when, they appear in all capitals, as
shown here.

== New Quruom Rules

To allow for the identity to be a verified document with multiple
delegates upon creation, an extra rule must be added when checking the
quorum. When checking the quorum of the identity and the revision is
the root revision, then a quourum is considred reach iff there is one
eligible signature from a delegate.

More formally:

The identity carrier passes the signature check, and:

* The document does not refer to a previous revision, no previous
  revision is known, and their is a single signature from the
* *Or* the document is signed by a quorum of the keys specified in the
  delegations of the document (`Q > D/2`).
\ No newline at end of file
diff --git a/docs/spec/sections/identities.adoc b/docs/spec/sections/identities.adoc
index 49b76744..eebf4733 100644
--- a/docs/spec/sections/identities.adoc
+++ b/docs/spec/sections/identities.adoc
@@ -198,8 +198,13 @@ The identity carrier passes 1., and is signed by at least one key specified in
the delegations of the document.
. *Quorum*
The identity carrier passes 2., and is signed by a quorum of the keys specified
in the link:#delegations[delegations] of the document (`Q > D/2`).
The identity carrier passes 2., and:

    * The document does not refer to a previous revision, no previous
      revision is known, and their is a single signature from the
    * *Or* the document is signed by a quorum of the keys specified in the
      link:#delegations[delegations] of the document (`Q > D/2`).
. *Verified*
radicle-link/patches/nixos-latest.yml: FAILED in 26m37s

[rfc: ammend quorum rules][0] from [Fintan Halpenny][1]

[0]: https://lists.sr.ht/~radicle-link/dev/patches/32420
[1]: mailto:fintan.halpenny@gmail.com

✗ #762550 FAILED radicle-link/patches/nixos-latest.yml https://builds.sr.ht/~radicle-link/job/762550
The same effect can be achieved by introducing a threshold field which allows to
specify the exact number of signatures (clamped to (0,n] where n is the number
of delegations).

It is not always obvious what value to pick for the desired semantics (`n` is
almost always a bad choice), which is why I went for a predefined quorum
initially. I think this is still the best choice for project identities, but
personal ones may prefer 1 or 2.