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

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.


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:

Attachment: pkcs11-ckh-token-label.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document

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