OASIS PKCS 11 TC

Point of order I think? I went back and reviewed the bidding on this proposal - it's current 5/2/1. But almost all of the yes votes are "contingent" on fixing a bunch of stuff. My understanding of the process is that typo's and such can be fixed, but that substantive changes are pretty much forbidden. As I read the proposal, (and in fact even a few of the comments with Yes votes seem to read this way) there are substantive changes needed not just editorial. I'm particularly nervous about backwards compatibility - specifically CKA_SUBPRIME_BITS is now (per the document and per Relyea's comment) a required attribute for parameter generation. It wasn't a required attribute for parameter generation for 2.20 or 2.30 (and I'm not even sure it was a permitted item). That means that a current application that currently works generating DSA parameters is going to get an error if it attempts to generate against a 2.40 HSM. AFAIK we're trying not to do backwards incompatible changes in this go around. I'd really like to ask those who have voted yes or planning on voting yes to consider this point specifically as I don't think it can be fixed as an editorial change. Mike

On 08/ 6/13 11:20 AM, Michael StJohns wrote: Point of order I think? I went back and reviewed the bidding on this proposal - it's current 5/2/1. But almost all of the yes votes are "contingent" on fixing a bunch of stuff. My understanding of the process is that typo's and such can be fixed, but that substantive changes are pretty much forbidden. Hi MIke - That wasn't entirely clear to me when I first joined, but, yes, I believe only small editorial things can be requested as changes (like typos) Other things cannot be changed. As I read the proposal, (and in fact even a few of the comments with Yes votes seem to read this way) there are substantive changes needed not just editorial. I'm particularly nervous about backwards compatibility - specifically CKA_SUBPRIME_BITS is now (per the document and per Relyea's comment) a required attribute for parameter generation. It wasn't a required attribute for parameter generation for 2.20 or 2.30 (and I'm not even sure it was a permitted item). That means that a current application that currently works generating DSA parameters is going to get an error if it attempts to generate against a 2.40 HSM. AFAIK we're trying not to do backwards incompatible changes in this go around. That's correct, changes should be backwards compatible in a dot revision. That was what we agreed to. I'd really like to ask those who have voted yes or planning on voting yes to consider this point specifically as I don't think it can be fixed as an editorial change. Mike makes a good point - please remember this when voting: you cannot ask for substantive changes in a real ballot (straw polls where ideas are being floated around are different). You can vote "Yes, but please fix this typo", but not "Yes, but only if you change this behaviour". If you don't like the item AS WRITTEN, vote no for the item (your no vote may include comments that could be taken into consideration for a future proposal - though we are short on time for such things). If you just aren't sure, you can vote "abstain". There's a lot of emails going around right now, but discussions should happen on the list before an item is taken to a ballot. thank you, Valerie -- Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva Solaris Cryptographic & Key Management Technologies, Manager Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054.