Hi Brian, On 05/02, Gix, Brian wrote: > > Right, but I think this is covered by the server/client model behaviour, so I don't > > think we need to care if the message was encrypted using a known remote > > device key, or our local device key. > > There is the SHALL paragraph in the specification, under section > 3.7.4.3: > > "A response message shall always use the same DevKey or AppKey used by > the corresponding request message." Indeed, but on the other hand 4.4.1.1 says that: "The application-layer security on the Configuration Server model shall use the device key established during provisioning." So it doesn't make any sense for a server model to accept messages encrypted with remote device key. I think the only situation where a message using remote device key should be accepted is processing responses directed to a local client. In the end, I agree we need to track the 'kind' of a device key... But, I think we actually need to expose the local/remote distinction to the application, as an (boolean?) argument of DevKeyMessageReceived. This is because foundation models aren't the only models that are allowed to use device-level security. Also, you mentioned earlier that the daemon will not expose APIs for all configuration client operations. > > I think this means that the API needs to allow using either local or remote > > device key when *sending* a message (i.e. use remote key for requests and > > local key for responses), but API for receiving messages needs only to > > differentiate between device and application keys. And what about this then? Because of the above, I don't think it's correct to always (automatically) use remote device key if one is known. If the previous comment about an additional argument makes sense, it would also make sense to add it to DevKeySend. > > I was more concerned about the CRPL size. At the moment the limit means that > > a node cannot simultaneously talk to more than 10 remote nodes because of > > this (mesh/appkey.c:227): > > This will definitely be fixed, and should be following the value > indicated by the Composition data of each node. Note that the Composition Data Page 0 indicates a *minimum* CRPL size. A node is free to use a longer list. So if I read this right, the plan is to allow the application to declare CRPL size during CreateNetwork/Join procedure? > > What are your thoughts on replacing the JSON storage with something more > > granular? > > > We would like to keep Node Storage, at least for the full Linux > implementation, in JSON format Got it. Thanks for the additional details. regards -- Michał Lowas-Rzechonek <michal.lowas-rzechonek@xxxxxxxxxxx> Silvair http://silvair.com Jasnogórska 44, 31-358 Krakow, POLAND
