Code change:
9.6. <del> The main MLS key schedule provides a "resumption_secret" that is used as a PSK to inject entropy from one epoch into another.  This </del> <ins> The main MLS key schedule provides a "resumption_psk" that is used as a PSK to inject entropy from one epoch into another.  This </ins> functionality is used in the reinitialization and branching processes described in reinitialization and sub-group-branching, but may be used by applications for other purposes. Some uses of resumption PSKs might call for the use of PSKs from historical epochs.  The application SHOULD specify an upper limit on <del> the number of past epochs for which the "resumption_secret" may be </del> <ins> the number of past epochs for which the "resumption_psk" may be </ins> stored. 9.7. <del> The main MLS key schedule provides a per-epoch "authentication_secret".  If one of the parties is being actively impersonated by an attacker, their "authentication_secret" will differ from that of the other group members.  Thus, members of a group MAY use their "authentication_secrets" within an out-of-band authentication protocol to ensure that they share the same view of the group. </del> <ins> The main MLS key schedule provides a per-epoch "authentication_code". If one of the parties is being actively impersonated by an attacker, their "authentication_code" will differ from that of the other group members.  Thus, members of a group MAY verify out of band that their "authentication_code" values are all the same, in order to ensure that they share the same view of the group. </ins> 10.

Related discussion:
text: In the key schedule we have the following: senderdatasecret | "sender data" encryptionsecret | "encryption" exportersecret | "exporter" authenticationsecret | "authentication" externalsecret | "external" confirmationkey | "confirm" membershipkey | "membership" resumptionsecret | "resumption" It would be best to provide a coherency to how we use these terms and check for consistency throughout, to avoid confusion for readers: A simple solution would be to use "secret" for all cases, i.e., changing membershipkey to membershipsecret.Another alternative, which may take more refining but could be useful to readers is to separate out terms based on items that are for internal protocol use versus external protocol use. For example, encryption, confirmation, membership, etc., would use "key" and exporter, authentication, etc., could use "secret", or vice versa. --Break-- Ref the mailinglist on confirmation vs authentication secrets, perhaps the naming of these two are a little misleading - authentication normally being within bounds of a protocol while confirmation is external to it. This confusion probably sparked some of that discussion to begin with. It could_ be worth considering switching those terms for clarity.
I actually think we have a fairly coherent taxonomy here: "secret" is something that gets fed into HKDF to derive further things "key" is something that gets fed into another algorithm, e.g., HMAC Looking through the list, the ones that deviate from this pattern are: , which is exported to the application but expected to be kept private , which is exported to the application but not expected to be kept private Given that, I would propose we update the table in question to something like the following, using because that's how it's used, and to follow the "security code" terminology used by applications:
Things are easier to understand like this! The "Purpose" column is quite valuable I think, I remember I was quite overwhelmed when I first read it and had no idea what all those secret / keys were used for. This helps to understand the big picture.