RE: [pkcs11] fwd: CKM_PKCS5_PBKD2_PARAMS struct: password length

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

I concur on first principles.

For example, If PKCS#11 were already an OASIS standard, this could not be fixed with an Errata because it would break implementations.  

If it were fixed by a (necessarily) implementation-breaking change in a future version, and there was no reliable backward compatibility case, deprecating the unfortunate feature and introducing a newly-identified feature strikes me as the appropriate way forward.

 - Dennis

PS: When HTML-formatted messages are X.509-signed, there is no companion plaintext for those readers that are configured to read all mail in plaintext.  I strongly urge that X.509-signed messages sent to the PKCS#11 list be in plaintext.  The list server does manage to preserve the HTML message, but not in verifiable form of course, <https://lists.oasis-open.org/archives/pkcs11/201304/msg00065.html>.  
  It is fortunate that there are no digest subscriptions.  Digests generally make a mess of mixed plaintext and HTML messages.


From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Robert Relyea
Sent: Friday, April 12, 2013 13:47
To: pkcs11@lists.oasis-open.org
Subject: Re: [pkcs11] fwd: CKM_PKCS5_PBKD2_PARAMS struct: password length

[ … ]

I'm personally coming to the conclusion we need to deprecate this mechanism number and make a new one that fixes this typo. The reason was some modules/libraries followed that the spec meant while others followed what the spec said. This allows library/module pairs that used to work together to continue to work, while all new libraries module pairs will work properly, and spreads the compatibility issues evenly.

Upshot:

1) define a new mechanism number, which takes the correct data structure.
2) mark the old one a depricated. If a library/module has already implemented this mechanism, that library or module should continue to use the understanding it already has. New libraries and modules should not implement the old mechanism.

I think this preserves the best case for interoperability (old module/library pairs that worked together continue to work together, old ones that conflict will continue to conflict. Updated versions of all the libraries and modules [including the previously conflicting ones will continue to work together])

As both a library implementer and a module implementer I know how I can move forward without breaking my world if the library or module gets updated out of sync (which happens regularly, and sometimes by design in NSS).

bob

[ … ]