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: We can pass to the concatenation of and . When is undefined/empty, test vectors are not affected. I guess this is what NAME is referring to?
label is a CBOR byte string. While alt 2 use an CBOR array. Definging alt2 as a wrapper seems more complication in my view.
Would be good if people stated alt 1. or alt 2. or made a concrete suggestion for alt 3.
Alt 3 (CBOR sequence) 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, labelcontext, length) where is a CBOR sequence: If you want to keep the test vectors intact, then you could make optional in the CDDL, but not sure how to specify an optional parameter in the interface definition.
Thanks. That is a valid alt 3. but ctx should probably be a bstr
I don't think keeping the test vectors intact is an important goal at all. Let's decide on what is simplest for a user of the exporter interface.
Something like that, yes. Later post do differentiate the type of "label" and "ctx" and in light of that and changing test vectors Alt3 seems clean.
I am fine with alt 3. I can start making PR for that unless somebody has different ideas. I don't alt 1 is a good alternative anymore as is restricts context to being a unicode string. Which would require some base64 encoding or similar for a general context.
Please review alt. 3 as specified in . Unless there are any comments we would like to merge this.
This is included in -07 so I close the issue.
Comment by Martin Disch in URL "The draft does a good job of pointing to the right places in RFC 8152, but I still ended up trying to understand another ~100 page document just to implement the few constructs I actually needed." Should we provide more details about COSE constructs, e.g. in appendix A.2?
(pasting my response from the mailing list here for completeness) Thanks for following up on this. Yes, in my opinion expanding on the COSE constructs would be helpful.