UUID version 5 support

[david-waltermire]

User Story:

As an OSCAL content creator, I'd like to use a version 5 UUID to generate a deterministic document level UUID in OSCAL. The current OSCAL UUID data type only allows a version 4 uuid to be used.

Goals:

• Add support for version 5 UUIDs in OSCAL.
• Allow the document-level UUID to be a version 5 UUID.

Dependencies:

None.

Acceptance Criteria

• All OSCAL website and readme documentation affected by the changes in this issue have been updated. Changes to the OSCAL website can be made in the docs/content directory of your branch.
• A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
• The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.

{The items above are general acceptance criteria for all User Stories. Please describe anything else that must be completed for this issue to be considered resolved.}

[bradh]

Does it really need to be any particular version? From an interoperability point of view, its essentially opaque identifier.

There could be reasons for a particular kind of UUID (e.g. to avoid revealing information), but those are perhaps more aligned to be specified in a domain profile rather than in OSCAL.

[Agh42]

I would very much like to be able to encode i.e. a namespace, issuer, document and revision into the generated UUID. This allows to quickly identify changed or equal documents.

As described in RFC4122, this requires a version 3 or 5 UUID. Since v3 uses a MD5 hash, the use of v5 would be preferable.

[bradh]

You could also encode those using props and then would be able to tell what is different, which is the newer version and the like.

[david-waltermire]

From RFC4122, the UUID versions are:

Msb0	Msb1	Msb2	Msb3	Version	Description
0	0	0	1	1	The time-based version
0	0	1	0	2	DCE Security version, with embedded POSIX UIDs.
0	0	1	1	3	The name-based version that uses MD5 hashing.
0	1	0	0	4	The randomly or pseudo-randomly generated version.
0	1	0	1	5	The name-based version that uses SHA-1 hashing.

• A version 1 UUID could result in some collisions for UUIDs generated at the same time if the same node ID is used. For this reason it is less useful for an identifier where multiple organizations are producing simultaneously. This also has privacy considerations due to the mixing of time and node id.
• I don't think we have a use for version 2, since we are not using POSIX UIDs. We can always add support for these in the future if there is a compelling reason to do so.
• A version 3 UUID is based on MD5, which is known for collision issues. This was implied above by @Agh42. This makes this version less useful as well.

This leaves versions 4 and 5 as great candidates for use. I believe we should support both anywhere a UUID is allowed in OSCAL.

[bradh]

I think the collision on MD5 is less relevant. There are known attacks against MD5, but the chance of an accidental collision is still very low. Its far more likely that someone will cut'n'paste a UUID (of any version) as part of a document header and forget to change it.

I still think it would be easier to just drop the version part and let people use whatever works for them. It'll also be future proof (when we decide SHA-1 isn't enough for every purpose and there is a version 6 or 7.

[david-waltermire]

If a version 3 uuid is ok, then a version 5 uuid provides the same capability with less issues.

@bradh Why not just use a version 5 uuid instead?

[bradh]

I think we're at cross-purposes here. I'm completely supportive of having version 5 support.

However if someone wants to generate version 3 (say because their tools don't do version 5), I don't see that hurts anything.

Equally, if someone has a use for version 1 node+time basis, that is OK too. I struggle to come up with a use of version 2, but I don't think that a version 2 UUID is going to cause interoperability problems* if someone wanted to use it.

It just seems unnecessary to restrict the version at the OSCAL core level.

*If there is an interoperability problem with consumers checking the UUID structure, then version 5 is possibly also a problem, and this would need to be kicked to 2.x. I really don't see it happening though.