|
On 04/09/2013 11:43 PM, Cohen, Doron
wrote:
+1
…. to correct the header per Tim’s proposal below.
The
use of CK_ULONG_PTR in is clearly a typo and, I can attest
that we already ship implementations where we treat it as
a CK_ULONG instead of CK_ULONG_PTR regardless of the typo.
While
I understand the issue is backwards compatibility, and that
other implementations follow the C header as is , I would
also claim that in reality implementers have already made
choices and there is significant inconsistency in the market
which causes interoperability issues regardless.
So,
since we are here with the goal of updating the spec , my
preference is that we SHOULD make it right and consistent
with the wording (and rest of the spec) in 2.40 .
Doron
The one issue is how much and who gets broken. A library* could
presumably, possibly detect that the value passed in the
CK_ULONG_PTR is really a CK_ULONG (assuming that input to a pbe is
likely to be small compared to a random memory address), but it's
not reliable (on some platforms the address could be passed in as
text).
There is a compatibility issue here. NSS has been using CK_ULONG_PTR
for quite some time, so pretty much every version of Firefox would
expect the value to be CK_ULONG_PTR, which means if your token
supports key import, any AES encoded PKCS #12 file could crash your
PKCS #11 module (and thus a browser) if you try to import it into
the token.
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
*I use library to mean "The code that talks to the PKCS #11 module".
Some use "application", but for me that masks the fact that
applications typically don't talk directly to PKCS #11 modules, but
to crypto libraries that talk directly to PKCS #11 modules.
I use the term "module" to mean the actual PKCS #11 DLL/so to
distinguish it from the crypto library that talks to it. I'm
wondering if we need to invent less confusing nominclature here to
distinguish the PCKS #11 caller from the PKCS #11 implementation.
bob
On 10/04/2013 7:36 AM, Michael StJohns
wrote:
I'd leave it as is. It's consistent in the
text and in the header files. If it needs to be changed,
then the proper way is to define a new structure and mechanism
and leave this one intact.
And I'm going to have to disagree here - in that the text
itself does not support the typographical error in the
structure definition.
It states:
ulPasswordLen length in bytes of the password
information
All the other references to CK_ULONG_PTR have a clear
description along these lines:
pulOutputLen pointer to the length in bytes
that the output to be created shall have, has to hold the
desired length as input and will receive the calculated length
as output
That the prose did not state "pointer to" means that it
is not documented as being a pointer reference.
And yes I do realise that there are other references to
pointer types which don't start with pointer in their
description (and they should) but there are only three
CK_ULONG_PTR references in mechanism parameters - and the
other two explicitly state "pointer to".
Those descriptions that don't state pointer to that are
actually pointers should be updated IMHO - the vast majority
of items in the specification explicitly state pointer to -
but there are some exceptions.
It's unfortunate that no one has raised this before as clearly
vendors have noticed it and made a choice (one way or the
other).
Leaving this little mess alone and not fixing it wouldn't be
my preference - this like this which are clearly being
interpreted differently by vendors should be fixed and now is
the right time to fix it before we cement this in an OASIS
specification.
Tim.
The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.
|