search

eriptic / uoscore-uedhoc

C implementations for constrained (and non-constrained) devices of the IETF protocols OSCORE and EDHOC
Other
15 stars 15 forks source link

All the remaining changes #15

Closed tgujda closed 2 years ago

tgujda commented 2 years ago

Remaining changes previously introduced internally by Assa Abloy team.

StefanHri commented 2 years ago

Hi

thanks for providing these updates!

I noticed that the edhoc_responder_run() function is extended now to take two more parameters uint8_t *c_i_bytes, uint32_t *c_i_bytes_len. What is the reason for that?

In addition, I am using in this project the Linux coding style, which is due to compatibility with Zephyr. Therefore typedef structs as here should not be used and be replaced with struct struct_name see here.

StefanHri commented 2 years ago

In addition, why you add additional uint8_t *client_pub_key, uint32_t *client_pub_key_size, parameters in edhoc_responder_run()? I guess that you want to provide the public key of the initiator (Note: the client can be the initiator and responder) to the application. My suggestion here will be to keep API ofedhoc_responder_run() as it is, since it is more simple and probably better suitable for most of the cases and provide an additional function, e.g., edhoc_responder_run_extended() which basically extracts the initiator public key and can be used in your use case. Then the edhoc_responder_run() can be implemented as just a wrapper around edhoc_responder_run_extended(). Something like that:

edhoc_responder_run(...){
  uint8_t *client_pub_key =  NULL; 
  uint32_t client_pub_key_size = 0;
  edhoc_responder_run_extended(..., client_pub_key, &client_pub_key_size, ...);
}