Open SmithSamuelM opened 1 year ago
A complication is for distributed multi-sig but the groupHab keeps a list of smids and rmids and so can figure out how to map the the key state of the group KEL to the key state of theof the local member and then to get both the rotation index and the key index in the the key list for a given member in order to compute the path.
The current HDK path generation in the key store makes the assumption that no key is reused in a sequence of keys for a given identifier prefix. Reserved rotation keys within a single non-distributed multi-sig group identifier violate that assumption. The current pathing includes the rotation index ridx and the key index kidx in the path. The key index is already unique as it is the index in the key sequence of all keys not the offset in a given rotation. This means that the rotation index is not actually necessary for the HDK to generate a unique path for each key, only the key index. Changing the pathing will break unit tests. One way to make it backwards compatible is to add a parameter that optionally indicates to allow reserve keys to be reused and hence not include the rotation index in the path. Suggest reservable True means not use ridx. False means use ridx.
The rotation number,
rn
,r
, field will be similar to the existing sequence number,sn
,s
, and first seen ordinal number,fn
,f
fields. It will be an ordinal butrn
will index or count the number of rotations,. thern
field value is a hex string equivalend of theridx
(int) parameter to the SaltyCreator for generating HDKs in keeping.py. This will allow signify to regnerate private keys on demand and avoid storing or transmitting any encrypted keys to/from the cloud.This use of the
ridx
is to maintain backwards compatibility. In the future it will be optional because thekidx
field is already unique. Thekidx
counts all the keys in a key sequence so is zero based to the zeroth key for the whole history of keys for a given KEL not the zeroth key in each est event. This makes theridx
superflouous. This was not a problem when all keys had to start their lifecycle as rotation keys (except the inception signing keys) but with reserve rotation keys in combination with signing only keys, the lifecycle of a key in a key sequence is no longer monotonic. A key may appear multiple times in the case of a reserve rotation key. Thus theridx
would be problematic because any path of a reserve rotation key would not be identical if it included theridx
. Thus in the future a given key sequence should be able to specify that only thekidx
can be in the path not theridx
. This means that the key state must also include the listkidxes
for each establishment event so that a signing key can be regenerated from its path. And merel knowing the number of keys in a key list is not enough to reproduce the list ofkidxes
.For reserve rotation members the
kidx
The
rn
of an inception event is zero, 0, the first rotation after inception hasrn
== 1. In an establishment onlyEO
KEL which does not have interaction events, thern
andsn
are identically valued.All that signify will need is the state message for any AID and from that and the secret salt ( which only the signify client has). Given the state (with the
rn
) and key lists for a given establishment event, the signifi client can recalculate the SaltyCreator path used to generate the keys in the first place.A complication is dual indexed signatures but the cloud can calculate the indices for the signature and pass them to the client with the signing request.
This simplifies things.
in the actual compact label form of the state message the field labels are
s
for snf
for fnr
for rn