[MLS] long term identity key rotation suggestion

["Owen Friel (ofriel)" <[e-mail]>]

There is currently no mechanism defined in https://tools.ietf.org/html/draft-ietf-mls-protocol-08 for long term identity key rotation. Richard and I have been thinking about how we could address this and here is a suggestion that could work.

The genesis of the idea is that as client can Add and Remove other parties from a group, a client with both an existing long term identity key (LTIK) that is in a group, and a new LTIK that is not in the group, could Add the new LTIK to the group, and then the client uses the new LTIK to Remove the old LTIK from the group. Working through that, it quickly collapses into a single Update message.

It ends up looking something like this (where CIK = ClientInitKey):

Client starts with:

LTIK-0
CIK-0 signed by LTIK-0
LTIK-0 and CIK-0 public key are in a group LeafNodeInfo.

Client then:

Generates new LTIK-1 and interacts with AS to get new LTIK-1 attested/signed.
Generates CIK-1 and signs it using LTIK-1
Interacts with DS to get LTIK-1/CIK-1 public keys published.

Then the client:

Sends Update Proposal message, signed by LTIK-0, which includes CIK-1, as opposed to just an HPKEPublicKey.
Updates DirectPath
Sends Commit message, signed by LTIK-0, which includes new DirectPath

Receiving clients need to:

Check that the Update is signed by LTIK-0 and that LTIK-0 is trusted
Check that CIK-1 is signed by the embedded LTIK-1
Check that LTIK-1 is trusted
Update the sender's LeafNodeInfo with LTIK-1 and CIK-1 public key

Subsequent messages sent by the client are signed using LTIK-1.

Thoughts?
Owen