Code change:
Application keys and other application specific data can be derived using the EDHOC-Exporter interface defined as: <del> where label is a tstr defined by the application and length is a uint defined by the application.  The label SHALL be different for each different exporter value.  The transcript hash TH_4 is a CBOR encoded bstr and the input to the hash function is a CBOR Sequence. </del> <ins> label_context is a CBOR sequence: </ins> <del> where H() is the hash function in the selected cipher suite.  Example use of the EDHOC-Exporter is given in I-D.ietf-core-oscore-edhoc. </del> <ins> where label is a registered tstr from the EDHOC Exporter Label registry (exporter-label), context is a bstr defined by the application, and length is a uint defined by the application.  The (label, context) pair must be unique, i.e. a (label, context) MUST NOT be used for two different purposes.  However an application can re-derive the same key several times as long as it is done in a secure way.  For example, in most encryption algorithms the same (key, nonce) pair must not be reused. The transcript hash TH_4 is a CBOR encoded bstr and the input to the hash function is a CBOR Sequence. where H() is the hash function in the selected cipher suite. Examples of use of the EDHOC-Exporter are given in asym-msg4-proc and I-D.ietf-core-oscore-edhoc. </ins> To provide forward secrecy in an even more efficient way than re- running EDHOC, EDHOC provides the function EDHOC-KeyUpdate.  When EDHOC-KeyUpdate is called the old PRK_4x3m is deleted and the new <del> PRk_4x3m is calculated as a "hash" of the old key using the Extract </del> <ins> PRK_4x3m is calculated as a "hash" of the old key using the Extract </ins> function as illustrated by the following pseudocode: 5.

Related discussion:
text: The motivation for "context" or "label postfixes" is to increase the flexibility for the application. Restricting the application to IANA registered labels is very limiting. An application might want to use the EDHOC exporter to derive a number of keys and we should encourage that. The alternative is that the application needs to implement its own key derivation, which might be less secure and might be outside of the TEE. I called it "context" just because TLS calls the paramater in its exporter context.
"Be like TLS" is of course a good motivation. Technically, a label prefix is not different from a context, it just saves the need to separate prefix and suffix.
(And of course there is nothing wrong with multiple calls with the same label; the application has a "right to forget" :-)
The solutions should be equal when it comes to security. The choice should be made based on what is easiest for implementators and apllications using EDHOC. Alt 1. We make an IANA register for label prefixes: "OSCORE Master Secret" "OSCORE Master Salt" The Export function stays the same: EDHOC-Exporter(label, length) = EDHOC-KDF(PRK4x3m, TH4, label, length) An application is allowed to append things to the label prefix: "OSCORE Master Secret" "OSCORE Master Secret PickleRick" Alt 2. We make an IANA register for labels: label = "OSCORE Master Secret" label = "OSCORE Master Salt" The Export function needs to change: EDHOC-Exporter(label, ctx, length) = EDHOC-KDF(PRK4x3m, TH4, [label, ctx] , length) An application is not allowed to append things to the label and uses the ctx instead: label = "OSCORE Master Secret" ctx = "" label = "OSCORE Master Secret" ctx = "PickleRick"
No major opinion. Alt 2 breaks the test vector for the OSCORE security context. It would be good to get more input.
Any preference NAME NAME NAME ?
If desired the CTX is more convenient it can always be added in a wrapper on top of EDHOC-Exporter(). (I assume re-use of label+ctx in Alt 2 is equivalent to re-use of label in Alt 1?)
I prefer to have explicitly specified.