Re: [pkcs11] C_ChangeLabel/C_ClearToken

[Michael StJohns <msj@nthpermutation.com>]

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

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