This is a very welcome update.
Here is my understanding of its applicability to industry specifications.
The ML-KEM hybrid seed derivation of X-Wing, as re-specified in the DeriveKeyPair function of the CG framework of draft-irtf-cfrg-hybrid-kems-10 and draft-irtf-cfrg-concrete-hybrid-kems-03, is an XOF seed-expansion compliant with Section 4.2.2.
However, the generation of the P-256/P-384 side of the same hybrid is not approved. (See https://filippo.io/hpke-pq#p-256-and-p-384 for a distilled specification.) This doesn’t look easily solvable.
The HPKE DeriveKeyPair procedure of the hybrids specified in draft-ietf-hpke-pq-04 and draft-ietf-hpke-hpke-03 (not the same DeriveKeyPair as above, see again https://filippo.io/hpke-pq for a distilled specification, where this is DeriveKeyPair and the above is expandKey as called by both Decaps and DeriveKeyPair) is a sequence of two nested XOF seed-expansions compliant with Section 4.2.2.
The hybrids of draft-ietf-lamps-pq-composite-kem-14 and draft-ietf-lamps-pq-composite-sigs-19 are out of scope, because they don’t derive the ML-KEM or ML-DSA seeds.
https://c2sp.org/det-keygen is a DRBG-based derivation compliant with Section 4.2.3.
(If any of the above is not accurate, it would be good for the specification to be clarified, or even better amended to actually cover the existing industry schemes.)
I interpret Section 4.2 to mean that it is acceptable to derive keys for both approved and not approved algorithms from the same KDK, as long as they are e.g. “selected from disjointed (i.e., non-overlapping) segments of the key-derivation process output.” Since this is the reality of all widely deployed approved + non-approved hybrids like X-Wing, it would be good for it to be explicitly allowed.
It is a bit unfortunate that Section 4.2.2 doesn’t allow different orderings of seed and additional input. Ordering restrictions caused unnecessary issues in the past.
I have noticed some inconsistency in the covered sections of FIPS 186-5 Appendix A: Section 4.2.1 refers to Appendices A.1.2, A.2.1, and A.2.2; Section 4.2.3 refers to Appendices A.1.3 and A.2.2. My understanding is that A.1.2 (provable primes), A.2.1 (reduction), and A.2.3 (EdDSA) take a seed or anyway a single DRBG generate output, while A.1.3 (probable primes) and A.2.2 (rejection sampling) generate multiple values from the DRBG. It seems to me that Section 4.2.1 should mention A.2.3 and not A.2.2.
Section 5.3 seems to constrain the use of HKDF-Extract (and maybe of two-step KDMs in general?) to extracting a single key from each input key material, disallowing the use of the same input key material with different salts:
Each component key shall be kept secret and shall not be used for any purpose other than the computation of a specific symmetric key 𝐾 (i.e., a given component key shall not be used to generate more than one key).
This is contradicting Section 4.2, which references Section 4.2.1 which references Section 5.2.2 which references Section 5.3:
A single key-derivation key may be used to derive multiple asymmetric and symmetric keys. This may involve:
[…]
Deriving multiple sets of keys over several key-derivation processes.
A key-derivation process may be a call to a key-derivation method (see Sec. 4.2.1) or seed-expansion method (see Sec. 4.2.2). Each key-derivation process using a given key-derivation key shall use unique additional input. [Footnote: Additional input may be reused across different key-derivation keys. A blank or “null” additional input is allowed.]
Using HKDF-Extract with unique salts to derive different keys is a secure and moderately common practice, and it would be good for it to be unambiguously approved by the upcoming SP 800-133, especially in light of the addition of RFC 5869 to SP 800-140D.