Having stprov derive other/more secrets
The running of stprov remote
(on server) and stprov local
(on operator's box, op-box) uses the UDS to derive an ssh hostkey on the server and storing it in an EFi variable in NVRAM. The fingerprint of this hostkey is delivered to op-box. This is very useful for later authenticating the server and the OS package running on it, before accessing it over ssh.
But as user who has just begun thinking about OS package design, deployment etc, I immediately think that I would also like to have at least 1 WireGuard keypair generated by the stprov procedure above. The private part of course stored in an EFI var, and the public part delivered to op-box.
To me, the big deal with stprov is that we're already authenticated, the secrets are generated on the server and remain there, while at the same time the public parts are very conveniently delivered to operator.
We had some discussions on the possibility of for example letting the OS package access UDS and have it derive secrets, which would then require that we authenticate and access the server to get the public part out and so on... This just feels wrong to me, given that we have stprov and run stprov anyway.
Now, having a WireGuard key was my first thought, because I know I will need it. Not in the least because I eventually expect to not even run sshd on my stbooted server. Other users, myself included, may want other types of secrets, or a number of WireGuard keys, or other things. I don't know now what they are. But maybe allowing for derivation of a handful -- or simply n
-- WG keys would be a good start.
I have not really thought about how this should work, but perhaps additional stprov command for each additional secret type, or argument saying how many secrets of each type user wants.