Hi, I've looked into the mechanism for configurable crypto backends and in particular the NSS backend, which is close to PKCS #11.
What I like about PKCS #11 is that it can conceal keys from the libkrb5 library, and thereby from the application's reachable memory. This is not how the NSS crypto backend is made, I found -- keys are imported into NSS as (session) keys and used there. If FIPS is enforced, it will fake its patterns by unwrapping a key that was wrapped just for that sake. This seems to me like a missed opportunity. Am I mad to think that a crypto backend could choose any krb5_keydata representation, and that a pkcs11: URI [RFC7512] would be fine? It looks like the surrounding libkrb5 treats the keys as literals and always invoke krb5_k_decrypt() and _encrypt() after expanding the key to an opaque krb5_key after krb5_k_create_key() and before krb5_k_free_key(), right? This does seem to be possible -- but how do others feel about this? Cheers, -Rick ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos