Original text:
The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf is the output of a successful EDHOC exchange.  Keys for applications are <del> derived from PRK_out, see exporter.  An application using EDHOC- KeyUpdate needs to store PRK_out.  If EDHOC-KeyUpdate is not used, an application only needs to store PRK_out or PRK_exporter as long as EDHOC-Exporter is used.  (Note that the word "store" used here does not imply that the application has access to the plaintext PRK_out since that may be reserved for code within a TEE, see impl-cons). </del>  4.2. <del> This section defines EDHOC-Exporter and EDHOC-KeyUpdate in terms of EDHOC-KDF and PRK_out. </del>  4.2.1. PRK_exporter is derived from PRK_out: where hash_length denotes the output size in bytes of the EDHOC hash <del> algorithm of the selected cipher suite.  Note that PRK_exporter changes every time EDHOC-KeyUpdate is used, see keyupdate. </del>  The (exporter_label, context) pair used in EDHOC-Exporter must be unique, i.e., an (exporter_label, context) MUST NOT be used for two Examples of use of the EDHOC-Exporter are given in transfer. <del> 4.2.2. To provide forward secrecy in an even more efficient way than re- running EDHOC, EDHOC provides the optional function EDHOC-KeyUpdate. When EDHOC-KeyUpdate is called, a new PRK_out is calculated as a "hash" of the old PRK_out using the Expand function as illustrated by the following pseudocode.  The change of PRK_out causes a change to PRK_exporter and derived keys using EDHOC-Exporter. where hash_length denotes the output size in bytes of the EDHOC hash algorithm of the selected cipher suite. The EDHOC-KeyUpdate takes a context as input to enable binding of the updated PRK_out to some event that triggered the keyUpdate.  The Initiator and the Responder need to agree on the context, which can, e.g., be a counter or a pseudorandom number such as a hash.  To provide forward secrecy the old PRK_out and derived keys must be deleted as soon as they are not needed.  When to delete the old keys and how to verify that they are not needed is up to the application. I-D.ietf-core-oscore-key-update describes key update for OSCORE using EDHOC-KeyUpdate. While this key update method provides forward secrecy it does not give as strong security properties as re-running EDHOC, see security. </del> 5. This section specifies formatting of the messages and processing CWT, X.509, C509).  None of the credential types are mandatory-to- implement. <del> Implementations MUST support the EDHOC-Exporter.  Implementations SHOULD support EDHOC-KeyUpdate. </del>  Implementations MAY support message_4.  Error codes (ERR_CODE) 1 and 2 MUST be supported. As required by RFC7258, IETF protocols need to mitigate pervasive monitoring when possible.  EDHOC therefore only supports methods with <del> ephemeral Diffie-Hellman and provides a KeyUpdate function for lightweight application protocol rekeying with forward secrecy, in the sense that compromise of the private authentication keys does not </del>  compromise past session keys, and compromise of a session key does <del> not compromise past session keys. While the KeyUpdate method can be used to meet cryptographic limits and provide partial protection against key leakage, it provides significantly weaker security properties than re-running EDHOC with ephemeral Diffie-Hellman.  Even with frequent use of KeyUpdate, compromise of one session key compromises all future session keys, and an attacker therefore only needs to perform static key exfiltration RFC7624.  Frequently re-running EDHOC with ephemeral Diffie-Hellman forces attackers to perform dynamic key exfiltration instead of static key exfiltration RFC7624.  In the dynamic case, the attacker must have continuous interactions with the collaborator, which is more complicated and has a higher risk profile than the static case. </del>  To limit the effect of breaches, it is important to limit the use of symmetrical group keys for bootstrapping.  EDHOC therefore strives to shared secret) leads to compromise of all session keys derived from that compromised shared secret.  Compromise of one session key does not compromise other session keys.  Compromise of PRK_out leads to <del> compromise of all keying material derived with the EDHOC-Exporter since the last invocation (if any) of the EDHOC-KeyUpdate function. </del>  Based on the cryptographic algorithms requirements sec_algs, EDHOC provides a minimum of 64-bit security against online brute force

Reviewer comments:
Replacing a session key with its hash for forward secrecy as specified with EDHOC-KeyUpdate, can alternatively be defined by the application as is done in KUDOS (draft-core-oscore-key-update). For this reason there is no need to recommend EDHOC-KeyUpdate as is done in Section 7. "Implementations SHOULD support EDHOC-KeyUpdate." EDHOC-KeyUpdate can useful in other applications but the description should be moved out of the body in the interest of focusing on the core functionality of EDHOC.
Discussed in the interim and PR merged.

Revised text:
The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf is the output of a successful EDHOC exchange.  Keys for applications are  <ins> derived from PRK_out, see exporter.  For the purpose of using EDHOC- Exporter, an application only needs to store PRK_out or PRK_exporter. (Note that the word "store" used here does not imply that the application has access to the plaintext PRK_out since that may be reserved for code within a TEE, see impl-cons). </ins> 4.2.  <ins> This section defines EDHOC-Exporter in terms of EDHOC-KDF and PRK_out. </ins> 4.2.1. PRK_exporter is derived from PRK_out: where hash_length denotes the output size in bytes of the EDHOC hash  <ins> algorithm of the selected cipher suite. </ins> The (exporter_label, context) pair used in EDHOC-Exporter must be unique, i.e., an (exporter_label, context) MUST NOT be used for two Examples of use of the EDHOC-Exporter are given in transfer.  5. This section specifies formatting of the messages and processing CWT, X.509, C509).  None of the credential types are mandatory-to- implement.  <ins> Implementations MUST support the EDHOC-Exporter. </ins> Implementations MAY support message_4.  Error codes (ERR_CODE) 1 and 2 MUST be supported. As required by RFC7258, IETF protocols need to mitigate pervasive monitoring when possible.  EDHOC therefore only supports methods with  <ins> ephemeral Diffie-Hellman.  This provides forward secrecy, in the sense that compromise of the private authentication keys does not </ins> compromise past session keys, and compromise of a session key does  <ins> not compromise past session keys.  Frequently re-running EDHOC forces attackers to perform dynamic key exfiltration where the attacker must have continuous interactions with the collaborator, which is a significant complication. </ins> To limit the effect of breaches, it is important to limit the use of symmetrical group keys for bootstrapping.  EDHOC therefore strives to shared secret) leads to compromise of all session keys derived from that compromised shared secret.  Compromise of one session key does not compromise other session keys.  Compromise of PRK_out leads to  <ins> compromise of all keying material derived with the EDHOC-Exporter. </ins> Based on the cryptographic algorithms requirements sec_algs, EDHOC provides a minimum of 64-bit security against online brute force