const void cose_sign_get_payload(cose_sign_t *sign, size_t *len)

@bremoran

https://tools.ietf.org/html/rfc8152#section-7.1

Readme.md advices to check https://bergzand.github.io/libcose/ for documentation which seems out of data to me

Dependencies:

    [cn-cbor](https://github.com/cabo/cn-cbor)
    Either [TweetNaCl](https://tweetnacl.cr.yp.to/) or [libsodium](https://github.com/jedisct1/libsodium) as crypto library
    A memory block allocator (can be malloc/calloc based)

vs

Dependencies:

    [NanoCBOR](https://github.com/bergzand/NanoCBOR)
    Either [HACL-C](https://github.com/mitls/hacl-c), [libsodium](https://github.com/jedisct1/libsodium) or [mbed TLS](https://tls.mbed.org/) as crypto library

• Import a whole key instead as a single string
• Exact key sizes without padding

@bremoran Does this cover all issues so far?

The changes of eclipse/tinydtls#34 altered the output of the cryptographic reference AES-CCM operations.

I'll yet have to dig down where things go wrong exactly, but chances are libcose should just use the more modern dtls_decrypt_params API rather than the compatibility dtls_decrypt which tinydtls offers.

Should be included in the automated tests for quality assurance

Please add standard C++ guards to include files so that they are linkable from C++ code.

With the iterative design of tinycbor, some refactoring can be done to make libcose eat a bit less memory. All of this implies a large API change.

Headers as linked list

Enables unlimited number of headers for a cose structure and demands only a minimum amount of memory when decoding.

Signers as linked list

Same as above but for signers of a sign/sign1 structure. Verification of a sign structure could be done by iterating over the signers and calling the verify function with a pointer to that specific signer.

Recipients as linked list

Same as above. Decryption in a similar way as the signer verification. It is more complex when the recipient structure is multilayered.

TODO:

• linked list headers
• Linked list signers
• Linked list recipients

• sign
• encrypt

• nanocbor
• eddsa key fix
• doxygen check

libcose looks like a good tool to get OSCORE running on RIOT, but seems to currently lack AES-CCM -- and AES-CCM-16-64-128 (COSE number 10) is the default algorithm there.

Would there be any obstacles to adding it?

It seems (from code inspection while digging through what safe buffer sizes for signature buffers are and whether *siglen can be predetermined; I'm not at the point of using it yet) that the mbedtls ECDSA implementation uses ASN.1 encoding for signatures where COSE expects its own fixed-length encoding.

Code path:

• cose_crypto_sign_ecdsa at src/crypt/mbedtls.c calls mbedtls_ecdsa_write_signature
• mbedtls_ecdsa_write_signature at library/ecdsa.c calls (via mbedtls_ecdsa_write_signature_restartable) ecdsa_signature_to_asn1 into sig[*siglen]
• ecdsa_signature_to_asn1 does ASN.1 encoding

while https://tools.ietf.org/html/rfc8152#section-8.1 says:

Using the function defined in [RFC8017], the signature is:
Signature = I2OSP(R, n) | I2OSP(S, n)
where n = ceiling(key_length / 8)

As mbedtls is the only ECDSA implementation in libcose, it wouldn't run against common test vectors. Has this been tested against any external COSE implementation yet?

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?

libcose is currently under the LGPL 2.1 license which unfortunately restricts use in systems that utilize static linking, such as microcontrollers. As this library is well suited for the microcontroller use case, I believe adoption would be greatly improved by moving to a less restrictive license.

For my application using the Espressif ESP32 microcontroller, my team and I are prepared to make the necessary additions to the ESP-IDF for inclusion of libcose into the upstream repo as a PR. The only hurdle is that Espressif will only accept code with an Apache 2.0 or compatible license.