OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-taxii message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti-taxii] TAXII Protocol Selection


We are not deciding yet on an encoding, just the transport method.  Further, all of the transport methods listed below can support any encoding. 

At the transport level, we need to have something that is TAXII.  If people want to go create a different solution that say runs over SNMP, then that is not TAXII, but something else. 

In regards to encoding, since you brought it up.  TAXII does NOT need to have the same encoding as the CTI that it transports and there is no added value for it being the same.  In fact, I believe that TAXII should be able to transmit Facebook ThreatExchange data just as well as STIX, CybOX, IODEF, or OpenIOC, or what ever new CTI language gets created next month.  TAXII needs to be just the best and easiest solution for transporting CTI, regardless of the CTI.

Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
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 Sep 1, 2015, at 16:20, Terry MacDonald <terry.macdonald@GMAIL.COM> wrote:

Hi Bret,

I'm still not convinced that we can make a final selection without first having decided upon a STIX protocol format. There is a potential that the TAXII selection will conflict with the STIX selection, meaning that TAXII wouldn't be able to transport STIX data which would of course be a very bad thing.

Could we just settle with a reduced list instead, at least until the STIX format is closer to a decision?

I like the idea proposed in the STIX mailing list of selecting a mandatory protocol and then leaving room for the creation of additional protocols for specialist scenarios in the future. Binary protocols such as cap'nproto, avro, protobuf or thrift maybe required in the future with larger numbers of data transmitted, so leaving the door open for their future use is appealing to me.

Cheers
Terry MacDonald

On 2 Sep 2015 5:10 am, "Jordan, Bret" <bret.jordan@bluecoat.com> wrote:
We are still soliciting comments on the pros and cons for the the following proposed protocols.  What we are trying to do is:

* Attempting to get consensus on a protocol to move forward with

* Provided compelling evidence that what we choose turns out to be wrong and that it will not meet our needs, we will revisit this decision and try and find a better solution. Obviously, we want to figure this out as quickly as possible.  So once we decide, please help us with use-cases and concepts so we can make sure it does in fact work.

* If we do not have a consensus, we will attempt to pare down the shortlist until we do have consensus

* Now is the time to get your comments in the mix.  

Just to recap, as of right now the public responses are leaning towards HTTP/1.1.  If you disagree with this then we would love to hear your opposing opinions.  We plan to discuss this on the community call next week, details and agenda to be forth coming.

HTTP/1.1
HTTP/2
ZMTP
AMQP 0.9
AMQP 1.0
MQTT
SMTP

Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
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." 



Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]