Let's clarify HTTP to HTTPS does not affect the CA layer architecture. [done] HTTP to HTTPS may affect the proxy module but not likely. [done] In OCF communication channel, it aligns to the secure communication policy. [done] Out of band from the OCF communication, this is argue point. [?]
This is service layer module policy whether we will allows incremental one or not for secure channel, and whether we will allows non-secure connection or not. BR, Uze Choi -----Original Message----- From: Thiago Macieira [mailto:[email protected]] Sent: Friday, July 29, 2016 4:34 PM To: ashok.channa at samsung.com Cc: ???; iotivity-dev at lists.iotivity.org Subject: Re: Fwd: Re: Re: [dev] CoAP - HTTP Proxy Review Request On sexta-feira, 29 de julho de 2016 06:57:50 PDT ?? wrote: > Our concern should be between OCF devices but not between OCF to any > other protocols/devices. We can make other protocols interoperable > with bridges but cannot force them to be secure. I disagree. A chain is only as strong as its weakest link. Therefore, we should promote the secure functionality as much as possible. You're right that we can't force them to be secure, but we have to give the option of using that. As evidence of that, when we were discussing the AllJoyn bridge, the person representing OCF security made quite an argument about bridging AllJoyn devices that did not implement any security (those should not be bridged by default). If we extend this to the proxy, we conclude that OCF's desire is that HTTPS be implemented first and foremost and that support for HTTP should be enabled only after the user's action. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
