On Thu, Sep 12, 2024 at 05:19:15PM +0300, Jarkko Sakkinen wrote: > I try to understand these in detail because I rebase later on my TPM2 > ECDSA patches (series last updated in April) on top of this. I'll hold > with that for the sake of less possible conflicts with this larger > series. > > Many of the questions rised during the Spring about akcipher so now is > my chance to fill the dots by asking them here. I assume you're referring to: https://lore.kernel.org/all/20240528210823.28798-1-jarkko@xxxxxxxxxx/ Help me understand this: Once you import a private key to a TPM, can you get it out again? Can you generate private keys on the TPM which cannot be retrieved? It would be good if the cover letter or one of the commits in your series explained this. Some of the commit messages are overly terse and consist of just two or three bullet points. The reason I'm asking is, there are security chips such as ATECC508A which allow generating private ECDSA keys on the chip that cannot be retrieved. One can send a message digest to the chip and get a signature back. One can also use the chip for signature verification, but that's less interesting because it's attached via i2c, which is usually slower than verifying on the CPU: https://cdn.sparkfun.com/assets/learn_tutorials/1/0/0/3/Microchip_ATECC508A_Datasheet.pdf If TPMs support unretrievable, maybe even on-device created private keys, they would offer comparable functionality to the ATECC508A and that would suggest adding an asymmetric_key_subtype which uses some kind of abstraction that works for both kinds of devices. I note there are ASN.1 modules in your series. Please provide a spec reference in the .asn1 file so that one knows where it's originating from. If it's originating from an RFC, please add an SPDX identifier as in commit 201c0da4d029. Thanks, Lukas
