OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Issues with SP 800 KDF in PKCS #11.




The guys working in our CS team has been trying to implement SP 800 KDF that we added to 3.0 and have found the following issues (with his suggested fixes). (Inline are my comments for them).

  1. PKCS#11 v3.0 Cryptographic Token Interface Current Mechanisms specification specifies a CK_SP800_108_COUNTER, while the pkcs11t.h from PKCS#11 v3.0 Cryptographic Token Interface Base Specification specifies CK_SP800_108_OPTIONAL_COUNTER.
    • I've provided both, making CK_SP800_108_COUNTER define to CK_SP800_108_OPTIONAL_COUNTER
I think we can handle this as a non-material change as recommended above.

  1. In both CK_SP800_108_KDF_PARAMS and CK_SP800_108_FEEDBACK_KDF_PARAMS, pAdditionalDerivedKeys is a single CK_DERIVED_KEY, when it should be a CK_DERIVED_KEY_PTR, since it is interpreted as an array of CK_DERIVED_KEYs. This appears in both the CTICM and pkcs11t.h.
    • I've fixed it in both places.
This is an issue. The text says it's an array, but the header and definition has the wrong type? Is this material or a typo?

  1. PKCS#11 v3.0 Cryptographic Token Interface Current Mechanisms specification specifies CK_SP800_108_DKM_LENGTH_SUM_OF_KEYS and CK_SP800_108_DKM_LENGTH_SUM_OF_SEGMENTS methods (and defines what they do), but the pkcs11t.h from PKCS#11 v3.0 Cryptographic Token Interface Base Specification doesn't assign them constant values.
    • I've fixed it by assigning 1 to the former, 2 to the latter:
      /* ERRATA: PKCS#11 v3.0 Cryptographic Token Interface Current Mechanisms
       * defines that these constants exist, but doesn't specify values. pkcs11t.h
       * from PKCS#11 v3.0 Cryptographic Token Interface Base Specification doesn't
       * define these constants either. */
      #define CK_SP800_108_DKM_LENGTH_SUM_OF_KEYS     0x00000001UL
      #define CK_SP800_108_DKM_LENGTH_SUM_OF_SEGMENTS 0x00000002UL
I think I can handle this as non-material like the other missing identifiers.

  1. For all three sections, PKCS#11 v3.0 says: about CK_ SP800_108_DKM_LENGTH, "This data field type is optional.", however no default method is chosen in the later section on deriving additional keys. So either PKCS#11 v3.0 should define a default, or make the field required when pAdditionalDerivedKeys is non-empty (and make it explicitly ignored otherwise).
    • Additionally, without this field, there's no way to indicate the endianness of L parameter, so perhaps it would be better to make this a required field.
I'm not sure how to handle this one. Basically the field is optional, but if it's not specified, the behavior is undefined. Maybe leave it and say as such in v3.1.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]