This removes the (faulty) current subkey support and replaces it with subaccounts.
This is not phased in with a hard fork as the current subkey approach is not used and should not be as it can leak the master private key to the subkey holder if used. (Session clients still shouldn't use it before storage server starts returning 19.4, but it doesn't hurt to have it work before then and is easier than version-gating it).
Subaccounts achieve largely the same thing as subkeys, but instead of attempting to mutate the master key into a subkey, we now simply allow any key to be used for the request as long as it carries a token + signature from the account owner authorizing the subkey to be used.
Additionally this prefixes the subaccount token with the network id (e.g. 03 for 03xxxxx pubkeys) and adds extra bits so that different types of subkeys can be issued:
read allows access an account to read it, e.g. for retrieve
write allows inserting messages and extending expiry times, but not delete message or shortening expiries
delete allows message deletion and expiry shortening
any_prefix allows the subkey to access any prefix, not only the one on the beginning of the token. (So if this is specified, a subaccount token for 05fffffff... can access any XXfffffff... (e.g. 03fffffff..., 42fffffff...) using the subaccount.
20 more bits for future use (since the token is usually base64 encoded, these are "free" in that they'd be base64 padding bits on the end for typical requests if we didn't use them as part of the token value).
Alongside subaccount revocation (which replaces the previous subkey revocation) we now have some additional related functionality:
A new unrevoke_subaccount that removes a revocation; Session groups need this to be able to remove and then re-add a member (which would use the same subkey), and thus Session will always issue an unrevoke just before adding a member (just in case the member was previous removed/revoked).
revoke_subaccount and unrevoke_subaccount can now be passed an array of subaccount tags (instead of just a single one) to bulk add or remove revoked subaccounts without needing to use batch requests.
This removes the (faulty) current subkey support and replaces it with subaccounts.
This is not phased in with a hard fork as the current subkey approach is not used and should not be as it can leak the master private key to the subkey holder if used. (Session clients still shouldn't use it before storage server starts returning 19.4, but it doesn't hurt to have it work before then and is easier than version-gating it).
Subaccounts achieve largely the same thing as subkeys, but instead of attempting to mutate the master key into a subkey, we now simply allow any key to be used for the request as long as it carries a token + signature from the account owner authorizing the subkey to be used.
Additionally this prefixes the subaccount token with the network id (e.g. 03 for 03xxxxx pubkeys) and adds extra bits so that different types of subkeys can be issued:
readallows access an account to read it, e.g. for retrievewriteallows inserting messages and extending expiry times, but not delete message or shortening expiriesdeleteallows message deletion and expiry shorteningany_prefixallows the subkey to access any prefix, not only the one on the beginning of the token. (So if this is specified, a subaccount token for 05fffffff... can access any XXfffffff... (e.g. 03fffffff..., 42fffffff...) using the subaccount.Alongside subaccount revocation (which replaces the previous subkey revocation) we now have some additional related functionality:
A new
unrevoke_subaccountthat removes a revocation; Session groups need this to be able to remove and then re-add a member (which would use the same subkey), and thus Session will always issue an unrevoke just before adding a member (just in case the member was previous removed/revoked).revoke_subaccountandunrevoke_subaccountcan now be passed an array of subaccount tags (instead of just a single one) to bulk add or remove revoked subaccounts without needing to use batch requests.