Change:
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

Discussion:
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.