CTI STIX Subcommittee

  • 1.  Proposal - Simplify UUID Requirements/Language

    Posted 02-14-2019 16:55
      |   view attached




    I m repeating a proposal I ve made twice before in hopes it will be considered and accepted/rejected solely on its merits.  We have not re-established voting rights, so I cannot make a motion.
     
    However, I believe it is a simple solution to the STIX Identifier discourse and its adoption would allow us to move on to more complex issues.
     
    Proposal

     


    Simplify the existing language in the 2.0 CSD
    Remove the arbitrary UUIDv4 restriction.  

     

    Type Name:   identifier

     

    An  identifier  universally
    and uniquely identifies a SDO, SRO, Bundle, or Marking Definition. Identifiers  MUST  follow the form  object-type -- UUID ,
    where  object-type  is the exact value (all type names are lowercase strings, by
    definition) from the  type  property of the object being identified or referenced and
    where the  UUID  is an RFC 4122-compliant UUID. The UUID  MUST  be generated
    according to the algorithm(s) defined in RFC 4122, [ RFC4122 ].

     

    Please note the following assertions:

     


    The only requirement for using UUIDs as part of STIX Identifiers is uniqueness.
    Any RFC 4122 compliant ID form meets this requirement  (Including UUIDv1).
    RFC 4122 addresses the requirements for how compliant UUIDs are generated.
     
     
    Patrick Maroney
    Merlin Advisor to Kings
    DarkLight
    Email:   patrick.maroney@darklight.ai

     
     
    This e-mail (including any attachments) may contain information that is private, confidential, or protected by attorney-client or other privilege. If you received
    this e-mail in error, please delete it from your system without copying it and notify sender by reply e-mail so our records can be corrected.
     






  • 2.  Re: [cti-stix] Proposal - Simplify UUID Requirements/Language

    Posted 02-14-2019 17:22
    Simple and clean approach. I strongly support this. This is solving the current issue[1]. [1] https://github.com/oasis-tcs/cti-stix2/issues/133 On 14/02/2019 17:55, Patrick Maroney wrote: > I m repeating a proposal I ve made twice before in hopes it will be considered and accepted/rejected solely on its merits. We have not re-established voting rights, so I cannot make a motion. > > > > However, I believe it is a simple solution to the STIX Identifier discourse and its adoption would allow us to move on to more complex issues. > > > > *Proposal* > > * * > > * Simplify the existing language in the 2.0 CSD > * Remove the arbitrary UUIDv4 restriction. > > > > *Type Name:* identifier > > > > An identifier universally and uniquely identifies a SDO, SRO, Bundle, or Marking Definition. Identifiers *MUST *follow the form /object-type/--/UUID/, where /object-type/ is the exact value (all type > names are lowercase strings, by definition) from the type property of the object being identified or referenced and where the /UUID/ is an RFC 4122-compliant UUID. The UUID *MUST* be generated > according to the algorithm(s) defined in RFC 4122, [RFC4122 < http://docs.oasis-open.org/cti/stix/v2.0/cs01/part1-stix-core/stix-v2.0-cs01-part1-stix-core.html#2zqjjj5wdk2h >]. > > > > Please note the following assertions: > > > > * The *only* requirement for using UUIDs as part of STIX Identifiers is uniqueness. > * Any RFC 4122 compliant ID form meets this requirement (Including UUIDv1). > * RFC 4122 addresses the requirements for how compliant UUIDs are generated. > > > > > > *Patrick Maroney* > > Merlin Advisor to Kings > > *DarkLight* > > Email: patrick.maroney@darklight.ai < mailto:patrick.maroney@darklight.ai > > > cid:image001.png@01D44B7D.C4426DB0 > > > > > > This e-mail (including any attachments) may contain information that is private, confidential, or protected by attorney-client or other privilege. If you received this e-mail in error, please delete > it from your system without copying it and notify sender by reply e-mail so our records can be corrected. > > > -- Alexandre Dulaunoy CIRCL - Computer Incident Response Center Luxembourg 16, bd d'Avranches L-1160 Luxembourg info@circl.lu - www.circl.lu - (+352) 247 88444


  • 3.  Re: [cti-stix] Proposal - Simplify UUID Requirements/Language

    Posted 02-14-2019 17:48
    This is perfect! On 14.02.19 17:55, Patrick Maroney wrote: > I m repeating a proposal I ve made twice before in hopes it will be > considered and accepted/rejected solely on its merits. We have not > re-established voting rights, so I cannot make a motion. > > > > However, I believe it is a simple solution to the STIX Identifier > discourse and its adoption would allow us to move on to more complex issues. > > > > *Proposal* > > * * > > * Simplify the existing language in the 2.0 CSD > * Remove the arbitrary UUIDv4 restriction. > > > > *Type Name:* identifier > > > > An identifier universally and uniquely identifies a SDO, SRO, Bundle, or > Marking Definition. Identifiers *MUST *follow the > form /object-type/--/UUID/, where /object-type/ is the exact value (all > type names are lowercase strings, by definition) from the type property > of the object being identified or referenced and where the /UUID/ is an > RFC 4122-compliant UUID. The UUID *MUST* be generated according to the > algorithm(s) defined in RFC 4122, [RFC4122 > < http://docs.oasis-open.org/cti/stix/v2.0/cs01/part1-stix-core/stix-v2.0-cs01-part1-stix-core.html#2zqjjj5wdk2h >]. > > > > Please note the following assertions: > > > > * The *only* requirement for using UUIDs as part of STIX Identifiers > is uniqueness. > * Any RFC 4122 compliant ID form meets this requirement (Including > UUIDv1). > * RFC 4122 addresses the requirements for how compliant UUIDs are > generated. > > > > > > *Patrick Maroney* > > Merlin Advisor to Kings > > *DarkLight* > > Email: patrick.maroney@darklight.ai < mailto:patrick.maroney@darklight.ai > > > cid:image001.png@01D44B7D.C4426DB0 > > > > > > This e-mail (including any attachments) may contain information that is > private, confidential, or protected by attorney-client or other > privilege. If you received this e-mail in error, please delete it from > your system without copying it and notify sender by reply e-mail so our > records can be corrected. > > >