Re: [pkcs11] C_ChangeLabel/C_ClearToken

[Michael StJohns <msj@nthpermutation.com>]

On 6/7/2013 3:46 PM, Tim Hudson wrote:
> My initial thoughts from reading that stream of information is that you
> really want to just have an C_UpdateTokenInfo/C_SetTokenInfo call that
> takes the CK_SLOT_ID and current CK_TOKEN_INFO and applies whatever
> modifications the token supports to that information which may be none,
> just the label, or whatever else is allowed to be changed by the
> implementation. The same could be applied to the slot details with a
> C_UpdateSlotInfo/C_SetSlotInfo - for exactly the same reasons as wanting
> to update that information without having to re-setup slots for those
> devices where slots are dynamic (and created via an API call).

Before you spend more time on this particular idea, please actually 
consider what's in CK_TOKEN_INFO and what of that you might actually 
want to update.


typedef struct CK_TOKEN_INFO {
CK_UTF8CHAR label[32];
CK_UTF8CHAR manufacturerID[32];
CK_UTF8CHAR model[16];
CK_CHAR serialNumber[16];
CK_FLAGS flags;
CK_ULONG ulMaxSessionCount;
CK_ULONG ulSessionCount;
CK_ULONG ulMaxRwSessionCount;
CK_ULONG ulRwSessionCount;
CK_ULONG ulMaxPinLen;
CK_ULONG ulMinPinLen;
CK_ULONG ulTotalPublicMemory;
CK_ULONG ulFreePublicMemory;
CK_ULONG ulTotalPrivateMemory;
CK_ULONG ulFreePrivateMemory;
CK_VERSION hardwareVersion;
CK_VERSION firmwareVersion;
CK_CHAR utcTime[16];
} CK_TOKEN_INFO;

Of all of these, the only two items that I can see wanting to update 
through PKCS11 (e.g. not through a native token configuration program, 
or by the token manufacturer at manufacturing time) are label and 
utcTime.  Pretty much every other item on this structure is  (and SHOULD 
BE) read-only, and immutable even if the token isn't initialized.  Other 
items vary based on what's on the token (*Memory fields) and you 
definitely wouldn't want to be able to set them.

So assuming I'm correct that the rest of the fields shouldn't be user 
settable, the utcTime field underlying clock is already capable of being 
set via the clock hardware object.  It seems sensible to use that same 
general approach to set the label on the token rather than adding a new 
special purpose command and a new structure to cover just that value.

And continuing on, there is a difference between SLOTs and TOKENs. And 
each has its own C_Get(Slot|Token)Info call.  So doing a 
C_UpdateSlotInfo call would seem to want to update CK_SLOT_INFO rather 
than CK_TOKEN_INFO.  Assuming you really meant CK_SLOT_INFO - here's 
that structure.

typedef struct CK_SLOT_INFO {
CK_UTF8CHAR slotDescription[64];
CK_UTF8CHAR manufacturerID[32];
CK_FLAGS flags;
CK_VERSION hardwareVersion;
CK_VERSION firmwareVersion;
} CK_SLOT_INFO;

But again - why would you want to update any of these fields?  All of 
the fields in this structure are derived from the slot vendor (e.g. 
smart card reader manufacturer, or HSM manufacturer for virtual slots 
associated with big iron type tokens) provided information - e.g. serial 
number for the HSM, or from the driver - e.g. "HSM Vendor <vendor name> 
Device 1 Slot 0".

I really can't think of any reason why any information in this structure 
should be anything but read-only.

Mike