[openssl-dev] [RFC v2 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[David Woodhouse]

On Tue, 2016-12-13 at 16:49 -0800, James Bottomley wrote:
> 
> So the proposal is to have a TPM specific value for PrivateKeyAlgorithm
> (which would have to be proposed as an OID) and use PrivateKeyInfo for
> the key?  That could be made to work.

Right.

> The slight fly in the ointment that's worrying me is that I need a key
> format that works for pkcs#11 tokens as well.  The problem here is that
> TPM keys don't have an id or a label and that's pretty much a
> requirement of using a pkcs#11 token, so the pkcs#11 code has to be
> able to set these attributes on the key files.  I was originally
> thinking of putting them into the PEM header with a pkcs11- prefix.  I
> suppose I can do the same with the attributes and some manufactured OID
> prefix with the CKA_ parameters we're interested in as a suffix but
> it's messy.

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.

Seriously, if you have any doubts about that at all, go read nss-pem
and ponder its operation. Then drink until you've forgotten most of it,
but remember that PKCS#11 isn't to be used for accessing stuff that you
have in a file.

PKCS#11 can sanely be used for keys which are persistently stored *in*
the TPM storage, which *do* have a UUID which can be used as CKA_ID.
(Or maybe as CKA_LABEL since CKA_ID really SHOULD be the pubkey hash,
if we can manage that).

If you're talking about a PKCS#11 token which has its *own* storage of
wrapped keys, then sure — you can keep whatever metadata you like. But
you don't need that to be part of the PKCS#8 standard format. In fact
if you want this you're probably better off extending SoftHSM to stored
wrapped keys and use the TPM for operating them.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161214/1b516ceb/attachment-0001.bin>