On Thu, 2024-09-12 at 17:27 +0200, Lukas Wunner wrote: > 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 is for implementing TPM2 bits of https://www.ietf.org/archive/id/draft-woodhouse-cert-best-practice-00.html The main use case is to protect signing key coming from outside CA infrastructure. > 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. I keep this in mind for the next version. Thanks! > > 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. OK this is good to know and I can address this as follows: 1. I explicitly state that the feature that in the scope of the patch set it supports the original use case (or at least how I understood David's specification). 2. It is probably then better make sure that the implementation does not set any possible roadblocks for the possible use cases you described. Also one thing I'm going to do in order to have better focus is to cut out RSA part because they don't have to be in the same patch set and it is way more important to have ECDSA. OFC I'll work on RSA right after that but I think this is the right order :-) > > Thanks, > > Lukas BR, Jarkko
