On 08/15/2019 06:00 AM, Tim Hudson
There is no disagreement whatsoever - and never has been.
The header files are the definitive source of truth - both
under RSA and under OASIS.
While I totally agree with you from an official spec perspective,
and agree that the nss and jss headers are not compliant with the
shipped headers, there is the practical consideration: Does anyone
else implement CKM_AES_GCM and do they work with NSS?
Longer term NSS will go to the 3.0 version of AES_GCM and only keep
the old version for legacy. If no one has made CKM_AES_GCM work with
NSS, I can switch NSS to use the real CK_GCM_PARAMS at the same time
I do the 3.0 conversion. If someone *has* implemented AES_GCM with
NSS, I think NSS would continue to use the definition in the spec,
and depend on correct implementations barfing on the data structure
being to small and fall back to the correct version.
There seems to be some disagreement about whether the
spec is authoritative or the headers. Perhaps the spec
should state that the headers take precedence if thatâs
If someone is using a non-official header file
then that issue is theirs to handle.
The published header files are the official
defined ones and any custom variations aren't
following the standard which creates
interoperability issues by definition.
Note that there were also a pile of modified
header files with various clashing mechanism
identifier values as well - those all have to also
be updated to match the official release.
NSS and Java (OpenJDK) both use a pkcs11t.h file
that is missing the ulIvBits field. So there is
already a incompatibility in the wild.
Information Security Corp.
> On Aug 15, 2019, at 5:05 AM, Daniel Minder
> Bob, all,
> This is actually the same issue as item 4 in
the "public review comments resolution log".
> Yes, it is an error and the reason is that
the ulIvBits field is not needed - only ulIvLen is
used. However, we cannot just remove the ulIvBits
field from the struct since this would create an
> Proposal: In the header file, we could add an
âunusedâ comment to the field and in the 3.1
standard we should add a note to the mechanisms
> -----Original Message-----
> From: email@example.com
On Behalf Of Robert Relyea
> Sent: Mittwoch, 14. August 2019 20:08
> To: Jonathan Schulze-Hewett <firstname.lastname@example.org>;
Michael Markowitz <email@example.com>
> Cc: firstname.lastname@example.org; email@example.com; firstname.lastname@example.org
> Subject: [pkcs11] Re: CK_GCM_PARAMS Question
>> On 08/13/2019 12:56 PM, Jonathan
>> The CK_GCM_PARAMS structure defined at
>> does not include the ulIvBits member.
>> However, the pkcs11t.h files published at
>> nclude /pkcs11-v2.40/pkcs11t.h does
>> I'm assuming, since the NSS source for
pkcs11t.h excludes it, that the
>> posted (and widely used it seems)
pkcs11t.h file is in error?
> Well there is clearly an error. The spec does
not define what ulIvBits means.
> The same discrepancy is in the 3.0 versions
> (I'm putting this on the mailing list so we
don't lose it as an issue).
>> Jonathan Schulze-Hewett
>> Director of Development
>> Information Security Corp.
> 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:
> Utimaco IS GmbH
> Germanusstr. 4, D.52080 Aachen, Germany, Tel:
> Seat: Aachen â Registergericht Aachen HRB
> VAT ID No.: DE 815 496 496
> Managementboard: Stefan Auerbach (Chairman)
CEO, Malte Pollmann CSO, Dr. Frank J. Nellissen
> This communication is confidential. If you
are not the intended recipient, any use,
interference with, disclosure or copying of this
material is unauthorised and prohibited. Please
inform us immediately and destroy the email.