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

There's a vast - make that ocean vast - difference between being a vendor serializing/marking/tagging/setting firmware for a specific token, and the type of access allowed/enabled by PKCS11.

Yes, the vendor can twiddle to their hearts content to provide the contents of those fields. So what?

You may be talking about other token/slot meta info besides time and label - I can't actually tell. But for the current structures and the current set of data represented by those structures I don't think you've made even the beginning of a case where the other elements of those structures should be subject to user or SO twiddling. If you can target it at specific elements and describe the use case, it might be a bit more helpful than the general push back you seem to be making.

Later, Mike

On 6/9/2013 7:50 PM, Tim Hudson wrote:
On 10/06/2013 8:58 AM, Michael StJohns wrote:
I really can't think of any reason why any information in this
structure should be anything but read-only.
The context is simply one where these are dynamically created items
(slot and tokens).
At the moment all vendors who have dynamic devices have to use
vendor-specific methods.

In that context all of the fields (other than perhaps the Version
fields) are settable.

Whether or not a particular device manufacturer lets a field be
specified or provides a default is up to the manufacturer and the
behaviour there varies.

This is how virtualisation/multi-tennacy/partitioning are handled - and
that is very much in active use at the high-end of the market.
These are not items which are particularly relevant for a single token
in a single slot.

It may be that all of these are post v2.40 items - however supporting a
standard way of handling this area does need to be tackled and if we are
going to start allowing renaming of tokens then we are moving away from
the fixed one-time set up model.


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]