cti-taxii message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [cti-taxii] Tuesday's Working Call
- From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
- To: Bret Jordan <Bret_Jordan@symantec.com>
- Date: Mon, 30 Jan 2017 10:42:17 -0400
My main questions on the doc as it stands
right now... added the same comments directly to the doc.
Here is a copy/paste from the doc -
red emphasis mine (apologies to anyone on a plain-text email client)
6.4.1 Certificate
Authentication
A TAXII 2.0 Server MAY support certificate
authentication. Software claiming
to support certificate authentication
MUST follow the normative
requirements listed in this section.
What is the normative definition of
"claiming to support" ?
Am I allowed to build software that
supports pinned certificates, but does not support CRLs? Because by my
reading, I could not do that.
-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security| www.securityintelligence.com
Without data, all you are is just another person with an opinion - Unknown
From:
Bret Jordan <Bret_Jordan@symantec.com>
To:
"cti-taxii@lists.oasis-open.org"
<cti-taxii@lists.oasis-open.org>
Date:
01/28/2017 02:04 PM
Subject:
[cti-taxii]
Tuesday's Working Call
Sent by:
<cti-taxii@lists.oasis-open.org>
I would like to discuss the authentication
and certificate pieces on this Tuesday's working call. We seem to have
a divide in the community about what to do here. Some are saying
we should be completely silent, others are saying we should define it because
otherwise the only interoperability we will have is a "best practice".
The group seems to be divided nearly 50/50.
What I am going to propose is that we put things like the certificate
authentication and certificate handing parts in the "Optional Features"
part of the Conformance Section. This would allow us to specify exactly
how it should be done, if you decide to implement it. We need to
make sure we take in to account cloud services that may not give you a
lot of flexibility over the stack that you are using. But I think
we can solve this.
So if you have opinions on this topic,
please join us on this weeks working call.
Thanks
Bret
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]