From nuncestbibendum at excite.com  Tue Aug 24 17:30:10 2021
From: nuncestbibendum at excite.com (Full Name)
Date: Tue, 24 Aug 2021 13:30:10 -0400
Subject: [Softhsm-develop] The lifespan of a private key identifier
Message-ID: <20210824133010.22232@web002.roc2.bluetie.com>

     GnuTLS exposes a number of PKCS #11- related APIs for generating key pairs - e.g. gnutls_pkcs11_privkey_generate3. When this function is invoked successfully against SoftHSM, it returns an identifier (a CKA_ID) that uniquely identifies the key object that has just been generated. This can be used later on in order to get SoftHSM to carry out cryptographic operations with the corresponding key - in essence, if I understand things correctly, this identifier is used by SoftHSM in order to find a private key blob that SoftHSM saved to the filesystem in the host computer when the key was generated by invoking gnutls_pkcs11_priveky_generate3.

     My question is, what is the lifespan of this identifier? My guess is that, as long as the matching keyblob is present in the filesystem, SoftHSM will be able to load that keyblob unambiguously when the identifier above is used for this purpose. Is this correct?

     

From rick at openfortress.nl  Tue Aug 24 18:20:51 2021
From: rick at openfortress.nl (Rick van Rein)
Date: Tue, 24 Aug 2021 18:20:51 +0000
Subject: [Softhsm-develop] The lifespan of a private key identifier
In-Reply-To: <20210824133010.22232@web002.roc2.bluetie.com>
References: <20210824133010.22232@web002.roc2.bluetie.com>
Message-ID: <20210824182051.GC7420@openfortress.nl>

Hello Full Name,

>      My question is, what is the lifespan of this identifier?

The authoritative source for this information is the PKCS #11
specification.  Read That Functional Manual :-)

You should never, Never, NEVER make assumptions about an
exchangeable API like PKCS #11 based on a mere implementation
such as SoftHSM2.  That only causes Bad Jynx.


Having said that, CKA_ID is only an identifier if it is set to a
unique value.  Also, it "identifies" both public and private keys
(and says/suggests they form a pair).  It is stored as an attribute
along with the others, and remains the same until it is changed.

I suppose this is another way to say that you should read the
PKCS #11 specification, namely to understand what the CKA_ID really
is and what properties you may assign to it.


Cheers,
 -Rick

From berry at nlnetlabs.nl  Tue Aug 24 19:56:34 2021
From: berry at nlnetlabs.nl (Berry van Halderen)
Date: Tue, 24 Aug 2021 21:56:34 +0200
Subject: [Softhsm-develop] The lifespan of a private key identifier
In-Reply-To: <20210824133010.22232@web002.roc2.bluetie.com>
References: <20210824133010.22232@web002.roc2.bluetie.com>
Message-ID: <9056e6c58b8eca4d0735a4744f788fec@nlnetlabs.nl>

>      My question is, what is the lifespan of this identifier? My guess
> is that, as long as the matching keyblob is present in the filesystem,
> SoftHSM will be able to load that keyblob unambiguously when the
> identifier above is used for this purpose. Is this correct?

Nope, it is not a unique identifier, so this is not necessary 
unambiguous.
It is up to the end-application to keep it unique and to distinguish
certificates/public/private keys with the same identifier.  It is also
not generated by (all) PKCS#11 implementations but must be set 
explicitly,
I assume for this reason.

The "lifespan" of this attribute is that once set, it remains stable
across sessions, so you may use it in another session or at later time
to look up the object.  This in contrast to the handle, which although
implemented as an integer, is not necessarily stable across sessions.

The main difference between CKA_LABEL and CKA_ID from my perspective is
the different values that are permissable, but their use case is
similar.  (Although labels are more meant for human consumption).

\Berry