Re: [pkcs11] C_ChangeLabel/C_ClearToken

[Tim Hudson <tjh@cryptsoft.com>]

On 12/06/2013 5:21 AM, Dina Kurktchi wrote:
> Respectfully, that approach may not be the right one for the
> collection of people in this group.  Silence may also mean
> "ain't got around it yet" or "nothing to add"; not disinterest.

I appreciate the response and recognise the sentiment Dina, but if there
is insufficient interest to even indicate off list or on list support
for a concept then frankly it will not make the cut for inclusion in
v2.40. Each proposal has to have sufficient support to make to to a
motion for a ballot, pass a ballot and generally have multiple vendors
interested in implementing it and making a statement of use.

The way OASIS technical committees work require support for proposals -
or simply put things do not move forward - a proposal with no support
simply does not get included no matter how nicely written up the
proposal actually is.

Generally you need at least three organisations who are interested for
something to make sense - and not simply two parties who have very
different views.

There is a lot of communication which occurs off list - but in order to
move things forward support has to be shown in the group itself. I know
quite a few folks are somewhat hesitant to speak up given the nature of
some of the responses which come back.

Personally I think we have a huge range of ideas built up over the last
decade of problems which PKCS11 does not (yet) tackle well; but I expect
that what makes it into the first OASIS release (v2.40) will be
relatively modest - that was my sense from the discussions at the face
to face and in the meetings.
That means the majority of the proposals floated to date are unlikely to
be included (where we haven't seen consensus amongst 3+ participants).
I could of course be completely wrong - but this is how things normally
work in an OASIS context.

Along those lines:
- if there is interest in an enumerate-all-attributes capability going
into v2.40 then speak up (MikeS and TimH have indicated an interest)
- is there interest in changing tokens after they have been set up (you
have indicated rename is at least important along with being able to
destroy all the objects on a token, MikeS has suggested modelling of the
HW handling, I've suggested going further allowing updates of everything
in CK_TOKEN_INFO, MikeS has indicated his views on that)
- is there interest in supporting dynamic creation of slots (e.g.
C_CreateSlot, C_DestroySlot)

I think if you want to add in renaming tokens and clearing tokens then
you want programmatic control over the life-cycle of a token and that
goes beyond what you have suggested - and should either be tackled in
that context or left alone (and tackled with handling slots as well as
tokens for the same reasons). If others agree or disagree who haven't
already expressed an opinion on the topic then they need to speak up.

Tim.