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

[Robert Relyea <rrelyea@redhat.com>]

On 04/11/2013 02:27 PM, Tim Hudson wrote:
> On 12/04/2013 7:04 AM, Michael StJohns wrote:
> > On 4/11/2013 4:47 PM, Tim Hudson wrote:
> > > 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.
> > And you're missing the point that on my laptop I have header files
> > from at least three different vendors including the PKCS11 from Java
> > that have the values as they currently exist in the 2.20 header
> > files.  You're saying - just fix the header file and the text so its a
> > CK_ULONG.
> And I've got three vendors who have changed it and two who have just
> placed a long and not used it as a pointer on one test configuration here.
>
> It's a mess. It needs fixing. Multiple vendors have indicated they
> corrected the clear mistake in the header files - leaving it alone is
> basically not a sensible option.

So I agree it's a mess. I agree that it was a typo. But I also know if 
we "fix" the typo and keep the same mechanism number, I am completely 
hosed. I have both a library and a module. Because of FIPS they don't 
get updates in sync. I have binary compatibility requirements to 
maintain. I'm not allow to have modules that work with my code today 
suddenly start crashing. Anyone who implemented this could not help but 
notice that it was a typo, but because it was a typo and consistent in 
both the header and the spec, we felt we had to follow the spec not 
matter how weird it seemed.

Now fast forward. We all agree it was a typo, but now have running code 
that depends on that type. I can't just change the header because it 
affects what happens in my binaries. I can't break modules that are 
already working today to fix modules that are crashing. Even worse, I 
can't always update my own PKCS #11 module on some of my platforms 
because of FIPS, so if I change my library, I will now crash on those 
platforms against my own PKCS #11 module. Obviously that can't happen.

I'm sure I'm not the only one in this position. Switching the spec so 
that it's clearly a pointer to the length (by changing the variable 
name) doesn't help because someone else is in exactly my same boat, only 
the depend on different behavior.

The only way forward is to abandon this mechanism number and we all go 
to a new mechanism that has the fixed typo. My library can then try the 
new mechanism first, and then fall back to the old one (which the way we 
interpreted the old mechanism). Now my updates don't need to be sync'd. 
I don't break old modules that did work with me before, but I have a 
prayer of getting all the new modules to work with me. No new crashes, 
the end game is something that we are all happily interoperating.

The spec updates are:

new mechanism (I'd also prefer a new name for the mechanism and 
structure, but that's not quite as critical as I can work around this). 
The old one is deprecated. You don't make a new implementation of the 
old mechanism. The documentation may actually simply say 'This mechanism 
is deprecated. In the field different implementations have different 
interpretations of the meanings of the parameters, so use of this 
mechanism is unreliable.' and nothing else.

bob
> Anyone currently using that mechanism is non-interoperable.


> I'm saying in PKCS11 v2.30 we can fix this - it is a new version - and
> we have not as a committee elected to make no changes and to require
> completely binary compatibility with previous (non-OASIS) versions.
>
> Tim.
>
>
>
> ---------------------------------------------------------------------
> 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: smime.p7s
Description: S/MIME Cryptographic Signature