[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11] C_ChangeLabel/C_ClearToken
Summarizing for the group the result of emails on this subject: 1. all discussion about (a) C_ClearToken() - destroys all destructible token objects (b) transactional control (c) convenience functions is deferred until after v2.40 is published. 2. C_RenameToken, nee' C_ChangeLabel, is still on the table, and to refresh memories, its purpose is change a token's name without destroying it or its contents (i.e. it is not C_InitToken()). [Note: I'm not attached to the name, just thought C_RenameToken was better, more specific, than C_ChangeLabel.] 3. addressing comments by M. StJohn below -- since he did throw out an implementation suggestion for C_RenameToken(), which I said I'd chew on. 4. my suggestion for C_RenameToken, will be sent in separate email. Now... as to M. StJohn's comments: Requoted here from him: ---snip--- I'd probably suggest doing this through a CKA_LABEL attribute on a "hardware" object that represents the token. Maybe something like CKA_CLASS = CKO_HW_FEATURE and CKA_HW_FEATURE_TYPE = CKH_TOKEN_LABEL or maybe more general CKH_TOKEN_DATA with a CKA_LABEL as one of the attributes. ... In some ways, renaming a token may be a bad idea from a security point of view. You may want to limit this to the CKU_SO login if you permit it at all. That, in the final analysis, may be the main reason for not pursuing the idea. ---snip--- Running with his idea a bit, writing 'out loud'.... The object with class CKO_HW_FEATURE and type CKH_TOKEN_LABEL would have to be a public token object. It needs to persist across sessions and device-removals. Authentication should not be required to read token names. I understand that the idea can extend to include all token info/data, but I'll stick to talking about the token name, mostly. I'm not sure I agree with using CKA_LABEL. It is one of the common storage attributes and can be possibly-empty description of the object. Maybe CKA_VALUE is better to use for the token name. In fact, an application may want to search for the HW object using a known, immutable label: CKA_CLASS=CKO_HW_FEATURE CKA_HW_FEATURE_TYPE=CKH_TOKEN_* CKA_LABEL="token-info" (immutable value for token name/data) CKA_VALUE=<put the token name here> The attribute used doesn't have to be CKA_VALUE; it can be any newly-created attribute such as CKA_TOKEN_NAME. As long as it's not CKA_LABEL. The HW object would be created at C_InitToken() time, right? It's a public token object, so what prevents me from opening a R/W public session on this token and ... - creating a second such HW object with C_CreateObject()? - making a dup with C_CopyObject()? - removing it with C_DestroyObject()? - altering values other token name with C_SetAttributeValue()? - with dups, which one will C_FindObjects find first? - having fun with switching labels around on multiple tokens? Many security concerns, though I think these issues open up needlessly DUE to the token name being made available as an object. I think we'd have fewer issues by simply modifying the token name in CK_TOKEN_INFO. We already have one interface C_GetTokenInfo() that returns the token name, among other things. Adding a HW object would add a second duplicative interface to get the same information using C_GetAttributeValue() and an object handle to the new HW object. I should point out the Clock HW feature (10.3.3) and the corresponding utcTime struct member in CK_TOKEN_INFO does set precedent for two ways to get the same info. Still, it may not sit well with some people, depending on how they feel about token Clocks. BTW, the clock value is modified using C_SetAttributeValue on the Clock HW object's CKA_VALUE, not the utcTime member in CK_TOKEN_INFO. Details about whether it can be modified, and by which user, are left device-dependent. If we did go the HW object route for token names, it may make sense to model it upon token Clocks. Back to the token name as a public HW object on the token. If all the token data were in one well-formed HW object, how would the common storage attributes be set, I wonder: CKA_CLASS = CKO_HW_FEATURE CKA_HW_FEATURE_TYPE = { CKH_TOKEN_LABEL | CKH_TOKEN_INFO | CKH_TOKEN_DATA } CKA_TOKEN = true CKA_PRIVATE = false CKA_MODIFIABLE = true for CKH_TOKEN_LABEL, but ??? for CKH_TOKEN_INFO CKA_LABEL = blank should be fine or some well-known string, as long as CKA_VALUE is used for the token name What would you set for CKA_MODIFIABLE if the HW object represented most/all of the info about the particular token? Not sure that putting most/all token info into the same HW object is good idea. Just curious, if anyone wanted to make the slot description configurable, how would that work? Couldn't be as HW object on a token. We still have all the multiple access and consistency problems for the token name HW object as we do for objects in general (9.4, 12.2). Making the token name available as a HW object could be done, but it seems a "heavy" approach. It feels simpler, less prone to issues, to modify the single field in the token info struct. Regards, D.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]