I've now managed to use this from within libOSCORE, and it's working alright and produces correct values. (The sodium implementation fails to implement larger seeds, though).

Things I've observed:

• Placing HKDF is a funny intermediate thing. Crypto primitive libraries tend not to offer it because it's easy enough for the user, so it doesn't fit well with the cose_crypto_ style parts -- but high-level COSE doesn't have a primitive for it either: It has a concept of HMACs (eg. algorithms 5, 6, 7) and of HKDF-based key derivation, but that's still a level higher up (-10, -11) that do use HKDF as a component.
  Not sure yet what to make out of this in terms of where to put it in here.
• Streaming data into HKDFs is gon' be fun. The unbounded data can sit in the seed, the IKM or the info. For salt and IKM it's gonna be the same situation as with plain HMAC: salt (the HMAC's key) and IKM (the HMAC's input) might both be stream-worthy. For HMAC the sequence would be to stream in the key first (thus for HKDF, the salt), condensing it to one block size, and then the input (for HKDF, the IKM). Then, streaming in the info is even more fun, because that may be needed multiple times in a row, depending on the output size measured in block sizes.

With the streaming situation becoming complex, it may really be the better idea to implement HMAC streaming-ready (which is tricky on its own), and then to experiment with an HKDF API built on that, probably based on splitting the extract and expand steps.

That's all the streaming roadmap, anyway. If we're good with a v1 stream-free API, what's can be good enough. (Especially considering that cose_crypto_* is not really part of the public API but rather something I've coopted for my devious uses). So far, I'm getting away doing upper-bounds estimates all around.

#120 is in so this can be closed