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

Comments below. Editing out things I'm not responding to...

On 6/7/2013 3:27 PM, Dina Kurktchi wrote:

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.

I think that's correct. And that's in line with other things that are currently defined as hardware objects. The persistence is something you'd define as part of the object description writeup - I'd say it's persistent from initialization to zeroization.

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.

Yup - again, part of the object description write up. This object is implicitly CKA_PUBLIC = true. I'd basically suggest it has the same use requirements as C_GetTokenInfo since the data is accessible there. (And note that if you have a clock on the token as a hardware object, that value is also accessible through the C_GetTokenInfo call).

Given that the clock is already exposed this way, you might as well expose the label the same way.

    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.

Yup. And its also possible to specify a string consisting of all blanks in the C_InitToken. I think that the object description has to say what the format of the value of the object is. I don't think there's any real problem with using CKA_LABEL. CKA_LABEL is defined as an RFC 2279 string. RFC 2279 says that's an UTF8 string. And the both the C_InitToken and C_GetTokenInfo use a fixed length UTF8 string.

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_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.

I'm not sure I understand why CKA_LABEL is abhorrent to you. I don't really care what attribute you use as long as it can represent a string of up to 32 UTF8 characters and it seems that CKA_LABEL can do just that. With respect to the above - you almost re-invented the CKA_GLOBAL stuff we've been discussing. (substitute CKA_OBJECT_IDENTIFIER for CKA_LABEL, and substitute CKA_GLOBAL for the combination of CKO_HW_FEATURE and CKH_TOKEN something and you're pretty close.) I considered using CKO_HW_FEATURE for that purpose, but I was looking for something more general that what you're looking for.

    The HW object would be created at C_InitToken() time, right?

Actually, it would always exist - it just will have the empty value if the token hasn't been initialized. I think that's in keeping with the current label info model.

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()?

The general contract for hardware objects is that you neither create nor destroy them. Try deleting the clock object for example, or one of a set of monotonic counters. In this case, this is just an access method to do a set/get of a permanent data field already associated with the token. It's meta data/meta object stuff, and bears no resemblance at all to the general key/cert/data object model.

    - 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.

There isn't any interface to do that - at least none that I know of. When you call C_GetTokenInfo you pass in a pointer to a CK_TOKEN_INFO structure in your user space. Twiddling with that structure does NOT allow you to twiddle with the token name stored on the token.

    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.

I don't quite get your point here. The C_GetTokenInfo interface is a read-only interface, and you really don't need to be able to change most of the items in the CK_TOKEN_INFO structure. In fact time and label are about it. We already have a definition of a hardware object to allow access to change the time (and incidentally, read it). You want to add a way to change the label, it seems to be using a similar model makes sense.

    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

Wait one. You can already get the token info via C_GetTokenInfo - we're only talking about one tiny piece of that.

would the common storage attributes be set, I wonder:

Just one of these to cover the label.  I still think it should be CKA_LABEL.

    CKA_TOKEN = true

This is actually implied by CKO_HW_FEATURE.

    CKA_PRIVATE = false

You can add this as an attribute, but since this is not a variable attribute (the data is ALWAYS public regardless of implementation), you don't actually need to include it. It's implied by the definition of the object.

        true for CKH_TOKEN_LABEL, but ??? for CKH_TOKEN_INFO

CKA_MODIFIABLE = true/false depending on whether or not you've met the access requirements (e.g. logged in as an SO, logged in as a user) or not.

    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.

I'm sure it isn't. Use the existing mechanism of C_GetTokenInfo. The rest of that data is not settable.

    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.

You really, really, really can't actually do that. There is no "C_SetTokenInfo" command.



To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:

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