20231101 kanidm integration

[Firstyear]

WIP for the changes needed to integrate this to Kanidm's Unix Integration.

I'm not 100% sure about this. It feels "messy". I was trying to use the HSM trait for dynamic dispatch so that the Kani unix resolver didn't have to care about the type of hsm that was in use. But the issue there is we then need Box<dyn Hsm<MachineKey = Type, LoadableMachineKey = Type, ....>>. Effectively we end up in a really awkward spot if we use associated types.

This changes to use enums for runtime dynamic dispatch - currently I half-baked it, wrapping the types, but I feel we just probably need to flatten to one giant "MachineKey" enum and each HSM type pattern matches over it. Currently it's

#[derive(Debug, Clone, Serialize, Deserialize)]
pub enum LoadableMachineKey {
    Soft(soft::SoftLoadableMachineKey),
    #[cfg(feature = "tpm")]
    Tpm(tpm::TpmLoadableMachineKey),
    #[cfg(not(feature = "tpm"))]
    Tpm(()),
}

Flattened would be

#[derive(Debug, Clone, Serialize, Deserialize)]
pub enum LoadableMachineKey {
    SoftAes256GcmV1 {
        key: Vec<u8>,
        tag: [u8; 16],
        iv: [u8; 16],
    },
    #[cfg(feature = "tpm")]
    TpmAes128CfbV1 {
        private: TpmPrivate,
        public: TpmPublic,
    },
    #[cfg(not(feature = "tpm"))]
    TpmAes128CfbV1 {
        invalid: ()
    }
}

Maybe the design here is flawed? Maybe there is a better structure? The goal was that the resolvers would just get a "dyn Hsm" and be able to interact with it, so they don't need to care where their keys are, and they trust we did the work for them.

I think to do this, maybe we just need to accept the enum's? Traits are making this too hard.

cc @micolous for some advice.

Checklist

• [ x ] This pr contains no AI generated code
• cargo fmt has been run
• cargo clippy has been run and there's no issues
• cargo test has been run and passes

[dmulder]

Like you said, I think you're maybe overthinking it a bit. The end result is either way, these implementation details are hidden from the end user. I think the current approach is fine.

[Firstyear]

Yeah. I kept going with this approach and tidied it up and I think I'm happy with it :) Thanks for the double check. I'll update this PR once I improve it more.

[Firstyear]

@dmulder This is good to go now. I renamed it from hsm to tpm mainly because some of these functions are tpm specific and hsm/pkcs11 is a little different.

[dmulder]

LGTM