Code change:
public key for the credential in the "leaf_key_package" of the "path" field. <del> An external commit MUST reference no more than one ExternalInit proposal, and the ExternalInit proposal MUST be supplied by value, not by reference.  When processing a Commit, both existing and new members MUST use the external init secret as described in external-initialization. </del> <ins> When processing a Commit, both existing and new members MUST use the external init secret as described in external-initialization. </ins> The sender type for the MLSPlaintext encapsulating the External Commit MUST be "new_member" <del> If the Add Proposal is also issued by the new member, its member SenderType MUST be "new_member" </del> <ins> In other words, External Commits come in two "flavors" - a "join" commit that adds the sender to the group or a "resync" commit that replaces a member's prior appearance with a new one. Note that the "resync" operation allows an attacker that has compromised a member's signature private key to introduce themselves into the group and remove the prior, legitimate member in a single Commit.  Without resync, this can still be done, but requires two operations, the external Commit to join and a second Commit to remove the old appearance.  Applications for whom this distinction is salient can choose to disallow external commits that contain a Remove, or to allow such resync commits only if they contain a "reinit" PSK proposal that demonstrates the joining member's presence in a prior epoch of the group.  With the latter approach, the attacke would need to compromise the PSK as well as the signing key, but the application will need to ensure that continuing, non-resync'ing members have the required PSK. </ins> 11.2.2.

Related discussion:
text: NAME NAME r?
Discussed at 20211004 interim, remove resynch with a single op (external join + remove in one op). NAME research why resynch was dropped.
A good point was raised by Jonathon Hoyland during the MLS IETF 109 meeting regarding possible concerns in using external commits for resync, particularly in the case of Alice adding/removing herself. Richard noted that this is a feature in the case that Alice is no longer synchronized with the group and therefore can use an external commit to add herself back in, removing the previous version. As opposed to any newcomer joining with an external commit, the case of Alice re-joining presents a potential security issue. Namely, as currently specified (in my reading of the draft), an existing group member, Bob, has no means to distinguish between the following cases: 1) Alice needs to resync and therefore performs an external commit and removes her prior version. 2) Alice’s signature keys are compromised (it is not necessary for the adversary to compromise any group state). The adversary performs an external commit in Alice’s name, and then removes her prior version and impersonates her to the group. One might hope that Alice notices that she is removed and communicates this to the group members OOB, but it is also possible that that she assumes some other reason for the removal, is offline, or simply is not active enough to take action for a fairly long compromise window. Even if she tries to use an external commit to get back into the group and then removes the adversary-as-Alice, there is no means for other group members distinguish the real Alice from the adversary-as-Alice and the process could be circular (until new valid identity keys are issued). While a newcomer is a fresh source to be trusted or not, Alice has been “healing” along with the group and the above option (2) allows the adversary to bypass all of that. The source of the problem is that when Alice re-syncs, she is not providing any validation of being the same/previous identity, so it is easy for other group members to accept that nothing more than a resync has taken place. Thus, a fairly straightforward solution is to require PSK use in cases where an external commit is used for resync.