CTI TAXII Subcommittee

 View Only
  • 1.  HTTPS implementation language

    Posted 12-23-2016 16:38
    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 Description: Message signed with OpenPGP using GPGMail


  • 2.  Re: [cti-taxii] HTTPS implementation language

    Posted 12-27-2016 14:58
    That language looks good, Eric. Thanks! -- Cheers, Trey ++--------------------------------------------------------------------------++ mobile: +32/494.766.080 gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4 5B9B B30D DD6E 62C8 6C1D ++--------------------------------------------------------------------------++ -- "No matter how hard you try, you can't make a baby in much less than 9 months. Trying to speed this up *might* make it slower, but it won't make it happen any quicker." --RFC 1925 Attachment: signature.asc Description: Digital signature


  • 3.  Re: [cti-taxii] HTTPS implementation language

    Posted 12-27-2016 23:14
    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]