On Jan 5, 2018 5:01 PM, "Heldt-Sheller, Nathan" < [email protected]> wrote:
...snip.. I’mm working on a change for the next OCF Specification (and implementation in IoTivity) that will hopefully improve the intuitive nature of “OC_SECURE” A simple renaming would go a long way. OC_SECURE => OC_EP_ENCRYPT OC_NONSECURE => OC_EP_NOENCRYPT Or maybe OC_COAP, OC_COAPS? and /acl2 configuration for many Devices, without breaking the security model. I can’t share more than that on the IoTivity reflector at this point but if you’re curious you can join the OCF Security Working Group and take a look at the proposal. Thanks, Nathan *From:* [email protected] [mailto: [email protected]] *On Behalf Of *Gregg Reynolds *Sent:* Friday, January 5, 2018 1:31 PM *To:* iotivity-dev <[email protected]> *Subject:* [dev] Systematic ambiguity of "secured" Security is a house of many mansions. Data integrity, confidentiality, non-repudiatability, authorization, authentication, etc. The Iotivity docs systematically conflate these attributes, resulting in confusion for devs who are not sec experts. Transport-layer security and access control security are totally orthogonal. The former is about integrity and confidentiality; the latter is about, well, something else. But every bit of Iotivity doc I have seen fails to make that critical distinction. If we want to increase uptake of OCF, this is a problem. For example, it is just wrong to say that OC_SECURE means a resource is secure. It only means that access to the resource must go thru d/tls. That's about the endpoint connection, not the resource. Access control is a completely separate issue afaik. The we have compiling with SECURED or not. Alas, I have not yet come up with better language. But if we want to attract devs we need clearer language. G
_______________________________________________ iotivity-dev mailing list [email protected] https://lists.iotivity.org/mailman/listinfo/iotivity-dev
