Re: [PATCH 11/21] doc: PKEX support for DPP

[James Prestwood <prestwoj@gmail.com>]

Hi Denis,

On 10/24/23 8:03 AM, Denis Kenzior wrote:
> Hi James,
> 
>>>
>>> Fair enough, lets explore whether we can provide this via some agent 
>>> API.
>>
>> Reading more about the identifier being used to distinguish a 
>> "plurality of devices" this is what I'm thinking as far as the agent 
>> interaction:
>>
>> It would make sense (on the configurator side) to query an agent 
>> _after_ the enrollee sends the PKEX exchange request. That way the 
>> configurator can look up the identifier/code, somewhat the same as 
>> RequestUserPassword.
> 
> Possible.  But isn't the main use case to share the code and initiate on 
> both sides independently?

That's kinda what I originally thought but the quote

"where a PKEX implementation may be provisioned to connect to a 
plurality of devices and needs to know which code to use to process a 
received PKEX frame"

Makes it seem like the implementation can lookup a code based on an 
identifier after receiving a frame. Like you mentioned, only a machine 
could do this while adhering to the spec so, eh? who knows what they 
intend here...

I'd prefer to support this because it allows a unique exchange 
per-device (assuming each device sends a unique ID). Obviously, also 
support the human case, maybe two configure APIs?

ConfigureEnrollee(code, identifier)
(Though we have to make the identifier optional, either via a{sv} or an 
empty string)

StartConfigurator(object agent_path)

> 
> So..
> ConfiguratorEnrollee(code, identifier)
> StartEnrollee(code, identifier)
> 
>>
>> I don't see much benefit of using an agent in StartEnrollee(), and 
>> would rather pass via the DBus arguments for simplicity. Adding an 
>> agent for this doesn't really gain us anything, it just adds 
>> complexity. The caller of the API can still change the code/id for 
>> each call it makes to StartEnrollee() as it sees fit.
> 
> Okay, sounds fair.
> 
>>
>> So something like:
>>
>> StartConfigurator()
>>      ... waits for PKEX exchange request ...
>>      -> RX PKEX exchange request
>>          if (id)
>>              Agent.RequestUserPassword(id)
>>          else
>>              Agent.RequestPassphrase()
>>
>> (And if we want "SharedCode" Agent APIs, that's fine, these just fit 
>> the need)
>>
>> The one caveat here is the timing since the PKEX exchange response 
>> must come within 200ms, which isn't possible for a human user. A human 
>> configurator would need to establish the code/id completely ahead of 
>> time.
> Well, that's why it says to retransmit 5 times.  But even then, that 
> isn't enough time for a human to process this.  Hence my point above, 
> that the use-case seems geared towards both sides entering the shared 
> code without any 'trigger' from the peer.
> 
> What you propose here is using the Agent, but only for as a way to 
> machine generated a response.  Sounds like maybe:
> 
> StartConfigurator(object shared_code_agent_path)?
> 
> Regards,
> -Denis
>