[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_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.
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.
Yup.
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:
CKA_CLASS = CKO_HW_FEATURE
CKA_HW_FEATURE_TYPE =
{ CKH_TOKEN_LABEL | CKH_TOKEN_INFO | CKH_TOKEN_DATA }
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.
CKA_MODIFIABLE =
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.
Mike
Regards, D. ---------------------------------------------------------------------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:https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]