UUID Generation Requirements

[telosBA]

Per OSCAL schema definition of "UUID," our team is attempting to create UUID's that have continuity at a global level. The current NIST OSCAL UUID generation method appears to be uuid4(), which yields a random generation resulting in different values across revisions unless the UUID's are saved in the database.
e.g.

import uuid
uuid.uuid4()
26bc3e7b-2169-4f25-ad82-73454644043c

Leveraging uuid5() to generate UUID's based on DNS and string name that will be globally defined, but the NIST validator does not currently support this format.
e.g.

import uuid
uuid.uuid5(uuid.NAMESPACE_DNS, "string - ie project name and tracking number")
b28d6ff2-424e-5e82-b0fb-b24eccf3506a

Another method our team came up with is to generate based on string values.
e.g.

import hashlib
import uuid
source = "String, or combo of strings, that we can pull from fields, ie field contents."
u = hashlib.md5()
u.update(source.encode('utf-8')
new_uuid = uuid.UUID(u.hexdigest())
c045303f-2ab7-6126-89e8-104715c73910

We would like some guidance on how to proceed with meeting the defined OSCAL schema requirements for UUID generation.

[bradh]

Can I ask why you are trying for continuity? What is the problem you are trying to solve?

I think the versioning should be such that "unique collection of content" should have unique identifier. I assume that tools will make the same assumptions. That is, given a UUID, if I have a file with that UUID on it, then that is the content I assume you meant (irrespective of any dates or other version numbers).

[aj-stein-nist]

I too would like to no more about the rationale.

[telosBA]

The rationale here is to create an "...identifier with cross-instance scope..." without saving generated UUID's to the DB. An example of a use case would be controls that exist in multiple OSCAL instances which should maintain continuity at the "site-level."

[bradh]

OK. For a control, I would have kept the UUID as part of the control model. I guess it depends on your implementation though.

[aj-stein-nist]

I am not sure what the issue is re UUIDv5 (because that could be a bug report if it were an error), but it seems to work fine for me.

# python3 run from shell
>>> import sys
>>> sys.version_info
sys.version_info(major=3, minor=8, micro=10, releaselevel='final', serial=0)
>>> import uuid
>>> uuid.uuid5(uuid.NAMESPACE_DNS, 'oscal.csrc.nist.gov') # Observe I used a DNS record format, not a free-form string
UUID('ae469dbc-a767-5470-9148-8961ac3bbd75')

Here is an example regex debugger showing my example as valid based on the regex sample on the OSCAL data types page and in our schema code.

We would like some guidance on how to proceed with meeting the defined OSCAL schema requirements for UUID generation.

I again refer you to the data types page, where you already confirmed we encourage UUIDv4 and UUIDv5 not so much as defined by NIST, but NIST endorsing for OSCAL use of the IETF standard proposed in RFC4122. It is short, so I recommend given your inquiry you understand that "to create UUID's that have continuity at a global level" is possible through methods, but not in the scope of the standard and not defined behavior as part of the standard. There is no global registry and community and security concerns sections call out, whether or not you do this, you are on your own about how you reason about that continuity and use it since you cannot control UUID generation outside of your application's domain with OSCAL or beyond your application generally. You probably could know that, but that is worth calling out. :-)

[GaryGapinski]

There are some novel draft UUIDs: https://datatracker.ietf.org/doc/html/draft-peabody-dispatch-new-uuid-format.

[david-waltermire]

@telosBA In OSCAL releases prior to OSCAL 1.0.4 version 5 UUIDs were not allowed due to an incomplete regex. The regex patterns that enforce UUID syntax where fixed in this version to allow type 5 UUIDs. Perhaps if you are having an issue validating, this is due to not using the latest OSCAL 1.0 patch release schemas?

[telosBA]

We were using 1.0.2, this solved our issue!