[3.9] Extensibility & profile composition #9

Activity

1. ozzyathome

   added

   aspect:extensibility3.9 Extensibility & profile composition3.9 Extensibility & profile composition

   status:deliberatingOpen argument — options being exploredOpen argument — options being explored

   type:decisionA concrete choice to be resolvedA concrete choice to be resolved

   needs:ownerNo aspect owner assigned yetNo aspect owner assigned yet

   on Jun 17, 2026
2. Grego22 commented on Sep 30, 2026

   

   Grego22

   on Sep 30, 2026

   More actions

   On draft decision 0022 (#52) and the PQC migration use case, one gap in pqc-migration-extended#I9, raised here ahead of the rules-file PR.

   Disclosure. I work at Qrypt, which sells entropy products. The proposal names no product or vendor.

   pqc-migration-extended#I9 asks for the services an interface's cryptography depends on at run time, and the list includes a time source. No one migrates a time source to post-quantum algorithms. It is there because the interface's cryptography fails without it and it has to be checked before the change goes in. The random bit generator a product draws from is the same kind of dependency, and the Keycloak example shows why it belongs on the list.

   • FIPS 203 and FIPS 204 set a minimum RBG security strength for each parameter set, 192 bits for ML-KEM-768 and for ML-DSA-65 key generation. Once JEP 527 lands, the hybrid groups depend on the provider's generator meeting that strength, and so would any ML-DSA realm key the Admin API eventually generates. A generator's default configuration is not always the strength the parameter set needs, so the operator has to confirm it.
   • int-cache generates and rotates its own RSA-2048 key inside the product. If the image runs on VMs that are snapshotted or cloned, or the JVM is checkpointed and restored, generator state can be duplicated unless something reseeds it.

   None of this is about source quality. A correctly seeded DRBG at adequate strength is enough. The operator still has to confirm the strength, which module's generator is in use, and how clones and restores are handled before new keys are generated. All three sit outside the interface in the same way the time source does.

   It is also declarable at the boundary. The vendor can state that the product draws from the platform's generator, which is a property of the image as shipped. Which platform generator feeds it is a fact about a deployment and belongs in a separate document, as the ZIP distribution's runtime does.

   The proposal is small. Add random-bit-generator to the I9 value list, with the row reading "certificate authority, revocation responder, directory, identity provider, HSM, key vault, time source, random bit generator, or none." For Keycloak, mgmt-admin and int-cache would list it, since both generate long-term keys inside the product. The TLS interfaces draw through the JDK provider, so the dependency would be stated once on the provider and inherited rather than repeated on seven interfaces. Where an HSM generates the key, hsm already covers it.

   Two things I'm unsure of. Whether 0022's inheritance of implementation facts applies to I9 or only to algorithm facts, and whether entropy-source would be the better name for matching time-source, though random-bit-generator is the more accurate SP 800-90 term.

   This asks for the dependency only, with no quality claim, source type or validation reference. It also stands apart from decision 0010. An interface that generates keys depends on a random bit generator at run time however randomness is classified, and I9 is where run-time dependencies go.