Conversation

Jarkko Sakkinen

working on RFC patch for TPM2 asymmetric keys (will use null seed encrypted session) for supporting x509: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/commit/?h=tpm2_key

https://datatracker.ietf.org/doc/draft-woodhouse-cert-best-practice/
1
0
0
weekend as a kind of freelancer (at least for some time) is the best time for own patches. on plus, you don't have to care anything but the solving problem itself... paid or unpaid i enjoy this ;-)
1
0
1

Jarkko Sakkinen

Edited 6 months ago
OK, now I have together ASN.1 parsing and new key subtype "tpm2_key_subtype", which is foundations for TPM2 asymmetric keys.

Only compile-tested ;-) This is now bare minimum to trial in QEMU. Lot's of dance relocating necessary bits of trusted keys code to the TPM driver (only ASN.1 parser at this point).
1
0
0
Also a bit unclear what is best bet for authentication but it is a non-concern for RFC.

One possible argument for just authentication value at most would be that LUKS2 already blesses with TPM2 policy and kernel communicates by using null seed derived key. Using policy adds robustness but is it worth of added complexity to have two layers of policy, I really don't know at this point.
1
0
0
So apparently (after searching) there is previous work https://patchwork.kernel.org/project/keyrings/cover/20200518172704.29608-1-prestwoj@gmail.com/. So I guess I just use some of it (and make it a separate patch with appropriate credits).
1
0
0

Jarkko Sakkinen

Edited 6 months ago
I emailed to James Prestwood if he wants to rebase just the ops part from his patch set. My patch does the reorg and defines parser and key type so that is exactly left so better to ask. I also was also wondering TPM2_RSA_Decrypt vs TPM2_Sign/TPM2_VerifySignature. The old patch set uses the former.

Depending on response I'll take that patch from him or refactor it myself.
0
0
0