The current implementation of mls-rs defines a ClientConfig.key_package_lifetime parameter which is intended to be used when creating KPs. Internally, however, this parameter seems to be used whenever a KemTree::Node is created. For example, when calling Client::create_group, that calls into Group::new which calls LeafNode::generate(..., config.lifetime())```.ClientConfig::lifetimeunder the hood uses theClientConfig.settings.lifetime_in_sto compute the returned value.ClientConfig.settings.lifetime_in_sis the backing value ofClientConfig.key_package_lifetime`.
Note that this is not the only place where ClientConfig::lifetime is passed to LeafNode::generate or other LN functions
Solution:
Potential solutions here are:
Renaming ClientConfig.key_package_lifetime and ClientConfig.key_package_not_before to something that indicates these are parameters driving the Node lifetimes instead. Ie ClientConfig.tree_node_lifetime and ClientConfig.tree_node_not_before
Splitting the lifetime params used for group creation / other non KP scenarios from the KP lifetimes. Extract the KP lifetimes to be parameters passed during KP generation.
Some other refactor?
Keep existing api to avoid breaking changes, Provide documentation to address potential confusion.
Problem:
Splitting this from the discussion in https://github.com/awslabs/mls-rs/pull/196/files#r1786752471
The current implementation of mls-rs defines a
ClientConfig.key_package_lifetimeparameter which is intended to be used when creating KPs. Internally, however, this parameter seems to be used whenever a KemTree::Node is created. For example, when callingClient::create_group, that calls intoGroup::newwhich callsLeafNode::generate(..., config.lifetime())```.ClientConfig::lifetimeunder the hood uses theClientConfig.settings.lifetime_in_sto compute the returned value.ClientConfig.settings.lifetime_in_sis the backing value ofClientConfig.key_package_lifetime`.Note that this is not the only place where ClientConfig::lifetime is passed to LeafNode::generate or other LN functions
Solution:
Potential solutions here are:
ClientConfig.key_package_lifetimeandClientConfig.key_package_not_beforeto something that indicates these are parameters driving the Node lifetimes instead. IeClientConfig.tree_node_lifetimeandClientConfig.tree_node_not_beforeRequirements / Acceptance Criteria:
TBD based on what solution we chose
Out of scope:
N/A