Change:
In the latest commit there are new names to distinguish infolabel and exporterlabel, the former is extended to be int. I also noted an error in the CDDL reference section C.2.
The current design of encryption of message2 in EDHOC limits the size of the message to 8160 bytes when SHA-256 is used. Is that a problem? message2 consists of the fields GY IDCREDR SignatureorMAC2 CR and optional fields: ? PAD2 ? EAD2 While these message fields could be very small, depending on use case, some may be arbitrarily large. The field IDCREDR would typically be a reference to an authentication credential, but may contain the credential itself, for example a certificate chain. EAD2 is defined by the application so may a priori be large. One example is revocation information. John: SHA-384 has the limit 12240 bytes and SHA-512 has the limit 16320 bytes. SHAKE128 and SHAKE256 have much much larger limits (2^2040 − 1 bits)
Some of the alternatives: Do nothing / this is not a problem Replace HKDF with HKDF', which allows larger length of output Use HKDF for message2 size < 8160, HKDF' for larger message2 Replace message_2 encryption with AES-CTR / ChaCha20 Use KMAC instead of HKDF Edit: Multiple applications of HKDF, to produce sufficiently long keystream John: HKDF' here refer only to HKDF-Expand. HKDF-Extract would stay the same. John: HKDF' would still be HKDF but not HKDF as specified in RFC 5869. The original HKDF paper just states that the counter is fixed length. RFC 5869 unfortunately chose 1 byte. URL
It seems that this is a concern if/when GY or SignatureorMAC2 becomes one of the monstrous Post-Quantum algorithms, or a HSS. I think that we should rule that out of scope, say that when it happens that we'll do EDHOC2 based upon new constraints at the time. I think that 8K is probably enough for the certificate chain. That's a lot (100) of 802.15.4 fragments. So unless switching to HKDF' is really cheap, don't bother.
Thanks Michael. Yes, the assumption so far has been "this is not a problem". NAME It would be good to understand the impact on implementation if we would come to a different conclusion. Please comment, on the examples below. Replace HKDF with HKDF', which allows larger length of output HKDF is constructed from HMAC using a counter which is 8 bits long. By defining HKDF' with 16 / 32 bits counter would make the output 2 MB / 137 GB (if I did the maths right) before the counter wraps. How is HKDF implemented today? Is it feasible to define your own variant, say with 32 bits counter? Use HKDF for message2 size >
PR is included in -16

Discussion:
where <del> label is a uint </del> <ins> info_label is an int </ins> context is a bstr

where <del> label is a registered uint from the EDHOC Exporter Label registry (exporter-label) </del> <ins> exporter_label is a registered uint from the EDHOC Exporter Label registry (exporter-label) </ins> context is a bstr defined by the application

algorithm of the selected cipher suite.  Note that PRK_exporter changes every time EDHOC-KeyUpdate is used, see keyupdate. <del> The (label, context) pair used in EDHOC-Exporter 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 can be reused with different nonces.  The context can for example be the empty CBOR byte string. </del> <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 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 can be reused with different nonces.  The context can for example be the empty CBOR byte string. </ins> Examples of use of the EDHOC-Exporter are given in transfer.