V6 - Requirement about UUIDs and CSPRNG

[randomstuff]

We have this requirement about UUID in "Random Value"

6.3.2 [MODIFIED] Verify that UUIDs are created with an implementation of the UUID v4 or v7 algorithms which utilizes a cryptographically-secure pseudo-random number generator (CSPRNG).

There are legitimate uses of other UUID versions (outside of cryptography) and this requirement currently forbid them if interpreted literally.

I think what we really intend to say here is:

6.3.2 [MODIFIED] Verify that UUIDs with v4 or v7 use a cryptographically-secure pseudo-random number generator (CSPRNG).

This makes sure that if any of these UUID v4 or v7 are used as secrets, this is not a great deal.

However, this quite feels weird in this section (?).

[elarlang]

Based on UUIDs own "RFC 9562 Universally Unique IDentifiers (UUIDs)", those MUST NOT be used for that

Implementations SHOULD NOT assume that UUIDs are hard to guess. For example, they MUST NOT be used as security capabilities (identifiers whose mere possession grants access). Discovery of predictability in a random number source will result in a vulnerability.

[randomstuff]

Implementations SHOULD NOT assume that UUIDs are hard to guess.

@elarlang, Oh, yes I forgot to mention that :)

But in practice, UUIDs are often used like this (as session identifiers, password reset tokens, etc.

Anyway, this requirement should probably be removed and might be replaces into requirements for generating unique random values for security:

Verify that when generating random values [TODO, for security], the application use a cryptographically-secure pseudo-random number generator and at least XX bits of entropy. UUIDs must not be used for this purpose.

[danielcuthbert]

Yes, the argument is valid. The requirement, as currently worded, could be interpreted to forbid legitimate uses of other UUID versions (such as v1, v3, or v5) that are appropriate in certain contexts outside of cryptographic needs. By specifying that only UUID v4 or v7 with a CSPRNG should be used, the requirement inadvertently disallows the use of other UUID versions even when they are suitable and safe for the intended purpose. This could lead to unnecessary constraints on developers and might force them to use less optimal solutions for their specific use cases

however, in the context of this requirement, it is in the cryptographic section and as such, would that mean it's less likely to confuse the other uses with those needing strong cryptographic foundations?

If that isn't the case, we could look at someting like this:

Verify that when UUIDs are used in security-sensitive contexts where unpredictability is important (such as session identifiers, tokens, or in URLs), they are generated using a cryptographically secure pseudo-random number generator (CSPRNG), utilizing UUID v4 or v7 algorithms. For non-security contexts where determinism or ordering is required, other UUID versions may be used appropriately.

I guess there does exist a need for contexts here but i'm also aware that this is about cryptography and not other uses

[elarlang]

I think we can just remove the requirement 6.3.2 and we don't miss anything. UUID own spec says how to (not) use it. We can add a "note" to 6.3.1 if it is really necessary that "do not use UUID for that", but I prefer to not do it.

UUID just does not match to requirement 6.3.1 and it is covered by that.

[danielcuthbert]

I'm good with that too ;). ill do a PR

[elarlang]

[DELETED, DUPLICATE OF 6.3.1]

[randomstuff]

UUID just does not match to requirement 6.3.1 and it is covered by that.

UUIDs might match the current requirements in 6.3.1 if generated using CSPRNG.

What we miss (in 6.3.1 or as a separate) requirement in to say that:

Verify that all random numbers and strings which are intended to be non-guessable must have at least XXX bits of entropy. Note that UUIDs do not respect this condition.

The usage of UUIDs for this kind of usage is prevalent, so I think it would make sense to explicitly talk about this.

[danielcuthbert]

So we deleting or amending?

[elarlang]

So we deleting or amending?

I think it is "deleting" (6.3.2) and amending (6.3.1)

[tghosth]

@danielcuthbert you are doing the PR?