Note that this is not quite trivial to test because using the test vector credential by value (it is relatively long given we use p256 and not x25519, and on top of that has a serial number in it) exceeds the 256 default length by some bytes.

I think this is showing a few cases where instead of doing CBOR encoding there is the tacit assumption that a byte value is just CBOR_MAJOR_BYTE_STRING ^ value :-/

    output.content[0] = CBOR_MAJOR_BYTE_STRING | (plaintext_3.len + AES_CCM_TAG_LEN) as u8; // FIXME if plaintext_3.len + AES_CCM_TAG_LEN > 23, then should use CBOR_BYTE_STRING

I've added a crude CBOR dissection for the message 3 lengths, and adjusted the Python tests so that different variations are run. I didn't quickly find where else we had that kind of CBOR processing -- refactoring would be welcome, but getting this out with the next release might be more urgent than doing this cleanly.

Thanks for the PR. Left a few comments.

I agree that the CBOR encoding could be improved.

Thanks for the review, I think all are addressed in some way or other.

Yep good on my side. Merging as CI passes.