On Wed, 2016-12-14 at 06:58 -0800, James Bottomley wrote: > > Hm, this seems odd. If something is stored in a file then exposing it > > through PKCS#11 doesn't make sense at all. Do not attempt to use > > PKCS#11 for any file access. > > OK, so the horse has already left the stable on that one with TPM > enabling gnome-keyring for ssh keys because it exports *every* key over > pkcs11. Since it does, I thought I'd play about with it a bit to see > how it would work. The below is what I found out playing around.
I think we're talking about two different things. What I mean is that a given application shall never have to deal with files and PKCS#11 for a given single object. Like the nss-pem horridness, where we create an object whose CKA_LABEL is the filename, and we want the soft token to go and load that file. You seem to be talking about software-based PKCS#11 tokens which happen to use their *own* files behind the scenes, but all the *application* ever knows about is sane PKCS#11 operations. That is absolutely fine. There's plenty of examples of that — including SoftHSM, GNOME keyring, and NSS's softokn. And you'll note that none of those examples need extensions to the PKCS#8 format to store arbitrary PKCS#11 attributes such as CKA_LABEL, CKA_PRIVATE, CKA_APPLICATION or anything else. Because it's their own database and they can do what they like; they don't have to store it in a PKCS#8 or similar file. The example you give with GNOME keyring doing SSH keys is a *different* special case. There it's automatically discovering the files in a known location (~/.ssh/id_*) and has to infer what it can from them, but still it's only exposing them over PKCS#11 in a standard way. There's none of the horridness for 'here, load *this* file into the token', is there? You can do that with ssh-add perhaps, but that's mostly orthogonal to what we're talking about here. > So this is the actual problem: the TPM only stores private keys. The > public key thing (can be simple, cert or something more fancy) isn't > known to it. All pkcs11 searchers find the public key in the public > objects and then look for the private key by id and label (this is what > the standard recommends). Which part of the standard are you referring to? It isn't really that prescriptive about how you look things up, as far as I was aware. > The problem is that the label they use isn't > going to be the UUID, so we need the private key to be labelled by what > its public counterpart expects to use the TPM for arbitrary keys, like > certificate private keys (or even gpg or ssh private keys). The UUID > thing works for stuff that expects separate private and public key > descriptions, like gnutls and openssl, but not for anything that uses > the full pkcs11 protocol (like netscape). Right, you need a full software token for stuff like NSS. But didn't you already do that in GNOME keyring? It stores the CKO_CERTIFICATE objects just like it always did, and now it's capable of storing the actual private key of a CKO_PRIVATE object in TSS-wrapped form, but the other attributes are still stored in its database just as they always were? And we could make SofTHSM and NSS support the same things. None of *that* needs to touch on the PKCS#8 storage format at all. That is *only* relevant to the case where the application is given a *file* with the private key it's supposed to use, and there is no PKCS#11 in sight. All of the above is for *wrapped* keys, of course. Not keys stored persistently in the TPM. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
