Hello discussion list members,
I'd like to inspire some discussion as to the way Content Blocks are currently laid out and processed. I've had some private correspondence with Mark Davidson pertaining to practical issues that can arise from the current specification on Content Blocks, and I'm going to reiterate the problem description and reasons for revisiting the current spec here.
First of all, these are the rules and knowns that we set out from:
- A Content Block requires a Content Binding ID and, optionally, a Content Binding Subtype .
- TAXII aims to be content agnostic:
"The TAXII specifications do not provide details about the underlying content formats of records within
TAXII. All content formats are a "black-box" as far as TAXII is concerned - none of the behaviors required
to process TAXII at the message level require inspection of any information stored within message
- The current list of canonical Content Binding IDs is not definitive; "Third parties may define their own Content Binding IDs for any form of content." .
- One of the canonical Content Binding IDs listed is "S/MIME", which is, given its uniform way of encoding data (eg. base64), truly content agnostic and context independent .
- The other three primary Content Binding IDs are STIX, CAP, XML Encryption, all of which are expressed using XML .
Typically, when a TAXII processor is to parse a TAXII message, which is always a valid XML document, it consumes and parses the entire TAXII message. Recently, the discovery of a local file inclusion vulnerability in libtaxii and related libraries necessitated that additional strictures were imposed on the instantiation of the XML parser leveraged by libtaxii. Among other things, the XML parser used by libtaxii currently does not allow XML entity references to be resolved anymore, because they are not required to parse TAXII documents and because leaving it enabled allows for exploitation of various vulnerabilities (like local file inclusion, the "billion laughs" attack, and so forth). All the current strictures imposed on the XML parser by libtaxii can be viewed here: https://github.com/TAXIIProject/libtaxii/blob/master/libtaxii/common.py#L42 .
The current specs on Content Blocks allow XML data to be embedded inside a TAXII document, which is also an XML document, and as such, is typically ingested and parsed in its entirety at once. Since the strict configuration of the XML parser limits its operation to what is necessary to parse a TAXII document, and prohibits such actions as resolving XML entity references and retrieving schema's from external sources, misalignments between which subset of XML functionality TAXII requires for successful parsing, and what an embedded XML document (inside a ContentBlock) requires, are bound to happen. This may or may not be the case yet for its currently supported Content Binding IDs (STIX, CAP, XML Encryption). However, the prospect of additional XML-based content types to be used (either defined by third parties or through future inclusion in the specs) warrants some anticipation of the consequences of the current leniency of the content in Content Blocks, and deliberation over whether to change the current specs.
My own proposal is to only allow S/MIME as the effective type of content to be stored within a Content Block. In the light of what has been described above, I think this will considerably reduce the overall complexity of dealing with Content Block content, as the parsing and ingestion module does not have to differentiate between a purportedly well-formed XML block (current) and a "string" type (S/MIME, preferred) that, once processed, can be of any type or form and on which the validity of the context (its encapsulating shell -- the TAXII document) does not depend.
 TAXII_Services_Specification.pdf, chapter 4.5 "TAXII Content Block"
 TAXII_Services_Specification.pdf, chapter 5.2.1 "TAXII is Content Agnostic"
 TAXII_ContentBinding_Reference_v3.pdf, chapter 3 "Third Party Defined Content Bindings"
 TAXII_ContentBinding_Reference_v3.pdf, chapter 2.1 "Table of Binding IDs"
Thank you for the message. One possible complexity I see with the suggestion is that key management would be necessary.
Perhaps in conjunction with some discussion on DANE there might be some solution whereby certs are retrieved from the recipient’s DNS entry and used for signing/encryption. This suggestion has its own complexities, but I think it could enable S/MIME to be used in many places.
From: Guido Vranken [mailto:[hidden email]]
Hello discussion list members,
|Free forum by Nabble||Edit this page|