feat: add eckey_t

[gocarlos]

what

• now cose_configure.h is create on the fly at configure time similiar to autoconf
• macros to decide on which cryto lib are now also namespaced e.g. COSE_C_...
• add methods needed for ot-commissioner ->
  • ref sign and validate with public keys (OpenSSL, mbedtls) #68
  • ref update to upstream cose-c  openthread/ot-commissioner#70

why

• by creating the configure.h at configuration time, we have the right defines in the header file instead of relying on the compiler flags from library consumers...
• namespace is important to not collide with other macros,

[coveralls]

Coverage decreased (-1.07%) to 83.52% when pulling daba796 on gocarlos:feat--add-eckey_t into 9223f01 on cose-wg:master.

[gocarlos]

@wgtdkp @jimsch please review this

[jimsch]

Long term this is not my preferred method of addressing this issue. Moving to a COSE Key structure and replacing the current CBOR key passed in allows for similar ways of dealing with the passed in keys and also allows for keeping the internal keys created around for a period of time if they are used multiple times, for example doing a signature verification against the same key multiple times.

I can understand doing this short term but it might mean another change later down the line

[jimsch]

I am not sure where this came from. I would expect it to be an EVP_KEY*

[wgtdkp]

@jimsch

Moving to a COSE Key structure and replacing the current CBOR key passed in

Replacing the CBOR key will break compatibility, is that acceptable? If true, I agree we should replace CBOR key with a COSE key.

[jimsch]

It would be possible to provide a thin wrapper that converts a CBOR key to a COSE key for a while and mark those functions as depreciated. Although I think every compiler does that differently.

[wgtdkp]

@jimsch

It would be possible to provide a thin wrapper that converts a CBOR key to a COSE key for a while and mark those functions as depreciated. Although I think every compiler does that differently.

Thanks! It makes sense to me.

[gocarlos]

Can we make this in a next mr? I wanted to make sure that ot-commissioner works with upstream cose-c. And it seems to work ok now... i’m for merging, adding a test and change the interfaces...

@jimsch what do you think?

[gocarlos]

Although I think every compiler does that differently.

Yeah, if the code would be c++, then this would be part of the language ;)

[jimsch]

A new PR WFM - I chose C rather than C++ because of the environment that I was shooting for. In retrospect I think I could have gone with C++ but that is life.

[gocarlos]

A new PR WFM - I chose C rather than C++ because of the environment that I was shooting for. In retrospect I think I could have gone with C++ but that is life.

I meant, that i think is better to merge this now (no side effects for existing users) then to improve it...

[jimsch]

As noted in the other pull request, this is not the way that I think this should go in the end. It would be better to declare a COSE_Key structure and have a method to build that. This can this be changed internal to the library without issues as well as adding some other types of keys. If you are doing this, please just make this specific to MBEDTLS as passing in the structure is not how one would do this for OpenSSL, instead you would pass in an EVP_KEY *.

I don't know what the current support is in MBEDTLS for TEMs at the moment. I would expect that at some point in the future this is going to be added if not currently present and that would require yet a different possible internal change for that support.

[jimsch]

I am tossing together a framework for this right now.

[wgtdkp]

I am tossing together a framework for this right now.

thanks @jimsch !