Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 18 Jul 2019 20:54:09 +0200
From:   Michal Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
To:     "Gix, Brian" <brian.gix@intel.com>
Cc:     "Stotland, Inga" <inga.stotland@intel.com>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH BlueZ] mesh: Init keyring storage directory on node
 Attach()
Message-ID: <20190718185409.3pqtjqwnahlus2k5@kynes>
Mail-Followup-To: "Gix, Brian" <brian.gix@intel.com>,
        "Stotland, Inga" <inga.stotland@intel.com>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
References: <20190718040126.5152-1-inga.stotland@intel.com>
 <20190718085923.4ljvk3t3avqdh24d@mlowasrzechonek2133>
 <DEBB0CAA2616974FAE35E4B560B9A4376CBD3EA6@ORSMSX103.amr.corp.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <DEBB0CAA2616974FAE35E4B560B9A4376CBD3EA6@ORSMSX103.amr.corp.intel.com>
User-Agent: NeoMutt/20180716
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Brian,

On 07/18, Gix, Brian wrote:
> There are no use case allowed in the specification that allows any
> Config Client except an authorized Provisioner to communicate with a
> Config Server (even the local Config Server)...   Any changes to a
> nodes configuration states should be tracked by provisioners in a
> master database, and this is not really possible if any node is
> allowed to change it's own CFG Server states.

OTOH, there is nothing in the spec that forbids it.

For example, it's perfectly legal to create a vendor model that extends
Config Server and adds a few additional opcodes that affect Config
Server states.

Another example is multiple Configuration Clients - the spec only says
that synchronizing Provisioners is implementation specific, and it's not
Provisioners who talk to Config Servers - it's a Configuration Client, a
different role. And sychronizing Configuration Clients is not even
mentioned.

Also, for Device Keys, the spec says they are "known by nodes".
Splitting the node into a "daemon" and an "application" is a
bluez-specific architectural decision that has nothing to do with the
standard. While I appreciate there are reasons to implement the stack in
this manner, I am very much against adding arbitrary restrictions on the
things one can do with such a stack.

One of these restrictions is denying access to keys. This is fine, but
the application needs to be able to use these keys *as if it knew them*.

For example, it should be possible to implement an application-side
server model that uses DevKey security. At the moment this is not
doable, because there is no API to send a message encrypted with *local*
device key.

regards
-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND