Re: [cti-users] Questions about TAXII 2.1 Envelopes vs. STIX Bundles

Thanks for submitting your question. Let me try and answer it. In the TAXII 2.0 release we discovered a few issues when accepting STIX content directly into a TAXII resource. Further, one we fixed pagination we found we needed extra properties on the âcontainerâ. By adding these extra properties we found that TAXII was putting requirements on STIX in a very weird way which would cause all kinds of problems when we try to keep version in sync. This caused problems with content negotiations as well. Further, many in the community asked that we separate the two and make sure the each spec did not put constraints on the other. After doing this, a lot of things got easier.

So yes, the TAXII envelope was designed to mimic the STIX bundle. This was done by design to make it super easy for code to be adapted. But as you will see, the TAXII envelope has extra properties that are required for pagination. This also means that the media types coming in to TAXII are now always TAXII. This prevents a lot of weird code paths that were problematic for early adopters of 2.0. It should now be much easier to code up support for TAXII 2.1.

In STIX and TAXII 2.1 the STIX bundle might be used for sending STIX content outside of TAXII. But when using TAXII, the TAXII envelope must be used. This also means that even when getting a single object or sending a single object, the TAXII envelop is used. This will give predictability and interoperability on the client and server and greatly reduces the amount of code needed to process inbound and outbound data.

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."

On May 12, 2020, at 6:05 AM, Adam Pearce <adam.pearce@xorsecurity.com> wrote:

All,

It appears that TAXII 2.1 Envelopes were introduced in such a way that allows their fields to be backwards compatible with STIX Bundles, so that there is compatibility between TAXII 2.0 and TAXII 2.1 clients.

However, there is some ambiguity surrounding the explicitness of the TAXII 2.1 specification. It mentions that

When requesting STIX 2 content, that content will always be delivered in a TAXII envelope even if there only one object returned.

And

When adding STIX 2 content, clients MUST deliver all objects in a TAXII envelope.

If STIX Bundles are TAXII envelopes, then there is no ambiguity.

However, there is a slight semantic argument to be made around "is" or "is not". My interpretation would be that Bundles are Envelopes, but Envelopes are not Bundles. Envelopes do not include the required 'type' and 'id' fields to be interpreted as Bundles. However, an Envelope has only 3 (optional) properties, one of which is 'objects'. So a Bundle could be interpreted as an Envelope. This is further supported by the 'Must Ignore' property of I-JSON for "unrecognized fields" (https://tools.ietf.org/html/rfc7493, Sec. 4.2).

Is this interpretation correct? Furthermore, is allowing a Bundle for the 'Add Objects' API in TAXII 2.1 acceptable?

Best regards,
Adam Pearce

cti-users message