Change:
For example, in order to communicate the example update described in the previous section, the sender would transmit the following values: <del> In this table, the value pk(X) represents the public key derived from the node secret X.  The value E(K, S) represents the public-key encryption of the path secret S to the public key K. </del> <ins> In this table, the value pk(ns[X]) represents the public key derived from the node secret X, whereas pk(X) represents the public leaf key for user X.  The value E(K, S) represents the public-key encryption of the path secret S to the public key K. After processing the update, each recipient MUST delete outdated key material, specifically: The path secrets used to derive each updated node key pair. Each outdated node key pair that was replaced by the update. </ins> 6.

Discussion:
This PR does the following: Adds a lead-in sentence describing how this section builds on the prior. Differentiates between public keys for nodes and public keys for leaves (users) Clarifies when secret key material needs to be deleted. I also wanted to make a couple other changes, but wanted feedback first. This section describes the private value corresponding to a node's public key as 'ns[0]' (or node secret), whereas the prior section referred to it as 'np[0]' (or node_priv). It would be better to have these terms be consistent. On line 773, it says that the client "...transmits a handshake message containing a set of public values" and on line 776 it says that "other members of the group can use these public values to update". However, this values seems to be contradictory with the value listed on line 785. The current terminology is unclear regarding 1) a Commit to the tree, 2) an update to the tree, and and 3) a handshake message. I think these are very similar but using the same language consistently would be better (such as defining a Commit as what updates the tree, and then describing how the handshake message is different from a Commit message, which is described earlier in the spec).
Thanks for looking through this, NAME There's a lot of historical baggage here, so it's good to get it cleaned up. I'll review the diff in a moment, but to respond to your points: Just to confirm terminology here, there are three values in play, (1) a symmetric secret, (2) a KEM private key derived from the secret, and (3) the corresponding public key. It should be the case that you only need to store the latter two in the tree (priv+pub), since the secrets are used transiently: For deriving the tree key pairs, for deriving the commit secret, and for initializing new members added in an epoch. stores the node secrets to simplify these operations, but it feels like it should be possible to arrange things so that this isn't necessary. So I think the right answer here is to just refer to node private keys. Line 785 is correct, the Commit contains a public key and encrypted copies of the path secret for each node. So the text should refer to public and encrypted private values as necessary.

The right taxonomy here is: "Handshake message" encompasses and . Processing the Commit is the thing that causes an update to the tree; more specifically, applying a DirectPath. So we should only talk about handshake messages when we want to cover both Proposals and Commits, and most instances of "update" should probably refer to either Commit or DirectPath.