Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remote_cred_cb: More input, more output #24

Open
chrysn opened this issue May 19, 2021 · 0 comments
Open

remote_cred_cb: More input, more output #24

chrysn opened this issue May 19, 2021 · 0 comments

Comments

@chrysn
Copy link
Collaborator

chrysn commented May 19, 2021

The way aiocoap currently uses remote_cred_cb has become a monster:

resp = self.responders.create_responder(
        lambda id_cred_peer: self._get_peer_cred(
            # These we have to provide through a curried function
            # -- without those, it'd be hard to find the right key
            # if the same key identifiers are used for
            # obviously-different keys.
            peer_is_static,
            m1.cipher_suites,
            # Only this py-edhoc thinks is relevant.
            id_cred_peer,
            # This is kind of a second return value -- not only do
            # we need to pass the found key material out to EDHOC,
            # but also tell aiocoap which permissions are
            # associated with this.
            credential_identifier_cb,
            ),
        ...
        )
credential_identifier_cb = lambda identifier: setattr(resp, "application_identifer", identifier)

This is because at the time where I process the peer's cred_id, I not only need more information I'm currying in here (because someone could use the same compact key ID with different keys in different cipher suites / methods), but I also need to get the information about the selected key out again (in particular, when an OSCORE context is created, that information will be used to decide what the authenticated client is authorized to do).

One more piece of information that may need to go out of there is the list of supported cipher suites (but I'm not sure there yet).

I don't have a concrete proposal yet, but maybe we can gather some already here.

Kneejerk reactions without proper vettig are:

  • Pass suite and staticness in to the remote_cred_cb.
  • Alternative, pass the responder itself to the remote_cred_cb, so the key finding function can ask whatever it needs.
  • Allow returning a third item (after the cred and the public key) that'll be stored in an attribute of the responder (like the dubious setattr lambda does here).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant