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).
- 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.
- 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_KEY s.
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?
- 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.
- 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.
|