OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [pkcs11] C_ChangeLabel/C_ClearToken

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];

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;

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]