Tim, 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 the case? Sincerely, Jonathan ---------------------------------- Jonathan Schulze-Hewett Information Security Corp.
schulze-hewett@infoseccorp.com Office: 708-445-1704 Mobile: 708-822-2926 On Aug 15, 2019, at 6:55 AM, Tim Hudson <
tjh@cryptsoft.com > wrote: 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. The official header files published at
http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/errata01/os/include/pkcs11-v2.40/ contain the valid definitions. Tim. On Thu, Aug 15, 2019 at 9:48 PM Jonathan Schulze-Hewett <
schulze-hewett@infoseccorp.com > wrote: Daniel,
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.
Sincerely,
Jonathan
----------------------------------
Jonathan Schulze-Hewett
Information Security Corp.
schulze-hewett@infoseccorp.com Office: 708-445-1704
Mobile: 708-822-2926
> On Aug 15, 2019, at 5:05 AM, Daniel Minder <
Daniel.Minder@utimaco.com > wrote:
>
> 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 incompatibility.
> 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 specification.
>
> Best,
> Daniel
>
> -----Original Message-----
> From:
pkcs11@lists.oasis-open.org <
pkcs11@lists.oasis-open.org > On Behalf Of Robert Relyea
> Sent: Mittwoch, 14. August 2019 20:08
> To: Jonathan Schulze-Hewett <
schulze-hewett@infoseccorp.com >; Michael Markowitz <
markowitz@infoseccorp.com >
> Cc:
dee.schur@oasis-open.org ;
tony.cox@cryptsoft.com ;
pkcs11@lists.oasis-open.org > Subject: [pkcs11] Re: CK_GCM_PARAMS Question
>
>> On 08/13/2019 12:56 PM, Jonathan Schulze-Hewett wrote:
>> Bob,
>> The CK_GCM_PARAMS structure defined at
>>
http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40 .
>> html
>> does not include the ulIvBits member.
>>
>> However, the pkcs11t.h files published at
>>
http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/errata01/csprd01/i >> nclude /pkcs11-v2.40/pkcs11t.h does include it.
>>
>> 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 as well.
>
> (I'm putting this on the mailing list so we don't lose it as an issue).
>
> bob
>>
>> Thanks,
>> Jonathan
>>
>> Jonathan Schulze-Hewett
>> Director of Development
>> Information Security Corp.
>> mailto:
schulze-hewett@infoseccorp.com >> 708-445-1704
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> 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 >
>
>
> ________________________________
>
> Utimaco IS GmbH
> Germanusstr. 4, D.52080 Aachen, Germany, Tel: +49-241-1696-0,
www.utimaco.com > Seat: Aachen Registergericht Aachen HRB 18922
> VAT ID No.: DE 815 496 496
> Managementboard: Stefan Auerbach (Chairman) CEO, Malte Pollmann CSO, Dr. Frank J. Nellissen CFO
>
> 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.
Attachment: smime.p7s Description: S/MIME cryptographic signature