[MLS] Possible erratum: Re-adding a member

[Richard Barnes <[e-mail]>]

Hi all,

I came across a situation where I think the spec might be ambiguous, if not
incorrect.  Consider a situation where a member is removed and re-added in
the same Commit, using the same signature key for both the old and the new
member, but fresh keys otherwise.  Is this a legal commit?

(Note that in addition to normal commits of this form, the "resync"
external commits that the spec mentions also have this form.)

On the one hand: The spec says that a proposal list is invalid if...
- [12.2] It contains an individual proposal that is invalid as
specified in Section
12.1 <https://www.rfc-editor.org/rfc/rfc9420.html#proposals>.
- [12.1.1] An Add proposal is invalid if the KeyPackage is invalid
according to Section 10.1
<https://www.rfc-editor.org/rfc/rfc9420.html#keypackage-validation>
- [10.1] Verify that the leaf_node of the KeyPackage is valid for a
KeyPackage according to Section 7.3
<https://www.rfc-editor.org/rfc/rfc9420.html#leaf-node-validation>.
- [7.3] Verify that the following fields are unique among the members of
the group: signature_key

On the other hand: The spec also says (emphasis mine):
- [12.2] It contains an Add proposal with a KeyPackage that represents a
client already in the group according to the application, *unless there is
a Remove proposal in the list removing the matching client from the group*.

So if you read "members of the group" in the former text as "members of the
group before any of the proposals are applied", then my proposed Commit is
illegal.  If you read it as "members of the group after any Remove
proposals are applied" (as in the latter text), then the proposed Commit is
fine.

Personally, I think the right answer here is for such a Commit to be
valid.  Basically because I don't think a "resync" operation (either
externally-driven or within the group) should force a signature key
rotation, because signature key rotation is expensive when signature keys
are tied to things like transparency or certificates.

If we can get agreement on the outcome here, it seems like we should
probably file an erratum clarifying the situation.

Thanks,
--Richard