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.


> 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.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Reply via email to