Add direct KDFs

[chrysn]

For use with OSCORE, it would be convenient to have COSE's direct key KDFs available (basically, a way to use the tables from COSE's table16).

Are there any plans to add support for that, would you accept PRs to that effect, or do you have concrete ideas on interface requirements for those?

[chrysn]

To be more precise, what I'd need (and consider adding) is wrapping the necessary lower-library primitives to implement KDFs at the level of crypto.h which I'd use directly; I'm not sufficiently familiar with non-OSCORE COSE applications to understand where those could be useful in general).

[chrysn]

For my application, it may also be sufficient to just expose the underlying HMACs, if they are relevant to the rest of COSE.

(The reason why I'd be also happy with that is that OSCORE uses only HMACs, which allows the optimization of splitting up the extraction and expansion steps for the (definitely happening) case when subsequent operations extract from the same key material but expand with different info elements.)

From the API point of view, if the info could be fed into the KDF segment-wise (you mentioned considerations for incremental APIs), that'd great as the info data don't come pre-assembled in a single buffer.

[chrysn]

I think I can tell apart a bit better now what I'll need and what would have a good place in a generic COSE implementation:

• The "direct key with KDF" mechanisms have their place in COSE. API-wise, they'd probably expose something like "Given the secret X, give me the content encryption key (alternatively, the IV) derived using algorithm Y (which is a direct+xKDF algorithm) for partyU nonce Z". The application does not do any stream-feeding into the library, and the library uses its knowledge of the CBOR object to build and to feed into the HKDF actual. (where "xKDF" stands for "probably HKDF, but could be any KDF really")
• What I'd use of this is, similar to what I'm doing in the AEAD cases, to take the workhorse function of the above COSE public thing and say "Using algorithm Y (which is a direct+xKDF algorithm, but only used as an xKDF algorithm in this context), compute me the derived key for the input I'll be feeding to you piecemeal".

Background: OSCORE is using the same numbers as direct+xKDF algorithms (at least when explicitly talking about the algorithms explicitly, like they do in the hkdf field of oscore-profile, but the actual input material fed into the HKDF is not structured like in COSE, but a bespoke CBOR structure.

[chrysn]

What's more, both APIs could offer optimizations for HKDFs that follow the extract-and-expand phases -- an application that does multiple key derivation from the same secret and different nonces could profit from doing the extract step once, storing the extracted material and doing the expand step multiple times.

For a first design stage, ignoring that in the API is probably good enough; if later the need for it does come up, it can still be added, and the original API would then become a convenience wrapper for applications with simple needs.