On Wed, 2016-12-14 at 17:05 +0000, David Woodhouse wrote: > 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.
Sure (as in I thought that went without saying).
> 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.
Yes ... I was mostly reacting against your statement that the keys
needed to be inside the TPM for PKCS11 use.
> 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.
OK, so as long as you're happy with pkcs11 being used on TPM key files
which are then loaded as needed via the pkcs11 interface, I think we're
on the same page. I'm coming to the conclusion that we need the files
in pairs and the public key can supply the attributes ... it's more or
less how gnome keyring currently does it.
> 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.
OK, so a token can be writeable as well, but I expect the object to be
loaded into the token to be correctly serialised according to the
protocol and also possibly wrapped.
> > 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.
Section 4.8 in the current OASIS base spec:
The CKA_ID field is intended to distinguish among multiple keys. In
the case of public and private keys, this field assists in handling
multiple keys held by the same subject; the key identifier for a
public key and its corresponding private key should be the same. The
key identifier should also be the same as for the corresponding
certificate, if one exists.
In practice it seems that most things use CKA_ID and CKA_LABEL if they
both exist.
> > 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?
Yes, I can do it, but the TPM private keys are going to have to inherit
the certificate CKA_ID, which is usually something like the subject ...
they can't be the uuid.
> 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.
I'm starting to think keys permanently loaded into the TPM aren't the
right way to go ... the wrapped format is secure and much more
flexible. The only advantage a loaded key has over a wrapped one is
that you don't need the parent authority and the key authority to use
it.
James
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
