Should setting id_ only set the local part of the ID? #222

MarkDavidson · 2014-10-27T16:29:04Z

Right now, properly setting custom IDs is somewhat counter-intuitive (to me).

The python-stix documentation has information on setting ID namespaces [1], which at present boils down to set_id_namespace({"http://MY-NAMESPACE.com" : "myNS"}) which causes myNS to be registered as an alias for http://MY-NAMESPACE.com.

After setting the namespace, IDs currently need to be set with the namespace alias in mind. For example: sp = STIXPackage(id_='myNS:SomeID') is required if you want to use SomeID instead of an auto-generated ID. However, I think this might trip some people up. I think some people would expect the id_ kwarg to just set the local part, and that the API would automatically prepend the alias (e.g., myNS). For example, I could see people thinking that sp = STIXPackage(id_='local_part_only') would create a valid ID because the APIs would "know" to prepend the NS alias.

This issue is to discuss this point of view and, should there be a consensus, possibly modify the implementation of IDs. One outcome could be that if there is not a namespace alias set in the id_ property, use the ID namespace. If there is a namespace alias set in the id_ property, use the specified namespace alias.

Thoughts?

Note: #176 might be related

[1] http://stix.readthedocs.org/en/latest/examples/index.html#id-namespaces

The text was updated successfully, but these errors were encountered:

MarkDavidson · 2014-10-27T16:29:50Z

FYI (Where I'm coming from): crits/crits#285

packet-rat · 2014-10-27T18:15:45Z

@MarkDavidson - I originally thought it was the way I was setting namespaces in crits/core/crits_mongoengine.py:

    #
    # Set the STIX namsespace to replace "example"
    from stix.utils import set_id_namespace
    STIXNAMESPACE = {"http://intinc.specere.org" : "INTINC-Dev"}
    set_id_namespace(STIXNAMESPACE)
    # Set the CybOx namespace to replace example
    from cybox.utils import set_id_namespace, Namespace
    from cybox.core import Observable

    CYBOXNAMESPACE = Namespace("http://intinc.specere.org" , "INTINC-Dev")
    set_id_namespace(CYBOXNAMESPACE)

Note: Suggest setting the Namespace attributes et al be handled as config localizations vs. requiring modifications to core modules.

Also note that I've gone back to STIX packages created before any Namespace customizations (the original Example) and see the same artifacts:

<stix:STIX_Package 
    xmlns:cyboxCommon="http://cybox.mitre.org/common-2"
    xmlns:cybox="http://cybox.mitre.org/cybox-2"
    xmlns:cyboxVocabs="http://cybox.mitre.org/default_vocabularies-2"
    xmlns:ArtifactObj="http://cybox.mitre.org/objects#ArtifactObject-2"
    xmlns:FileObj="http://cybox.mitre.org/objects#FileObject-2"
    xmlns:URIObj="http://cybox.mitre.org/objects#URIObject-2"
    xmlns:example="http://example.com"
    xmlns:incident="http://stix.mitre.org/Incident-1"
    xmlns:indicator="http://stix.mitre.org/Indicator-2"
    xmlns:stixCommon="http://stix.mitre.org/common-1"
    xmlns:stixVocabs="http://stix.mitre.org/default_vocabularies-1"
    xmlns:stix="http://stix.mitre.org/stix-1"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="
    http://cybox.mitre.org/common-2 http://cybox.mitre.org/XMLSchema/common/2.1/cybox_common.xsd
    http://cybox.mitre.org/cybox-2 http://cybox.mitre.org/XMLSchema/core/2.1/cybox_core.xsd
    http://cybox.mitre.org/default_vocabularies-2 http://cybox.mitre.org/XMLSchema/default_vocabularies/2.1/cybox_default_vocabularies.xsd
    http://cybox.mitre.org/objects#ArtifactObject-2 http://cybox.mitre.org/XMLSchema/objects/Artifact/2.1/Artifact_Object.xsd
    http://cybox.mitre.org/objects#FileObject-2 http://cybox.mitre.org/XMLSchema/objects/File/2.1/File_Object.xsd
    http://cybox.mitre.org/objects#URIObject-2 http://cybox.mitre.org/XMLSchema/objects/URI/2.1/URI_Object.xsd
    http://stix.mitre.org/Incident-1 http://stix.mitre.org/XMLSchema/incident/1.1.1/incident.xsd
    http://stix.mitre.org/Indicator-2 http://stix.mitre.org/XMLSchema/indicator/2.1.1/indicator.xsd
    http://stix.mitre.org/common-1 http://stix.mitre.org/XMLSchema/common/1.1.1/stix_common.xsd
    http://stix.mitre.org/default_vocabularies-1 http://stix.mitre.org/XMLSchema/default_vocabularies/1.1.1/stix_default_vocabularies.xsd
    http://stix.mitre.org/stix-1 http://stix.mitre.org/XMLSchema/core/1.1.1/stix_core.xsd" id="71f3d913-52bb-480e-a95b-c4b466ed7e18" version="1.1.1" timestamp="2014-10-13T20:48:49.678029+00:00">
    <stix:STIX_Header>
        <stix:Title>Test</stix:Title>
        <stix:Package_Intent xsi:type="stixVocabs:PackageIntentVocab-1.0">Threat Report</stix:Package_Intent>
        <stix:Description>This is the Event Main Description Field</stix:Description>
        <stix:Information_Source>
            <stixCommon:Identity id="example:Identity-1ff30e47-89d1-4314-be5b-5613e04e464a">
                <stixCommon:Name>INTINC-Dev</stixCommon:Name>
            </stixCommon:Identity>
            <stixCommon:Time>
                <cyboxCommon:Produced_Time>2014-10-13T16:48:49.677859</cyboxCommon:Produced_Time>
            </stixCommon:Time>
            <stixCommon:Tools>
                <cyboxCommon:Tool>
                    <cyboxCommon:Name>CRITs</cyboxCommon:Name>
                    <cyboxCommon:Vendor>MITRE</cyboxCommon:Vendor>
                    <cyboxCommon:Version>4-master</cyboxCommon:Version>
                </cyboxCommon:Tool>
            </stixCommon:Tools>
        </stix:Information_Source>
    </stix:STIX_Header>
    <stix:Observables cybox_major_version="2" cybox_minor_version="1" cybox_update_version="0">
        <cybox:Observable id="example:Observable-164552bc-ad4f-4b3c-97dc-6c8dc0eac2c6">
            <cybox:Object id="example:File-04820cce-520b-40c5-8b33-877c99255702">
                <cybox:Properties xsi:type="FileObj:FileObjectType">
                    <FileObj:File_Name>20140610 DDoS attack UDP - NTP on 30 MAY 2014 Source_IPs.txt</FileObj:File_Name>
                    <FileObj:Size_In_Bytes>5342</FileObj:Size_In_Bytes>
                    <FileObj:File_Format>ASCII text, with CRLF line terminators</FileObj:File_Format>
                    <FileObj:Hashes>
                        <cyboxCommon:Hash>
                            <cyboxCommon:Type xsi:type="cyboxVocabs:HashNameVocab-1.0">MD5</cyboxCommon:Type>
                            <cyboxCommon:Simple_Hash_Value>6e6d0f5a3c1052c1ea19258e62e0209e</cyboxCommon:Simple_Hash_Value>
                        </cyboxCommon:Hash>
                        <cyboxCommon:Hash>
                            <cyboxCommon:Type xsi:type="cyboxVocabs:HashNameVocab-1.0">SHA1</cyboxCommon:Type>
                            <cyboxCommon:Simple_Hash_Value>efdf3e4fa344a31ffff6ba56fc29ebdbd839f0dc</cyboxCommon:Simple_Hash_Value>
                        </cyboxCommon:Hash>
                        <cyboxCommon:Hash>
                            <cyboxCommon:Type xsi:type="cyboxVocabs:HashNameVocab-1.0">SHA256</cyboxCommon:Type>
                            <cyboxCommon:Simple_Hash_Value>b4654e9cdf7c3b68cb048a50e92e5570f4f52667190002c18aa43a45bf9dbf0e</cyboxCommon:Simple_Hash_Value>
                        </cyboxCommon:Hash>
                        <cyboxCommon:Hash>
                            <cyboxCommon:Type xsi:type="cyboxVocabs:HashNameVocab-1.0">SSDEEP</cyboxCommon:Type>
                            <cyboxCommon:Simple_Hash_Value>96:1O/CkPTAweF/XvYEePw65CU5KnxiVVxxJdhs0ShrQTapjKob0mABD:1OhAwQ/eZzVVzJd+0qQTaQobbAB</cyboxCommon:Simple_Hash_Value>
                        </cyboxCommon:Hash>
                    </FileObj:Hashes>
                </cybox:Properties>
                <cybox:Related_Objects>
                    <cybox:Related_Object id="example:Artifact-bbbaf757-7aa1-481b-83fc-63340a12c913">
                        <cybox:Properties xsi:type="ArtifactObj:ArtifactObjectType" type="File">
                            <ArtifactObj:Packaging>
                                <ArtifactObj:Encoding algorithm="Base64"/>
                            </ArtifactObj:Packaging>
                            <ArtifactObj:Raw_Artifact><![CDATA[MTA5LjExMS4yMzUuOTgNCjU5LjE0NS4xMzIuNzANCjYxLjM2LjIxOS4zNg0KMTI1LjIxLjU1LjE0DQo0Ni4xOS45OS44DQoxODguMjQxLjIwMC4yDQo1OS4xNDUuMjMyLjYNCjE4MC4yMzUuMTYzLjQyDQoxODcuNjAuMjE1LjY2DQo4Mi4xMTkuOTAuMTc0DQo2MS4yNDYuMjA4LjEzOA0KODUuMjYuMjA3LjIyNg0KMTk4LjIxMS41OS4xNjINCjgwLjExMC40MC44OA0KMjEyLjY2LjM4LjM0DQoxMDMuMTYuMTQ2LjI0Mw0KMTk4LjE1My4xOTIuNTANCjE5NC4xNDMuMTQ4LjcNCjQ2LjE5Ljk3LjEwNg0KNDYuNDAuODcuMTc4DQoxNjIuOTcuODEuMg0KMTgyLjczLjg1LjI2DQoyMTcuMjUuMjExLjMwDQoyMTMuMTcyLjE3Ni4yMDYNCjQ2LjI1NS45Ny4yNg0KMTk0LjQ0LjIzNy4yMTgNCjIwMy4xMDEuNzYuMTA2DQoyMDcuMjA0LjE5NC4yMDYNCjQ2LjE5Ljk2LjExNA0KODAuOTcuNTYuMjUzDQo3MC4zNC4xNDQuMjEwDQo2MS4yNDYuMTEuNTgNCjk0LjEwMC44MC4xMTANCjg4LjIyMC4xNjguNzANCjIxNy4xNTAuMzkuMjA5DQoyMTEuMTY2LjAuMTY4DQo1OS4xNDUuOTguMTA2DQo4Ny4yMjkuMjQuMjMNCjc4LjE0MC42My43NQ0KMjE2LjY2LjcwLjIyDQoxODMuODcuMTA1LjYNCjE3OC4yMTcuOC43OA0KOTEuODIuMTEyLjE5NA0KMjEzLjIwMC4xMi4yMDYNCjQ2LjE5Ljk2LjIxMA0KMTE0LjE0MS44OS4zNg0KNjYuMTI4Ljk1LjQyDQoyMDYuNTUuMTIxLjEzMQ0KNzguMjUuMTI3LjE2Ng0KMjAxLjE2OC4xNDAuMg0KNjkuNTguMTE1LjIyDQoxNzguMjE3LjEwLjYNCjE5NS4xNzUuNjMuMTc0DQo5MS4xMDYuMzUuMTU0DQoxMDUuMjM2LjczLjIyNA0KNzguMTU1LjIyLjE1DQo4My4xMzYuMjAxLjgNCjc4LjE4OS41LjE5Mg0KMTAzLjIyNi41NS4xOTMNCjIwOS45Ni4yNDcuMzQNCjExMy4yMy4xODIuMjQyDQozNy4yMzUuNzEuMzgNCjM3LjIzNS42Ny4xOTENCjkzLjEyNS44LjEyMQ0KOTEuMTQ0LjE3OC4xMDUNCjEwMy4yMjUuNjYuMjIxDQo2Mi4xMDAuMTEwLjIzNA0KNzcuMjQzLjExMy4xNDYNCjExMi43OC4xNDguMTE4DQoxOTMuMzQuNjEuMjUwDQoyMTMuMTMwLjEwLjE3NQ0KNzcuMjQzLjExNC4xNjkNCjgyLjE5Ni4xNDkuMTcNCjMxLjIyLjIxLjEzMw0KMjQuMTE0LjExMi4zMg0KNDIuNjEuNTEuMTQ3DQo2NS45Ny4yMzAuMTQ2DQo3OC4yNC4xMzEuNzgNCjc4LjI0LjEzMS43OQ0KODkuMjQ4LjE2OC4xNjgNCjg4LjIwMC4yMjIuMjMwDQo2NS45Ny4yMzAuMTY1DQo4MC44Mi43OC4yDQo0Ni4yNTIuNjUuNjYNCjMxLjUyLjExMS4yMjMNCjY2LjE3Mi4yNDkuMTINCjY3LjUwLjg5LjQNCjQ2LjIzNC4xMTMuMjMwDQozNy41Ny4yMTkuNDMNCjQyLjYxLjExMS4xNDcNCjQ5LjEuMjExLjI1Mg0KNDkuMS4yMTEuMjUxDQo0Mi42MS4xMDMuNzANCjQ5LjEuMjExLjI1Mw0KODEuMTQ5LjMwLjE5DQo4Mi4xNDcuOC4xODYNCjk1LjYyLjg2LjEzNg0KNzAuOTYuMTA2LjIwDQo4Mi4xNDcuOC4xNDANCjk1Ljg0LjIxMC4xMDQNCjQyLjYwLjI0Ni4yMDgNCjg1LjkyLjIxNS4xODQNCjg1LjkyLjIxNS4xODkNCjQ5LjEuMjE4LjEzMA0KODIuMTQ3LjguMTg1DQo3NS4xMjcuMTE1LjUwDQo4NS45Mi4yMTUuMTkwDQo4NS45MS42LjczDQo4NS45Mi4yMTUuMTg4DQo4OS40Mi41My41DQo3Ny4xMDkuODUuMw0KNDIuMTEyLjQuMTMxDQo3Ny4xMDkuODUuMg0KNjQuMjAxLjI0MS4yMjENCjYyLjcxLjEwNi4yNTANCjQwLjEzNC4yMjcuMTYyDQo5My4xODcuMTY4LjQxDQo0MS43NS4yMDcuMTMwDQo2Ni43Ni40NC4xNjENCjIzLjgwLjk0LjEyMQ0KMjQuMTI0LjAuMjUxDQo2Mi4xODkuMjkuMjQzDQo1LjE0NS4xNjguMjQyDQo4Mi4xMzcuMjQ4LjMNCjkyLjU1LjEwNy4xOTUNCjQwLjEzMy4xMzEuMTANCjc3LjIxMS4xNi4xMzUNCjguNi4yMjMuMTMNCjk0LjMxLjU2LjINCjcyLjIzMi4yMDkuODUNCjY3LjE5OC4xODguMTUNCjUwLjI1LjI1LjINCjcyLjIzMi4yMDkuODYNCjkxLjIwMi40MS4xNDINCjY1LjExMS4xMTIuMTEwDQo4My45Ny44Ni41DQo5NS42MC4yMzIuODUNCjk1LjYwLjE4Ni44DQo2Ni4xNDYuMTU4LjEzMg0KNjEuNTguMTM2LjI0Ng0KODEuMTQ5LjE3My4xNzYNCjg5LjQyLjUzLjUNCjQyLjExMi40LjEzMQ0KOTIuNTUuNzYuNDINCjY2Ljc2LjQ0LjE2MQ0KNjQuMjAxLjI0MS4yMjENCjkzLjE4Ny4xNjguNDENCjYyLjcxLjEwNi4yNTANCjI0LjEyNC4wLjI1MQ0KNDEuNzUuMjA3LjEzMA0KNDAuMTM0LjIyNy4xNjINCjUuMTQ1LjE2OC4yNDINCjQwLjEzMy4xMzEuMTANCjYyLjE4OS4yOS4yNDMNCjIzLjgwLjk0LjEyMQ0KOC42LjIyMy4xMw0KOTIuNTUuMTA3LjE5NQ0KOTQuMzEuNTYuMg0KNzIuMjMyLjIwOS44NQ0KOTQuMzEuNTYuMw0KMTQuMTguMTcuMTA4DQo2MS4xOTAuMTEyLjIyDQo2Ny4xOTguMTg4LjE1DQo3Mi4yMzIuMjA5Ljg2DQo3Ni43My4xNjYuNA0KOTEuMjAyLjQxLjE0Mg0KNTAuMjUuMjUuMg0KOTEuMTk2LjE3MC4xODkNCjY2Ljc2LjEwNy4yMTANCjIzLjE5LjExNC45MQ0KNjUuMTExLjExMi4xMTANCjkzLjk5Ljc2LjEzMA0KNjEuMTY0LjEyMC4yDQo3OC42LjgzLjU4DQo2MS4xNTUuMjExLjMzDQo4Mi4xMzcuMjQ4LjMNCjc2LjEwLjguMTgNCjYyLjE3OS4xMDQuMTQ2DQo0Ni41LjExLjENCjc3LjEwNC4yMTQuOA0KOTQuMTEzLjI1NC4xNDINCjgzLjEwMy4xNjEuMTU1DQo2MS4xNTcuMTUzLjk3DQo5MS4yMDMuMjA5LjIxDQo4NS4xODYuMjIwLjE1MQ0KOTEuMjI5LjE4Ni4zNQ0KNjEuMTMwLjIxNi43NA0KNjEuMTUyLjEwOS4xOTgNCjc5LjE3MC4yMTAuMjUwDQo5MS4yMDEuMjEuMjENCjYxLjE1NS4yMTUuMTM0DQo2MS4xODMuNTMuMTkzDQo3Ny4xMDQuMjIwLjEyOQ0KNDIuNjIuNDguMTQyDQo2Ni4yMzEuMTgzLjQxDQoxNC4xNy4xMTEuMw0KNjIuMTc5LjEwNC4xNDUNCjgwLjg0LjY2LjIwDQo2MS45Ny45LjEwMA0KNjEuMTMwLjIxNi43Mw0KNjEuMTY0Ljc5LjE4Nw0KNjYuMjMzLjE2NS40NA0KNzguOTcuOTQuMjQ0DQo4NC4yNDIuOTMuMTM0DQo4NS4xODYuMjQyLjQxDQo4MS4yMjMuOTkuNTANCjUwLjI0NC4xMjYuMTU0DQozNy4wLjMyLjM2DQo3Ni4zMC4yMS4yNDANCjYxLjE3NC41MC4yMzANCjkzLjk5LjE3OS42OA0KOTIuNjIuMjI5LjE5DQozNi4zOS44LjEzOQ0KNjQuOTQuMS4xMjANCjYxLjE4My41My4xMzgNCjEuMTc2Ljc0LjE5OA0KMTQuMTguMjA0LjE1MQ0KNjEuOTcuMS4xODYNCjUwLjc4LjIyMy42NQ0KNjEuMTc0LjUwLjIyOA0KOTEuMTQ0LjkuNDMNCjM3LjE5MS4xMzEuMTkzDQo2MS4xNDcuMTE3LjE5MA0KNjEuMTc0LjkuMjUNCjkxLjE0NC45LjQ0DQozNi4zOS4xNzEuMTM0DQo4MS45Mi4xNDkuMzMNCjQyLjgyLjgwLjU4DQo2NC4xOS4xMC4zNA0KOTQuMTEyLjI1NS4yMjINCjg0LjExOS4xNzQuMTg0DQo5NC4xMTMuMjQyLjk0DQo0Ni4yMzEuMTIuMTE4DQo0Ni4xMjcuMTgzLjEyMA0KMjAwLjIyMS4xMS4xMDANCjE3Ny4yMDAuODcuMTc0DQoyMDAuNTUuMTk4LjI0Mg0KNzguMzEuMjE1LjIxOA0KMjAzLjIxNS40OC4yDQo4MC41MC4xMzAuMjE0DQoxODUuMjkuMjAzLjIzNA0KMTg5LjUzLjg2Ljc4DQo3Ny4yMjIuNzAuNTQNCjk0LjE1OC4yMjQuNTQNCjQxLjIyMS4yMTYuMTgNCjE3Ny42OS4xODguMTY5DQoxMDMuOS4xMTIuNzQNCjEyNS4yNTUuOTYuMTk0DQoxMTkuODEuNS4xMDINCjIxMi4xNTguMTI5LjIwMg0KMTExLjY3LjkyLjk0DQoxODkuMTEyLjg5LjEyDQoyMTIuMTEzLjIzMS4xNzgNCjc5LjEyNC4yLjINCjE3Ny4xNTUuMTczLjM4DQo1OS4xNTIuOTguMTQ2DQoxMDMuNS4xODcuMTANCjE4Ni4yMjUuNTMuMTg2DQoxMTAuNDQuOTYuMTMxDQoyMDAuMTg4LjI0NC4xNjMNCjE4Ny4xMTEuMjIxLjcwDQoxOTUuNzMuMTI2LjE5MQ0KMjAwLjE2Ny4yMDkuMzANCjE4OS45MS4xMy4xNTcNCjIxMi4xNjkuNDkuMTA5DQoxOTUuNzMuMTM5LjE3Nw0KMTc3LjIyMC4yMDAuNg0KMTc2LjEwOS4wLjI0DQo4Ny4yNDUuMjI5LjEwNg0KMzguMTIyLjIwNi40Ng0KODQuNDEuMTE3LjM2DQoxOTUuMjE4LjIzMS4xNzgNCjIxNy42NS44OS4yMTANCjg2LjUzLjExOS4zMA0KODguMjIwLjE2OC42DQoyMTIuMTAwLjE0Ni4xOTQNCjE3Ny4yMC4xODkuMTANCjIwMy42Ni44Ni40MQ0KMTc3LjE1NS4yMTEuMTYyDQoxNTkuMjI0LjE3MS4xDQo4NC40MS4xMDguNzQNCjg2LjUzLjEyOC4yNg0KOTIuODYuMzMuODINCjgzLjE0NS4xMzIuNTANCjE3Ny44NC43MC44MQ0KNzkuMTI2LjEyMi4yMTQNCjE3Ny4zOC4yNDUuMTYyDQoxNzguMTUwLjY1LjENCjE5NS4yMi4yMjIuNg0KMTg1LjI3LjIxOC4xMDINCjE4Ny4zMy4yMjYuNTQNCjE5NS44MS4xMjMuOTANCjY2LjIzMi43MC4yMzQNCjU5LjE1Mi4xMDEuMTANCjE3Ny4yMjAuMjAwLjI3DQoyMDAuMjM3LjEyOS4xNTQNCjEwMy4xNS4yNDcuMTgNCjE3OS4xODkuMi4yNTANCjg5LjEwNy4xNTUuMTg2DQoxOTUuNzMuMTYxLjkNCjE5My4xNzMuNS4yMTYNCjE4OC4xMzYuMjIwLjMzDQoxNzcuMTEuMTYzLjI2DQoxODcuNjMuMTUuNjYNCjE3Ny41NS42MC4xOA0KNjIuMjU0LjExNy4yMg0KMjAzLjE3Ni4xMjkuMTA3DQo4Ni41My4xMjguMjE0DQoxMjYuNDcuMjQ4LjI1MA0KMTc3LjIyMy40OC4xNDYNCjE5NS4xMjIuMTk3Ljg2DQoxODkuODYuODQuMTMwDQoyMjAuMjI3LjQ2Ljc3DQoxODcuNjAuNDEuMTAyDQoxODYuMjI1LjE3Ni42Ng0KODUuMjM1LjE5Mi4xOTgNCjE3Ny41My4xODQuNDINCjE4Ny42My4yMjguNTgNCjE4OS43Ni4yMTUuMTQNCjE4Ni4yMTEuMTc2LjIzMA0KMTE0LjQuMjQuMTM0DQo4Ni41My4xMTkuODINCjE5MC45MC4zMC4xMjINCjg2LjUzLjEyNC41NA0KMTE1LjI0OS45LjE2MQ0KOTMuMTU5LjEyOS41OA0KOTMuOTEuMTQ0LjE2DQoyMDAuMjQyLjE3LjEwNg0KODYuNTMuMTE5Ljk4DQoxNzcuMTA0LjI1My4xOA0KNzcuODguMjE5LjQyDQo4Ni41My4xMjguMTIyDQoxODYuMjA4LjEyNy4xMDYNCjEwNS4yMzUuMjI1LjIyMw0KMTc3LjIyMy4wLjM2DQoxMjMuNjMuMjE0LjkzDQo2Ny4yMjIuMTYxLjINCjg2LjEwMS4xNzkuNDYNCjgyLjE0OC4xNjAuMjIyDQoxNzYuMTE5LjIyNC41MA0KMjEzLjIxNy4xNTUuMjUwDQoyMTIuMzkuMTI1Ljg2DQoxOTYuNDEuOS4yNg0KOTMuODcuNzMuMTU0DQoyMTMuMTM1LjkzLjUyDQoxOTUuMTc4LjMzLjE3MA0KMTc3LjM4LjguMTA2DQoyMDAuMTEwLjkzLjQ4DQo2Ni43Ni4xMTUuMTU4DQoxNzcuNS4yNDcuMTcwDQoxODMuOTEuODUuMTMwDQo5MS4yMjYuNTAuNDMNCjE4Ny40NC4xMzguMzQNCjEwMy4yNDEuNC4yNDYNCjIxMi45MS4xODkuNg0KMjAxLjE2OC4yMDQuNDINCjYyLjEyLjE3Ny4xNTUNCjE4Mi4xOS42MS4xNDkNCjIwMi4xNTIuNDMuMTUwDQoyNy4xMjMuMjE1LjIyMg0KMTU5LjI1NS4xNjcuNDkNCjE3OC44OS4xMDcuMzA=]]></ArtifactObj:Raw_Artifact>
                        </cybox:Properties>
                        <cybox:Relationship xsi:type="cyboxVocabs:ObjectRelationshipVocab-1.1">Child_Of</cybox:Relationship>
                    </cybox:Related_Object>
                </cybox:Related_Objects>
            </cybox:Object>
        </cybox:Observable>
    </stix:Observables>
    <stix:Indicators>
        <stix:Indicator id="example:indicator-c1c43f28-40c1-4ce2-a22c-a44a09f61f4a" timestamp="2014-10-13T20:48:49.674587+00:00" xsi:type='indicator:IndicatorType' negate="false" version="2.1.1">
            <indicator:Observable id="example:Observable-988add80-f1cc-42a7-b4c1-35bd7242ab37">
                <cybox:Object id="example:URI-fb10373d-134f-47f1-b088-c4b63e9a50a1">
                    <cybox:Properties xsi:type="URIObj:URIObjectType" type="URL">
                        <URIObj:Value>http://badguys.com/badstuff.php</URIObj:Value>
                    </cybox:Properties>
                </cybox:Object>
            </indicator:Observable>
            <indicator:Producer>
                <stixCommon:Identity id="example:Identity-093c3b8d-a95d-4e17-819a-2e5f38006cff">
                    <stixCommon:Name>INTINC-Dev</stixCommon:Name>
                </stixCommon:Identity>
            </indicator:Producer>
        </stix:Indicator>
        <stix:Indicator id="example:indicator-d52d546e-8f88-411b-91b4-5d4946bcb22c" timestamp="2014-10-13T20:48:49.674993+00:00" xsi:type='indicator:IndicatorType' negate="false" version="2.1.1">
            <indicator:Observable id="example:Observable-47900804-fd63-4e42-8684-bf075ec71206">
                <cybox:Object id="example:URI-671e0386-3cbb-40ef-a254-c2cf58367917">
                    <cybox:Properties xsi:type="URIObj:URIObjectType" type="URL">
                        <URIObj:Value>http://reallybadguys.com/badstuff.php</URIObj:Value>
                    </cybox:Properties>
                </cybox:Object>
            </indicator:Observable>
            <indicator:Producer>
                <stixCommon:Identity id="example:Identity-0aa49c35-e7eb-43a6-9742-c0237e7b3d9a">
                    <stixCommon:Name>INTINC-Dev</stixCommon:Name>
                </stixCommon:Identity>
            </indicator:Producer>
        </stix:Indicator>
    </stix:Indicators>
</stix:STIX_Package>

MarkDavidson · 2014-10-27T18:34:57Z

Ah - I think I see what's happening.

In CRITs, the STIX_Package/id is being created with [1]:

stix_msg['stix_obj'] = STIXPackage(indicators=stix_msg['stix_indicators'],
                        observables=Observables(stix_msg['stix_observables']),
                        threat_actors=stix_msg['stix_actors'],
                        stix_header=header,
                        id_=uuid.uuid4())

What's funny is, it's only schema-invalid if the leading character of the UUID is a number. So a UUIDs of the form [a-f].... is schema valid while UUIDs of the forms [0-9]... are not. Therefore, the issue might not show up right away, and won't always show up.

I see three possible remediations, all probably belong in the CRITs code:

Prefix all IDs with package (per the suggested practices [2])
Have CRITs use the defined namespace prefix.
Both

Edit: Opened an issue here: crits/crits#289

[1] https://github.com/crits/crits/blob/master/crits/core/crits_mongoengine.py#L764
[2] http://stixproject.github.io/documentation/suggested-practices/

mgoffin · 2014-10-27T19:20:06Z

If I am reading the documentation properly, the reason that this isn't an issue is because STIX prefers that you add a construct-type in front of the GUID, thus guaranteeing there is a letter at the beginning of the ID?

MarkDavidson · 2014-10-28T13:22:18Z

@mgoffin,

You are correct that prefixing the GUID with something (like package) guarantees that the ID will be a schema valid QName (why QNames are OK with letters but not numbers, I have no idea).

-Mark

bworrell · 2014-10-28T13:31:38Z

@MarkDavidson, @mgoffin ,

A quick observation regarding the CRITs example that @MarkDavidson provided:

stix_msg['stix_obj'] = STIXPackage(indicators=stix_msg['stix_indicators'],
                        observables=Observables(stix_msg['stix_observables']),
                        threat_actors=stix_msg['stix_actors'],
                        stix_header=header,
                        id_=uuid.uuid4())

I think one way to approach this may be to just not set the id_ paramter in __init__. By not specifying an id_ parameter, python-stix will generate one.

Internally, python-stix uses uuid.uuid4() but prepends the ns alias and construct type as well, rendering a valid STIX id. The namespace portion of the id can be adjusted via the set_id_namespace method that @MarkDavidson mentioned.

MarkDavidson mentioned this issue Oct 27, 2014

XML Validation Errors in TAXII Service STIX Packages : Example stix:Observables crits/crits#285

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Should setting id_ only set the local part of the ID? #222

Should setting id_ only set the local part of the ID? #222

MarkDavidson commented Oct 27, 2014

MarkDavidson commented Oct 27, 2014

packet-rat commented Oct 27, 2014

MarkDavidson commented Oct 27, 2014

mgoffin commented Oct 27, 2014

MarkDavidson commented Oct 28, 2014

bworrell commented Oct 28, 2014

Should setting id_ only set the local part of the ID? #222

Should setting id_ only set the local part of the ID? #222

Comments

MarkDavidson commented Oct 27, 2014

MarkDavidson commented Oct 27, 2014

packet-rat commented Oct 27, 2014

MarkDavidson commented Oct 27, 2014

mgoffin commented Oct 27, 2014

MarkDavidson commented Oct 28, 2014

bworrell commented Oct 28, 2014