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] Groups - Ballot reminder: "Proposal for changes to DSA mechanism"


On 12/09/2013 2:37 AM, Michael StJohns wrote:
> That document should not have gone to ballot and should not have been
> passed because of the group agreement on backwards compatibility, but
> was passed against the rules.  

You'd be more than a little incorrect there Mike. The group passes by
ballot whatever the group wants to pass by ballot. That is the OASIS
rule. The TC can vote to have additional standing rules in place but has
not done so. We have some items we have discussed as a group as
objectives/guidelines - but nothing formal in place. I suggest you
actually go and read the TC process rules as they are how all OASIS
technical committees operate.

I noted explicitly that I thought the backwards compatibility issue
should be addressed but still voted for the proposal as-is (as did
others) because even without that addressed it made sense to progress
forward (in my view and that of others as well). That ballot passed.

This new proposal was meant to address that specific item and to update
references to FIPS184-6 [not FIPS186-4 as in your email].
It goes beyond that. It is certainly not what it was presented as doing.

The ballot was not formed as a complete "replacement" - that is not what
the motion was or the ballot text - it was meant to address only those
items previously raised.

On the size issue - FIPS184 has always had specific values listed and
not a range - and the range has always been in PKCS#11 as an API
allowing for a full range of usage and not just the specific limits
noted in FIPS184 - conformance to the various FIPS requirements is
something done over and above what is in PKCS#11 - we haven't wired in
those limitations previously (in this area) nor do I think we should
start doing that now, especially in a proposal which was meant to be
addressing references and a SUBPRIME backwards compatibility issue.

If you want to make a change like this is should be brought before the
group and discussed and noted explicitly - not placed in a proposal as
yet another "fix" - I doubt anyone was expecting that sort of change to
go in.

We also did discussed leaving out the manifest constant values and just
placing in markers for the editor to allocate values - but this isn't
what you did - you for some reason I simply don't follow (at the moment)
included some list which is incorrect. I took the effort of actually
looking at the list and comparing it. It is incomplete and incorrect in
quite a few places.  It is not a matter of the editor allocating some
values - it is a matter of the editors needing to completely ignore it.
That's a different topic.

Tim.



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