terrymacdonald
commented
9 years ago 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
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 https://github.com/TAXIIProject/TAXII-Specifications/issues/82.
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-Protocolbeing 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.