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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

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


Subject: Re: [cti] STIX 2.0 RC1


Because Bundles are not STIX objects.  They are a convenance for transporting STIX specifically outside of TAXII, but may be used in TAXII.  A consumer or producer of STIX content should not consider Bundles as existing beyond their transmission.  Meaning in most cases you would never be able to go back and ask for the same bundle again.  You would have to ask for the same content again and then it would be up to the server to determine how best to send you that data. 

Bundles have an ID, but that ID should not be considered something that is stored or recorded.  


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 Aug 20, 2016, at 08:39, Patrick Maroney <Pmaroney@Specere.org> wrote:

(1) Just curious as to why we wouldn't want to be able to show relationships between Bundles or between Bundles <> SDOs?  Not arguing one way or the other, just want to understand the basis for the suggested constraints.

(2) Concur on adding the normative language to disallow relationships between SROs.

Patrick Maroney
Email: pmaroney@specere.org
Cell: (609)841-5104

_____________________________
From: John-Mark Gurney <jmg@newcontext.com>
Sent: Friday, August 19, 2016 5:41 PM
Subject: Re: [cti] STIX 2.0 RC1
To: Wunder, John A. <jwunder@mitre.org>
Cc: <cti@lists.oasis-open.org>


Wunder, John A. wrote this message on Fri, Aug 19, 2016 at 18:55 +0000:
> Passing along one suggested change from the MITRE person writing a STIX 2 validator:
>
> Problem: Right now, there’s no normative statement that precludes a Relationship object from pointing to another Relationship object as either the source or target. We said it in the definition of the object, but when writing the validator it seemed like it would be nice to have a normative statement to reference (that could then be listed in the conformance section).
>
> Suggestion: Add the following statement to the source_ref and target_ref property descriptions on the Relationship object: “The value MUST be an ID reference to a STIX Domain Object (i.e., cannot point to an SRO, Bundle, or Marking Definition)”.

I agree that this should be included, and Terry's comment that it
needs to be added too..

--
John-Mark

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




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



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