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?
Kerberos mailing list Kerberos@mit.edu