OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

openc2 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: DKS33 - Backwards - HTTPS CSPRD Comment

Page 11, lines 32ish to Page 12, line 56ish sections 2.3 & 2.4; page 15 line 25ish to page 16 line 22ish Sections 3.5&3.5

I have several issues with the âbackwardsâ scenarios where the OpenC2 Consumer (eg the IoT device) controls the communications instead of the OpenC2 Producer (eg the security orchestrator) and would propose to delete these in this initial version of OpenC2.

OpenC2 is new and I think we are making unnecessarily-complicated scenarios for version 1.0. This âbackwardsâ scenario greatly complicates understanding this specification.

My worry is the scenarios in the standard are ones members think âsomeone else must needâ without fully understanding the impact if such a scenario did exist. If TC members actually need this scenario, would they please submit use cases where they would actually have their security orchestrator unable to initiate communication with the devices they are orchestrating. Note a device should only be controlled by a mutually-authenticated producer. Recall it is the security orchestrator that is in charge of security controls. The proposed âpollingâ scenarios seem to be a case where the security orchestrator is not able to affect security controls.  The only uses I can see are nefarious - where an adversary needs to control a compromised device and I would prefer to not enable those scenarios (and I recognize adversaries wonât care whether they meet standards or not - itâs an issue of principle to not standardize backdoors). 



Duncan Sparrell

sFractal Consulting LLC

iPhone, iTypo, iApologize

I welcome VSRE emails. Learn more at http://vsre.info/


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]