Thank you for your response Jouni. Please see below: On 27.11.22 08:16, Jouni Malinen wrote:
On Tue, Aug 02, 2022 at 03:16:08PM +0200, Eliot Lear wrote:This patch might require some discussion and some edits. It is possible that two or more devices might get configured at the same time. In this case, the upper layers may wish > to the status of respective devices. I have tested the dpp_tcp.c code. I have NOT unit tested the dpp_supplicant code (I don't have a test setup for that).This way of identifying a peer is problematic since there is no separate bootstrapping information entry for a peer when acting as a DPP Responder (well, ignoring the mutual authentication case here) since no QR Code (etc.) was actually read on the Responder device. As such, the upper layers would not really have any context for determining what the particular peer bootstrapping information identifier might be in such cases.
Forgive my confusion, but the code above what you quoted indicates that clearly we are providing a conf result, which means that we are the configurator and we have already authenticated the peer with the public key from the enrollee's qrcode. Am I misusing / misinterpreting the struct?
Eliot
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
