Progress on MS extension support

[Firstyear]

Add support for MS OAPXBC key management in the soft-tpm, with a view to have this work with HW TPM's.

Relates kanidm/hsm-crypto#30

• [ x ] cargo fmt has been run
• [ x ] cargo test has been run and passes
• [ x ] documentation has been updated with relevant examples (if relevant)

[dmulder]

Hrm, maybe I can make things work using msoapxbc_rsa_key_import()?
I guess I need to understand your vision here. How would you expect someone to use the msextensions features of compact_jwt without the hsm-crypto features? How would I use compact_jwt without the TPM/soft hsm?

[Firstyear]

Hrm, maybe I can make things work using msoapxbc_rsa_key_import()? I guess I need to understand your vision here. How would you expect someone to use the msextensions features of compact_jwt without the hsm-crypto features? How would I use compact_jwt without the TPM/soft hsm?

My thinking here is that we want to model our implementation around the TPM as the key storage mechanism. That's why to me I wanted to create this such that you have to use the TPM to protect the key.

Put the other way, is there a reason someone would want to use this feature without their machine identity keys being in a TPM? Part of the thinking about this is to "raise the bar" as well - we want users of this library to be doing the right thing, so why should we let them use keys without protecting those keys appropriately? There is a bigger block of work in parallel to this to have everything cryptographic in kanidm and related libraries be protected in a TPM or HSM.

Initially I think we will be the only user, and our interfaces (inside the kani unixd framework) all rely on the tpm and provide it, so we can always rely on it being there. For testing and users without a HW TPM, the softtpm interface exists to fill that gap. And if we need it, we can always use the rsa key import feature that I added to the softtpm for tests.

[Firstyear]

PS: This isn't saying I'm hard-against adding it back. I just think we should have a good reason to add it back because there are risks entailed and I do like to "bring up" the quality standard of all our users around us. :)

[dmulder]

PS: This isn't saying I'm hard-against adding it back. I just think we should have a good reason to add it back because there are risks entailed and I do like to "bring up" the quality standard of all our users around us. :)

Well, my only argument in favor of providing it without the TPM is that it's slightly easier for testing! I suppose that's not a very strong argument. Let's stick with TPM/soft hsm only.

[dmulder]

Well, I've integrated this in himmelblau (via my msal library), and all looks good! I did some basic testing, and all the fundamentals are working as expected (with me splitting the transport and certificate keys).

[Firstyear]

@dmulder Sounds good. I'll do some more on this today then, I wanted your feedback first before I kept going deeper into this :)

Did you want me to add the bcrypt format export to hsm-crypto too here then?

[dmulder]

Did you want me to add the bcrypt format export to hsm-crypto too here then?

I don't think it matters. Up to you.

[Firstyear]

for now I think we leave it as is then,