Subject: Re: [pkcs11] C_ChangeLabel/C_ClearToken
On 10/06/2013 11:25 AM, Michael StJohns wrote: > 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. If we are going to make changes in an area to PKCS11 then we need to consider what vendors have actually seen sufficient need in the market over the last decade to add as extensions. That's a point I've been making repeatedly - to actually look at what has been done to determine which areas need to be addressed. There are very different views on PKCS11 depending on where you've been using it and for what purposes as to the priorities that should be tackled. For some vendors slots and tokens are entirely dynamic and under user (SO) programmatic control and there are a range of extensions for how those vendors (and they happen to be the major HSM vendors in the market) handle such concepts. There is no standard approach. It would be good to see a standard approach in place. I'm not talking about serializing/marking/tagging/setting firmware - just about dynamic slots and tokens. What I'm suggesting is if we are going to make any changes in the v2.40 time frame then we need to consider that context and not just add fields item at a time modelled of the HW clock approach (an approach which in my observation has limited actual support in products). I'm not sending out detailed proposals as frankly without a level of active interest amongst the group to tackling these areas (which can be determined from a email exchanges to see who sees a particular area as worth looking at) producing proposals is not a productive use of all our time. If there is interest then the group of folks interested in that can work off-list to produce a proposal. If there is no interest then it simply doesn't move forward. That you yourself don't see the need for this does not mean that others do not - I suggest you (like I am) wait to see if others express an interest. If not then this simply remains a vendor-specific area which we all have to deal with separately when interacting with the devices from vendors which have these interfaces. Tim.