Change:
MLSMessageContent is authenticated using the MLSMessageAuth structure. <del> The "signature" field in an MLSMessageAuth object is computed using the signing private key corresponding to the public key, which was authenticated by the credential at the leaf of the tree indicated by the sender field.  The signature is computed using "SignWithLabel" with label ""MLSMessageContentTBS"" and with a content that covers the message content and the wire format that will be used for this message.  If the sender is a member of the group, the content also covers the GroupContext for the current epoch, so that signatures are specific to a given group and epoch. </del> <ins> The signature is computed using "SignWithLabel" with label ""MLSMessageContentTBS"" and with a content that covers the message content and the wire format that will be used for this message.  If the sender's "sender_type" is "Member", the content also covers the GroupContext for the current epoch, so that signatures are specific to a given group and epoch. The sender MUST use the private key corresponding to the following signature key depending on the sender's "sender_type": "member": The signature key contained in the Credential at the leaf with the sender's "LeafNodeRef" "external": The signature key contained in the Credential at the index indicated by the "sender_index" in the "external_senders" group context extension (see Section external-senders-extension). In this case, the "content_type" of the message MUST NOT be "commit", since only members of the group or new joiners can send Commit messages. "new_member": The signature key depends on the "content_type": "proposal": The signature key in the credential contained in KeyPackage in the Add proposal (see Section external- proposals). "commit": The signature key in the credential contained in the KeyPackage in the Commit's path (see Section external- initialization). Recipients of an MLSMessage MUST verify the signature with the key depending on the "sender_type" of the sender as described above. </ins> The confirmation tag value confirms that the members of the group have arrived at the same state of the group.

Discussion:
This PR: consolidates instructions on which key should be used to compute (and verify) a signature on an MLS message depending on the sender type reverts introduces a extension that ensures that group members agree on preconfigured signature keys, as discussed in and on the mailing list
As , the current preconfigured sender mechanism isn't interoperably specified. There is no confirmation that the members of a group agree on who the allowed preconfigured senders are, so different members might respond differently. It seems like there are two options here: Add the required details. We would need a extension to confirm agreement to use the mechanism at all, and would probably need to have a list of senders there as well. Remove the feature from the base protocol. Since an extension is required in any case, there's no pressing need to have the feature in the base protocol. Personally, I would lean toward (2). Early deployment experience doesn't show a lot of need for this feature. For example, in Webex, we just have the server forward a KeyPackage instead of synthesizing an Add proposal under a preconfigured signer; the TLS authentication is as good as a preconfigured signer signature. As long as the SenderType enum is around, the extension should be a small follow-on spec if it is really needed.
NAME and I would probably prefer the first option. I will write up a more detailed reason and post to the mailing list, but the TLDR is basically that in a really long session in async messaging, server driven proposals save you from some painful logic, and the extension would improve this to allow for interop / federation cases.
I am pretty clearly in favor of option 1. Pre-configured senders are playing a key role for us in implementing automation of backend-initiated changes to the group. Things like: initiating the removal of Bob('s phone) because his account (or device) was deprovisioned. announcing a change to the group's properties due to system wide policy changes. Having an audit trail (i.e. the preconfigured sender's signature on the proposal) makes this a lot easier for the group to authenticate why this action is being committed to by group members. (Also, external commits are not a good alternative as they have the unwanted side-effect of the preconfigured sender learning the new epoch's key schedule.)

As for how to agree on preconfigured sender public keys, I think a minimal solution could be to have a list of preconfigured sender public keys as a group context extension. We already have a mechanism to change it during the life time of the group (via groupcontextextensions proposal) so its a pretty small change to the the RFC.
Thanks Joël, NAME that covers my feedback as well, no need for mailing list follow up
That sounds fine to me. NAME want to write up a PR? It seems like something of the following form: The idea being that BasicCredential already has the (id, public key) pair that you would need, so you would just need to say that when , is the field from the corresponding BasicCredential. (Also probably rename to .)
Or actually, you could do things even more simply by just having the extension be a list of , and having be a index into the array.
Ok no problem. I'll take a look today and propose something and we can iterate
What do you think about it just being credential instead of basic credential?
I had the same thought. Since I kicked off the discussion, I felt the need to take a stab at closing it and I included the input from this threat and the list. See . My main goal was to consolidate the instructions on signature computation and verification and I thought I might as well deal with the preconfigured senders as well. Let me know if you want to take your own stab at the preconfigured senders extension and I'll remove that part from the PR.
Thanks NAME , glad I put this off until now :-) I'll take a look at your PR
Here's the Weekly Digest for : - - Last week 3 issues were created. Of these, 0 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by - - Last week, 4 pull requests were created, updated or merged. Last week, 3 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there was 1 commit. :hammerandwrench: by - - Last week there was 1 contributor.

:bustin_silhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Thanks for tackling this, looks good I think we are fully aligned on that. We have already departed by allowing preconfigured senders: "The preconfigured SenderType is reserved for signers that are pre-provisioned to the clients within a group. If proposals with these sender IDs are to be accepted within a group, the members of the group MUST be provisioned by the application with a mapping between these IDs and authorized signing keys. Recipients MUST verify that the MLSPlaintext carrying the Proposal message is validly signed with the corresponding key. To ensure consistent handling of external proposals, the application MUST ensure that the members of a group have the same mapping and apply the same policies to external proposals.” With preconfigured senders, it is up to the AS to verify signatures and thus to ensure authenticity. Having a new sender type for indirections would be no different. Btw, we also don’t have an extension to make sure that everyone in the group supports preconfigured senders. We just assume that this is somehow handled on the application level. So following this logic we should introduce an extension for that as well for robustness. These details aside, my main worry is that we shut the door to any (future) deniable authentication if don’t allow this indirection now. We’ve been very flexible to accommodate all sorts of AS configurations so far (BasicCredentials, X.509, preconfigured senders), why not this one? I think it is very reasonable to keep the door open, given that there has been sufficient support for this in the past. Again, any implementation that does not wish to support it is not forced to support it. In fact, I suspect that in many deployment scenarios preconfigured senders won’t be allowed either. Raphael