pkcs11 — archive

[Tim Hudson]

On 12/04/2013 6:34 AM, Michael StJohns wrote: On 4/10/2013 1:53 PM, Burns, Robert wrote: I think that because we are on the precipice of publishing this as an OASIS standard, now would be a good time to take care of these issues and fix obvious flaws. This is a good ‘edge-condition’ by which we can justify to the user base that changes need to be made. Although it is a change, it should be manageable and improve the usability in the long run. Bob Let's make a no impact change. Define a new mechanism and mechanism param that fixes this. Leave the other one alone. Foot note the text to explain what we did. Deprecate the old one - say it will go away with PKCS11 3.0. It's about5 minutes work cut and paste. And that approach misses the point that we have a mess - the current mechanism as realised in actual implementation is non-interoperable from the point of view of the consumers of PKCS11. It needs to be fixed. Now is the time to fix it. We are making changes - this is v2.40 - not v2.30 or v2.20. It is not a no-impact change from the point of view of users - it is leaving the current impact (non-interoperable) in place - and the point of PKCS11 is to have interoperability. Tim.