Original text:
for nodes in its direct path that are being reset by the corresponding Commit. <del> In the description of the tree as a list of nodes, the "key_package" field for a node MUST be populated if and only if that node is a leaf in the tree. </del>  On receiving a Welcome message, a client processes it using the following steps: Verify the integrity of the ratchet tree.  For each non-empty parent node, verify that exactly one of the node's children are non-empty and have the hash of this node set as their "parent_hash" value (if the child is another confirmation key and the "confirmed_transcript_hash" from the GroupInfo.  11. This protocol includes a mechanism for negotiating extension the value of the extension in the GroupContext, according to the semantics of the specific extension. <del> A client joining a group MUST populate the GroupContext extensions with exactly the contents of the extensions field in the Welcome message.  If any extension is unrecognized (i.e., not contained in the corresponding KeyPackage), then the client MUST reject the Welcome message and not join the group. </del>  Note that the latter two requirements mean that all MLS extensions are mandatory, in the sense that an extension in use by the group

Reviewer comments:
A couple of shortcomings to note on this PR: The joiner can't compute their private keys because they're not told where they are in the tree or how big the tree is. The former should be added to and the latter to . This approach assumes that the joiner gets the tree OOB before processing the Welcome, otherwise they can't verify the signature on the Welcome. (Since Welcome presumes they get the credential for the signer from the tree.) We could avoid the latter problem by including a credential for the signer and a "membership proof" comprising the hashes needed to tie that leaf to the tree hash in the Welcome. That could allow participants to remain "passive" (without a full tree, just their private keys) for longer, especially if such a proof could be provided on Commit as well. This might be a good candidate for an extension, though.
Discussion at the 2020-07-14 interim indicated that we should go ahead with this strategy, and just note the requirement that you have to get the tree before you process the Welcome.
I remember we discussed this in the past, but I don't think we ever spec'ed this out fully: Right now the whole tree is part of (which in turn is part of ). This can grow quite big in large groups (~17MB with 100k members with the MTI). The practical limitations are: The TLS representation of the tree is hard to parse efficiently (no skipping and no a priori information of how many nodes are in the tree) Out-of-band transmission (like server assist) is not possible Large messages like that are hard to handle on mobile devices, when they have to be downloaded in the background We should introduce an indirection, like a commit hash of the tree.

Revised text:
for nodes in its direct path that are being reset by the corresponding Commit.  <ins> The client processing a Welcome message will need to have a copy of the group's ratchet tree.  The tree can be provided in the Welcome message, in an extension of type "ratchet_tree".  If it is sent otherwise (e.g., provided by a caching service on the Delivery Service), then the client MUST download the tree before processing the Welcome. </ins> On receiving a Welcome message, a client processes it using the following steps: Verify the integrity of the ratchet tree. <ins> Verify that the tree hash of the ratchet tree matches the "tree_hash" field in the GroupInfo. </ins> For each non-empty parent node, verify that exactly one of the node's children are non-empty and have the hash of this node set as their "parent_hash" value (if the child is another confirmation key and the "confirmed_transcript_hash" from the GroupInfo. <ins> 10.3. By default, a GroupInfo message only provides the joiner with a commitment to the group's ratchet tree.  In order to process or generate handshake messages, the joiner will need to get a copy of the ratchet tree from some other source.  (For example, the DS might provide a cached copy.)  The inclusion of the tree hash in the GroupInfo message means that the source of the ratchet tree need not be trusted to maintain the integrity of tree. In cases where the application does not wish to provide such an external source, the whole public state of the ratchet tree can be provided in an extension of type "ratchet_tree", containing a "ratchet_tree" object of the following form: The presence of a "ratchet_tree" extension in a GroupInfo message does not result in any changes to the GroupContext extensions for the group.  The ratchet tree provided is simply stored by the client and used for MLS operations. If this extension is not provided in a Welcome message, then the client will need to fetch the ratchet tree over some other channel before it can generate or process Commit messages.  Applications should ensure that this out-of-band channel is provided with security protections equivalent to the protections that are afforded to Proposal and Commit messages.  For example, an application that encrypts Proposal and Commit messages might distribute ratchet trees encrypted using a key exchanged over the MLS channel. </ins> 11. This protocol includes a mechanism for negotiating extension the value of the extension in the GroupContext, according to the semantics of the specific extension.  <ins> If any extension in a GroupInfo message is unrecognized (i.e., not contained in the corresponding KeyPackage), then the client MUST reject the Welcome message and not join the group. The extensions populated into a GroupContext object are drawn from those in the GroupInfo object, according to the definitions of those extensions. </ins> Note that the latter two requirements mean that all MLS extensions are mandatory, in the sense that an extension in use by the group