cti-taxii message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [cti-taxii] HTTPS implementation language
- From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
- To: Eric Burger <Eric.Burger@georgetown.edu>
- Date: Tue, 27 Dec 2016 19:13:55 -0400
I worry a lot about having such strict
requirements for TAXII.
I have said a few times on here in the
past ( Dec 16 / 2015, June 3 2016 ) that we want to be very careful here
of what we mandate vs. what we prescribe.
I do not even think stating that a client
MUST implement TLS 1.2 is a good idea because it opens the door to us having
to emergency-revise the spec if and when there is a flaw discovered in
TLS 1.2
I especially do not agree with the mandate
that a TAXII server MUST support CRLs and PKIX client certificates to be
claim TAXII compliance. What if I only want to support JWT for authentication?
-
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:
Eric Burger <Eric.Burger@georgetown.edu>
To:
cti-taxii@lists.oasis-open.org
Date:
12/23/2016 12:37 PM
Subject:
[cti-taxii]
HTTPS implementation language
Sent by:
<cti-taxii@lists.oasis-open.org>
DRAFT
2. HTTPS Requirements
The TAXII Protocol defined in this specification requires HTTPS as the
transport for all communications.
· TAXII Servers and Clients MUST implement HTTPS [RFC7230].
· TAXII Servers and Clients MUST implement TLS version
1.2 [RFC5246].
o TAXII Servers and Clients SHOULD implement later versions when
available.
· TAXII Servers MUST implement PKIX X.509 certificates
and certificate revocation lists [RFC5280 and RFC6818].
· TAXII Servers MUST support authenticating certificates
using PKIX [RFC6125].
o TAXII guarantees TAXII Clients can use at least PKIX (see above).
· TAXII Servers and Clients MAY support other certification
verification policies such as:
o Certificate Pinning: A single or limited set of either hard-coded
or physically distributed pinned certificate authorities or end-entity
certificates.
o DANE: DNS-based Authentication of Named Entities [RFC7671]
o Note that Self-Signed Certificates (like other certificates which
cannot be verified by PKIX) MAY be supported via Certificate Pinning and/or
DANE as noted above for limited, closed user group applications.
[attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]