Randomness for cryptographic values should come from the cryptographic provider

[skmcgrail]

This proposed change is driven by FIPS requirements specified in NIST.SP.800-140D

6.2 Sensitive security parameter generation and establishment methods
For the current list of CMVP-approved sensitive security parameter generation and establishment
methods, see https://csrc.nist.gov/projects/cmvp/sp800-140d.

This will then direct you towards NIST.SP.800-133:

6.1 The “Direct Generation” of Symmetric Keys
Symmetric keys that are to be directly generated from the output of an RBG shall be generated as
specified in Section 4, where B is used as the desired key K. The length of the key to be generated
depends on the length requirement of the application or algorithm with which the key is used and
the security strength to be supported. See SP 800-57, Part 1 for discussions on key lengths and the
(maximum) security strengths supported by symmetric-key algorithms and their keys

Referring to Section 4:

4 Using the Output of a Random Bit Generator
Random bit strings required for the generation of cryptographic keys shall be obtained from the
output of an approved random bit generator (RBG); approved RBGs are specified in SP 800-90.

So os.urandom would not be guaranteed to be sufficient depending on the target platform and configuration to meet these requirements. It would make sense to delegate to the cryptographic provider's RBG implementation, as if the module has an approved FIPS implementation of an RBG, then this would mean it would get used. This also aligns the RBG source for symmetric keys to be the same with where the asymmetric keys would be sourcing it's randomness (since that is done within the cryptographic module).

[alex]

Will need to discuss with @reaperhulk.