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

Reply via email to