We have good consensus in the community that IEP should be included as part of STIX 2.1. The technical mechanism that we do that (a data marking definition) is very straightforward and is described in the playground. There are several open questions though, that can be resolved as a combination of text in the specification itself, in the conformance section of the specification, or in the interoperability specification.
- Do we lock IEP specifically to a single version? Locking it to one version makes compatibility easier to state, but precludes the ability for newer versions of IEP to be used in STIX without a modification to STIX. Allowing it to remain open makes compatibility more difficult (STIX 2.1 and IEP 2.0 incompatible with STIX 2.1 and IEP 2.2) but allows IEP to evolve and be used ahead of STIX.
- How do we talk about the overlap of IEP and TLP? We could take a range of options with text in our specification documents (STIX, and interop) that would go from either remaining entirely neutral (not recommending one or the other) to strongly preferring IEP to even having normative text describing them.
This document describes several different options for each decision point.
In this option, the normative text in the STIX specification references a specific version (or versions) of IEP as a normative reference. This is a similar approach that we've taken to most other specifications in STIX, including TLP. Any discussion of IEP in STIX then means that specific version or versions.
Option 2: Leave version open in the specification, lock it down in the interoperability specification
In this option, the normative text in STIX references the earliest supported version of IEP as a normative reference but has text that says future versions of the specification are also acceptable. This hasn't been done in STIX before but seems doable.
The interoperability specifications would then say that for specific use cases you need to support a specific version of IEP.
This option is similar to Option 2 but without the text in the interoperability specification.
In this option, normative text in the STIX conformance section lists IEP as a required feature. Tools would be required to implement support for IEP in order to claim compliance with STIX. There is a challenge with this approach, in that we have to define what it means to "support" IEP. Be able to parse it and not throw an error? That's a low bar. Be able to correctly implement all of the potential restrictions across IEP? That's near-impossible to test. We probably have an out in that we could say that you MUST conform to what the IEP specification itself says, but again it seems like most tools will not be able to functionally support all of those capabilities.
In this option, we could say that documents containing IEP and TLP MUST give precendence to the IEP content. That text would probably go in the IEP data marking section. Putting both IEP and TLP in a document would be pointless in a STIX 2.1 ecosystem, but would make sense if you're also trying to support STIX 2.0 tools with your 2.1 content (which should be fairly doable).
In this option, normative text in the STIX conformance section lists IEP as an optional feature. This has many of the same issues as above, in that to claim support for the optional feature we need to define what it means to support IEP.
If IEP is optional, we could say that tools supporting both IEP and TLP MUST give precedence to the IEP content. If they don't support IEP, they can use the TLP. We would probably need to state that content SHOULD be marked with both TLP and IEP given it would lead to more uneven support of IEP and we'd already weighed in on one vs. the other.
In this option, there's no normative text discussing the interaction of different types of data markings in the core specification. This aligns with how STIX 2.0 works now, we don't talk about potential overlap between different marking types.
In this option, text could be added to the interoperability specification that could recommend IEP and describe how IEP and TLP in the same document should be handled. It could possibly also even require IEP for certain use cases/personas, though that - as with 1 and 2, gets in to the same issues with defining what it means to "support" IEP (i.e. what TLP:AMBER in IEP means for trust group A might be different than trust group B, so you can't really write test cases for it).
STIX could also remain completely silent on the topic and let trust communities work it out.