Document Requirements

[MarkDavidson]

All,

Lately I have found myself describing requirements for TAXII 1.0 and TAXII 1.1, and I have realized that these are not really captured anywhere. This issue is an attempt to better document the requirements. Please feel free to request additional information on certain topics.

The requirements are in no particular order, and are numbered for referencing.

01 - Protocol Agnostic, Message Format Agnostic

TAXII was designed to be agnostic in terms of protocol (e.g., HTTP) and message format (e.g., XML). This was because we anticipated that people would want to create and use their own protocol/message bindings. This is why there is a TAXII Services Specification and HTTP/XML Bindings. This also resulted in, for instance, X-TAXII-Protocol being defined.

02 - Digital Signatures

In certain contexts, being able to verify the authenticity of a TAXII Message is important. For this reason, all TAXII Messages contain an XML Digital Signature field. This caused all TAXII Messages to have data, and therefore required HTTP Posts for all TAXII Message exchanges.

03 - Architectural Flexibility (Push/Pull)

Allowing a producer or consumer to be a network Client or network Server allows the design of a TAXII Solution to be more flexible. For this reason, both pushing (producer is a client) and pulling (producer is a server) were designed into TAXII.

[terrymacdonald]

I would like to add (if I may)....

04 - Defined TAXII Discovery Location

Having IANA defined TCP ports for the HTTP based and HTTPS based TAXII
traffic, and a defined path on the URL (e.g. /discovery) would allow a
TAXII client to know exactly how to initially connect to a TAXII Server. If
we then combined this with the creation of a new '_taxii' DNS TXT record
then this would allow for the auto-discovery of the TAXII server for a
domain. We could just do the _

TAXII Client would then be able to either:

• Look up DNServer for a domain
• Check for a _taxii DNS TXT record
• Go directly to the discovery URL and continue with the discovery process

OR

• Go directly to the domain on a well-known TAXII TCP port to /discovery

Cheers

*Terry MacDonald *| STIX, TAXII, CybOX Consultant

M: +61-407-203-026
E: terry.macdonald@threatloop.com
W: www.threatloop.com

https://www.threatloop.com

Disclaimer: The opinions expressed within this email do not represent the
sentiment of any other party except my own. My views do not necessarily
reflect those of my employers.

On 27 May 2015 at 23:44, MarkDavidson notifications@github.com wrote:

All,

Lately I have found myself describing requirements for TAXII 1.0 and TAXII
1.1, and I have realized that these are not really captured anywhere. This
issue is an attempt to better document the requirements. Please feel free
to request additional information on certain topics.

The requirements are in no particular order, and are numbered for
referencing.
01 - Protocol Agnostic, Message Format Agnostic

TAXII was designed to be agnostic in terms of protocol (e.g., HTTP) and
message format (e.g., XML). This was because we anticipated that people
would want to create and use their own protocol/message bindings. This is
why there is a TAXII Services Specification and HTTP/XML Bindings.
02 - Digital Signatures

In certain contexts, being able to verify the authenticity of a TAXII
Message is important. For this reason, all TAXII Messages contain an XML
Digital Signature field.
03 - Architectural Flexibility (Push/Pull)

Allowing a producer or consumer to be a network Client or network Server
allows the design of a TAXII Solution to be more flexible. For this reason,
both pushing (producer is a client) and pulling (producer is a server) were
designed into TAXII.

—
Reply to this email directly or view it on GitHub
#82.