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

[Michael StJohns <msj@nthpermutation.com>]

Fix attached.

Mike


On 4/12/2013 8:27 PM, Dennis E. Hamilton wrote:
> 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
>
> [ … ]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Attachment: pkcs11-pbkd2-fix.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document