[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11-comment] PKCS#11 v2.40 issues
Hi Jaroslav - Responses in line. On 5/17/2015 2:33 PM, Jaroslav Imrich wrote:
Hello all, it's been a month since OASIS PKCS#11 TC released PKCS#11 v2.40 as an OASIS standard without the C header files [0]. Previously when I was asking TC to
Those are a work in progress, we are aware that people are anxiously awaiting our header files. We did not expect such demand immediately upon release, but we have been in process of addressing this and will continue to move forward in this area as quickly as possible.
provide headers Robert Griffin said that "...header files will be illustrative, based on the normative definitions of constants in the appendices to the Base Specification and Mechanisms specifications." [1]. Following this philosophy I took the latest stable headers (v2.20a3) and manually added new items from pkcs11-base-v2.40-os, pkcs11-curr-v2.40-os and pkcs11-hist-v2.40-os documents. In order to keep the process transparent I have created github repository which allows anyone to easily review my changes [2]. During this process I have gone through v2.40-os documents more then once and discovered several issues in them. I consider some of them to be a major issues because they prevented me from completing the headers. I have marked all the issues in my headers with "TODO_v2.40" string and I am also attaching their description later in this e-mail. BTW I was really surprised when about an hour ago I have found a page called "PKCS#11 Definitions" [3] on PKCS11 TC Wiki which describes most of the issues I have encountered (maybe even all of them). Looking at the page history [4] I can see that most of the issues were documented by Stef Walter when v2.40 was still in the draft stage and I am failing to understand why did TC proceed with the standardization process without fixing them. I would be grateful if someone with more insight into the TC activities could shed some light into this.
As a committee, we decided to still move forward as the process of moving documents from proposals into finished standards is quite long. There are many phases of being "draft" that are actually quite complete. We did not want to restart the process based on this.
We had discussed doing in a rattle document, based on our previous committee experience when the standard was under the tutelage of RSA Inc., but discovered that we would have to run such a document through the full Oasis process.
The committee decided then to move forward with version 2.41, which will be mostly a "bug fix" version of the standard. We are already beginning to review proposals for changes to that new standard.
We are working on two versions of the header files. One that is essentially generated based on what is in the standard itself, including errors, and one that addresses the errors. The work from this will also go into improving version 2.41.
Thank you so much for providing your list of errors, I will make sure that the person working on the latest version of the header files has this content in addition to Stef's content.
[0] https://lists.oasis-open.org/archives/pkcs11-comment/201504/msg00004.html [1] https://lists.oasis-open.org/archives/pkcs11-comment/201410/msg00003.html [2] https://github.com/jariq/PKCS11-2.40-HEADERS/commit/850c9666c198a7a68d34f235f2a9f50136992e26 [3] https://wiki.oasis-open.org/pkcs11/Definitions [4] https://wiki.oasis-open.org/pkcs11/Definitions?action=info OK so here is the list of issues I am facing right now. BTW does TC already maintain official errata for PKCS#11 v2.40 as mentioned in chapter 1 of [pkcs11-base-v2.40-os]? I cannot find it.
As noted, there doesn't seem to be a good way to do this with oasis process. If we are missing something, we will be happy to look into it. Our first idea was to just store this on the wiki, and use that as content to fix in the next version of the standard.
MAJOR ISSUE #1 These key types are mentioned in [pkcs11-curr-v2.40-os] but there are no values defined for them: - CKK_SEED - CKK_GOSTR3410 - CKK_GOSTR3411 - CKK_GOST28147 MAJOR ISSUE #2 These mechanisms are mentioned in [pkcs11-curr-v2.40-os] but there are no values defined for them: - CKM_DES3_CMAC_GENERAL - CKM_DES3_CMAC - CKM_SEED_KEY_GEN - CKM_SEED_ECB - CKM_SEED_CBC - CKM_SEED_MAC - CKM_SEED_MAC_GENERAL - CKM_SEED_CBC_PAD - CKM_SEED_ECB_ENCRYPT_DATA - CKM_SEED_CBC_ENCRYPT_DATA - CKM_AES_GMAC MAJOR ISSUE #3 These key derivation functions are mentioned in [pkcs11-curr-v2.40-os] but there are no values defined for them: - CKD_SHA224_KDF - CKD_SHA256_KDF - CKD_SHA384_KDF - CKD_SHA512_KDF - CKD_CPDIVERSIFY_KDF MAJOR ISSUE #4 There seems to be an incomplete definition of CK_SEED_CBC_ENCRYPT_DATA_PARAMS and CK_CBC_ENCRYPT_DATA_PARAMS structures present in chapter 2.40.1 of [pkcs11-curr-v2.40-os]. MINOR ISSUE #1 Constant CKR_COPY_PROHIBITED is defined in appendix B of [pkcs11-base-v2.40-os] but it is not mentioned in the text. Is this a leftover after v2.30 that was superseded by CKR_ACTION_PROHIBITED in v2.40? MINOR ISSUE #2 These structures were present in v2.20 headers but are missing in the text of v2.40 documents: - CK_ECDH2_DERIVE_PARAMS - it was present in the text of v2.11 chapter 12.4.4. - CK_TLS_PRF_PARAMS - it was present in v2.20 chapter 12.32.2. - CK_CAMELLIA_CTR_PARAMS - it was present in v2.20a3 chapter 3.4.3. What is the current status of these structures? Are they deprecated now? I believe they should be present in v2.40 headers to keep the backwards compatibility. MINOR ISSUE #3 Definition of CK_DSA_PARAMETER_GEN_PARAM structure is present in the text but CK_DSA_PARAMETER_GEN_PARAM_PTR is missing. Is this intended? MINOR ISSUE #4 Mechanism CKM_X9_42_DH_PKCS_PARAMETER_GEN defined in [pkcs11-curr-v2.40-os] uses the same value (0x00002002) as CKM_X9_42_DH_PARAMETER_GEN in older versions. Was the renaming intentional? I believe both definitions should be present in v2.40 headers to keep the backwards compatibility. MINOR ISSUE #5 Constant CK_OTP_FORMAT defined in [pkcs11-curr-v2.40-os] uses the same value (0x00000007) as CK_OTP_OUTPUT_FORMAT in older versions. Was the renaming intentional? I believe both definitions should be present in v2.40 headers to keep the backwards compatibility. Thanks for any feedback
I will work with the committee on getting more specific answers to your issues. Thank you, Valerie -- NOTE: Using voice recognition software, forgive typos/grammar mistakes! Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva Solaris Cryptographic & Key Management Technologies, Manager Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]