First, security specialist would probably rebel about providing the password or keys in clear. The best practice says do not reveal the keys/passwords but rather encrypt them with some other "transport" secret that would be known to the user or destination host and would protect the password/key while in transit.
OK, the transport from client to FreeIPA would, of course, be secure, but the key/token that is returned from the client is available in cleartext (perhaps just in memory, such as ssh-agent). And specifying a passphrase on the command line would be discouraged but possible -- prompting for it, if Kerberos tokens were not sufficient, would be preferable.
Our current plan is to focus on the storage and make sure we can address the use cases we need to address like keys for disk encryption, SSH etc. Serving them out is whole different story and I doubt it will be done soon. Design work in this area would hopefully start in the fall.
If there were some way to securely embed an arbitrary string in the user profile, that would go a long way to solving this problem. At least 4KB to cover a 2048 X.509 public key, but ideally 10 KB or more. To remove the ACL complexity, just having it accessible only by the user (token or password based fetch) would be suitable.
_______________________________________________ Freeipa-users mailing list Freeipafirstname.lastname@example.org https://www.redhat.com/mailman/listinfo/freeipa-users