Allow applications to pick their C_x #104
Conversation
chrysn
force-pushed
the
more-application-control
branch
11 times, most recently
from
05b06a5
to
be0ab60
Compare
lib/src/lib.rs
Outdated
| @@ -761,7 +770,8 @@ mod test { | |||
| let mut initiator = | |||
| EdhocInitiator::new(state, I, G_R, ID_CRED_I, CRED_I, ID_CRED_R, CRED_R); | |||
|
|
|||
| let message_1 = initiator.prepare_message_1(); | |||
| let c_i: u8 = generate_connection_identifier_cbor().into(); | |||
There was a problem hiding this comment.
Is .into() needed here (and other similar lines)? The output of generate_connection_identifier_cbor() is already a u8.
There was a problem hiding this comment.
Whether the output of generate_connection_identifier is U8 or u8 used to depend on the back-end; those can go away when rebasing onto remove-hacspec, which is my next step.
|
Thanks @chrysn, it looks good. Left a minor comment. As for merging, maybe we could merge it directly into the remove-hacspec branch I just pushed upstream. |
chrysn
force-pushed
the
more-application-control
branch
5 times, most recently
from
8bb8813
to
a5dc9ae
Compare
The change allows applications to pick usable C_x (i.e., C_I and C_R) values, which they are in a position to decide, because unlike the EDHOC library, they keep track of all the ongoing exchanges. The c_wrapper API is *not* changed at this point, because the API change would be way too subtle (the "out" parameter would be changed to an "in" parameter). BREAKING CHANGE: This alters the message 1 and 2 API.
chrysn
force-pushed
the
more-application-control
branch
from
a5dc9ae
to
9699574
Compare
|
This is now only one commit atop #106. Rebasing was a bit of a hassle, but worked in a mixed cherry-pick and manual application approach. Looks like remove-hacspec is in a stable enough shape to rebase onto, at any rate, and things are much easier on that! From my PoV, this is done once CI says Go. |
|
Great! Merged into |
Applications may need to pick their own C_x (as opposed to the EDHOC library picking one at random, as it was before) for three reasons:
This will likely need follow-ups for similarly delegating the choice of {ID_,}CRED_peer to the callers (resolving #99 issues from), but those are separate enough that I'd do them in a separate PR.
These are API breaking changes. They're split in two because I did C_R first, and kept them split to ease review especially on the CI side; when ACK'ed, I'd like to squash them.