Re: [pkcs11] C_ChangeLabel/C_ClearToken

[Dina Kurktchi <dina.kurktchi@oracle.com>]

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.