Subject: Re: [Cacao] GAP Analysis with RID/ROLIE

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 1 Oct 2018 09:23:52 -0400

Brett,

Sent from my mobile device

> On Oct 1, 2018, at 2:47 AM, Allan Thomson <[email-masked]> wrote:
> 
> Bret – thanks for sending this summary out.
>  
> To re-enforce your point about CACAO. Its not focused on the transport at all. Our intention is that the transport of CACAO content could be conveyed by multiple protocols that satisfy the requirements of security defined in the draft.
>  
> As you state the focus for CACAO is enabling the definition of a set of actions/responses for cybersecurity response where one or more systems may work in a coordinated manner. The CACAO project and its content are the primary focus of the work (right now). Eventually we will want to discuss transport methods but that is a future step not the initial one (imo).

Thank you for your work on a gap analysis.  This was helpful to me at least as you’ve more clearly stated your goals.  It was not as clear in previous messages that you planned to limit your scope.

RID also has policy aspects and the COA price was moved to IODEF, do you have comments on the gap with those aspects of your planned work?  I ask as that was one of the other similarities I noticed from your descriptions.

Thank you,
Kathleen 
>  
> Regards
>  
> Allan Thomson
> From: Cacao <[email-masked]> on behalf of Bret Jordan <[email-masked]>
> Date: Monday, October 1, 2018 at 12:03 AM
> To: "[email-masked]" <[email-masked]>
> Subject: [Cacao] GAP Analysis with RID/ROLIE
>  
> All,
>  
> This weekend I re-read the RID and ROLIE RFCs, even though recently I had became quite familiar with both of them. Yes, the authors of these documents have done an amazing amount of work.  However, they represent a different set of use cases and problems from what we are trying to do here. 
>  
> From a comparison / gap stand point with this work, it is important to note that RID and ROLIE are about how to share the data once it has been created. Similar to the way TAXII is about sharing STIX data once it has been created. CACAO on the other hand is primarily about creating the data in the first place. 
>  
> From a sharing standpoint with CACAO, we may look to AMQP, RabbitMQ, MQTT, ZeroMQ, MATRIX, TAXII, native HTTP REST etc. However, that work is a long ways off and represents probably only 3-5% of the problem space we need to address. 
>  
> RID and ROLIE:
> RID is a SOAP type interaction that uses XML and is tied at some level to IODEF. Just like TAXII can transmit content other than STIX, I am sure RID could be configured to interact with content other than IODEF.  However, nearly all of the examples and namespace requirements call out IODEF or require IODEF to be imported in to the schema. (Please do not flame me, but that is how the document reads).   
>  
> ROLIE is an XML based RESTful interface that uses XMPP synchronization of content by sharing a manifest like resource so the client can go back and get the actual content it wants. ROLIE does not push or share the actual content, but rather, enables the clients to know what content is available and tells it where to go and find it.
>  
> Summary
> As I said above, both of these work products represent a lot of good work by the authors. But CACAO is about the ontology or language for how one might describe courses of action and allow them to be shared in a way that allows them to be collaboratively worked on. It is not about how to transmit data.
>  
> When it comes time to work on the protocol side of this work, I am guessing that we will be able to either just pick a preferred set of solutions and define what it will mean to use them or borrow a lot of ideas from other work to create something that easily works for this use case.  
>  
> My goal is to get something working as quickly as possible, get vendor adoption, and then iterate and add functionality over time. If our initial spec is too big and complicated, it will never get implemented. I often say that if the first version of HTML would have looked like the current HTML5, it probably would have never gained broad market adoption.
>  
>  
> Thanks,
> Bret
> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
> 
> 
> -- 
> Cacao mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cacao

---

From: Bret Jordan <[email-masked]>
Date: Mon, 1 Oct 2018 09:53:55 -0400

Kathleen,

Thanks for you comments.  I will try harder to be more clear up front going forward. Hopefully this will help us better understand each other and enable collaboration. 

Thanks,
Bret

> On Oct 1, 2018, at 9:23 AM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Brett,
> 
> On Oct 1, 2018, at 2:47 AM, Allan Thomson <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> From: Cacao <[email-masked] <mailto:[email-masked]>> on behalf of Bret Jordan <[email-masked] <mailto:[email-masked]>>
>> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/cacao <https://www.ietf.org/mailman/listinfo/cacao>

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 1 Oct 2018 10:46:31 -0400

Thanks, Bret,

I’m just trying to understand the scope of work and how it differs from previous work as a logical step to engage.  Once I understand how it differs from the policy aspects of RID and the previous CoA work that I think is in IODEF, that will help me and most likely others who assisted in that work.

Best regards,
Kathleen 

> On Oct 1, 2018, at 9:53 AM, Bret Jordan <[email-masked]> wrote:
> 
> Kathleen,
>