[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11] C_ChangeLabel/C_ClearToken
On 6/9/2013 10:03 PM, Tim Hudson wrote:
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.
And again - write up a proposal. I don't understand why you think this idea would be useful, and waving your hands in the air about it won't help any of us understand.
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).
It seems you want to have your cake and eat it too. The original request was for "change the label", I suggested a mechanism which was pretty simple, could work in the existing context and required probably minimal changes to the token side if implemented. You came back with "that approach is too limited, we need to consider other things" but without actually going into what other things we might need to consider.
For this proposal, it really doesn't matter whether or not anyone implements the clock setting mechanism - that's a red herring - it matters whether or not the mechanism specified (a virtual object of the CKA_HW_FEATURE_TYPE=CKH_TOKEN_LABEL) can solve the problem posed.
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.
See the attached. It took me less time to write that than it did to answer this email. It is a tangible proposal. It took about 5 minutes to adapt the existing clock text to this. We can talk to that. I'm pretty much done with other rat holes on this topic without more details.
To be blunt, it seems a bit disingenuous to push back on other proposals while declining to provide your own alternatives to those proposals with sufficient detail to be evaluated.
If you don't want to add a mechanism to set labels, say so. And then you're done - there's nothing more to say.
If you don't like the specific approach, then say so, explain why and provide an alternate approach in sufficient detail that the group can compare them side by side.
That you yourself don't see the need for this does not mean that others do not
I have no clue whether or not I see a need for this. What you've provided is massively insufficient to make any determination on that topic.
- 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. --------------------------------------------------------------------- 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