| Least/Less Authority | Sub-key Revocation |
Sub-key registration
In this post we are going to be looking at two aspects of the coinZdense deep-dive:
- blockchain-stored key-data
- sub-key creation and dimensioning
As you might have gathered from earlier posts, different clients with the same signing key can synchronize the Signing Keys post, the blockchain using coinZdense will need to record some info about every known owner key.
The only bit of chain-side storage we discussed so far is the signing index. If we add attenuated priviledge subkeys to the mix, we see that there is quite some more signing-key hierarchy information that needs persistent blockchain storage. All the on-chain signing key data can be gathered by a node just through first-use signatures and earlier data stored about the signing key and/or its parents. There is just one operation that needs to be done explicitly and that operation is revocation. We will discuss revocation in the next post in detail. For now just realize that every non-owner signing key will have an on-chain boolean indicating if the signing key has been revoked, and that this boolean, once set, can never get cleared again. Once revoked, always revoked.
Similar to the transaction signing index, the blockchain stores a subkey derivation index for the signing key. A subkey has its own transaction signing index, so even if there is a local version of the sub-key, the client will still need to retreive the transaction signing index for the subkey before signing a transaction with the subkey. On first use, a subkey transaction signature shall also contain a derivation signature chain that will register the subkey with the blockchain.
Now when another client with the owner key, a client that didn't create the subkey, requests the derivation index, it will find there is a subkey it didn't know about. The second client should than ask the subkey parameters from the chain. Given the subkey parameters, consisting of the list of priv id's, the index-space index and the index-space bit count, the second client will have all the information needed to recover the sub key.
It is strongly suggested that any blockchain project using sub-keys in a granular way approaching POLA implements a petname system for naming sub-keys within a parent-key scope, storing sub-key petnames on the blockchain.
Now if we look closely at the information stored from the perspective of an key, we end up with something like this:
{
"XXXXXX": {
"ownerkey": true,
"transaction_idx": 32,
"derivation_idx": 1,
"subkeys": ["YYYYYY"],
"revoked_subkeys": []
},
"YYYYYY": {
"ownerkey": false,
"transaction_idx": 29,
"offset": 123456789,
"bits": 41,
"parent": "XXXXXX",
"owner": "XXXXXX",
"priv_ids": ["ZZZZZZZ"]
"revoked": false
"petname": "ACTIVE-2022-01-17"
}
}
Again, please note that on-chain information storage falls outside of the coinZdense implementation and is up to the blockchain project using coinZdense. The coinZdense project will provide the hooks, the on-chain storage is up to the blockchain project itself. Again, note petnames are not part of the hooks provided, but their use is strongly encouraged.
In the next post we shall look at revocation and the implications of revocation for signature validation. After that we will close of this series of post with a post about wallets.
| Least/Less Authority | Sub-key Revocation |
|
|
|