We will see what we can do,
worst case we'll have to deal with RHCS 10 having its own KDF implementation until we can release a new NSS.

Yes.

"key size" in the above message refers to the "[L]_2" parameter in NIST SP800-108, which is well-described by a PKCS#11 v3.0 CK_PRF_DATA_PARAM struct of type CK_SP800_108_DKM_LENGTH (pointing to a CK_SP800_108_DKM_LENGTH_FORMAT struct with bLittleEndian = CK_FALSE, ulWidthInBits = 16). From SCP03:

> (4.1.5) A 2 byte integer “L” specifying the length in bits of the derived data (value '0040', '0080', '00C0', or '0100').

"counter" in the above message refers to the "[i]_2" parameter in NIST SP800-108, which is well-described by a PKCS#11 v3.0 CK_PRF_DATA_PARAM struct of type CK_SP800_108_ITERATION_VARIABLE (pointing to a CK_SP800_108_COUNTER_FORMAT struct with bLittleEndian = CK_FALSE, ulWidthInBits = 8). From SCP03:

> (4.1.5) A 1 byte counter “i” as specified in the KDF (which may take the values '01' or '02'; value '02' is used when “L” takes the values '00C0' and '0100', i.e. when the PRF of the KDF is to be called twice to generate enough derived data).

"context" in the above message refers to the "Context" parameter in NIST SP800-108, which is well-described by a PKCS#11 v3.0 CK_PRF_DATA_PARAM struct of type CK_SP800_108_BYTE_ARRAY (pointing to a uint8_t array with the relevant data). From SCP03:

> (4.1.5) The “context” parameter of the KDF. Its content is further specified in the sections below applying the data derivation scheme.

And then further:

> (6.2.1) The “context” parameter shall be set to the concatenation of the host challenge (8 bytes) and the card challenge (8 bytes).
> (6.2.2.1) The “context” parameter shall be set to the concatenation of the sequence counter (3 bytes) and the AID of the application invoking the SecureChannel interface (5 to 16 bytes).
> (6.2.2.2) The “context” parameter shall be set to the concatenation of the host challenge (8 bytes) and the card challenge (8 bytes).
> (6.2.2.3) The “context” parameter shall be set to the concatenation of the host challenge (8 bytes) and the card challenge (8 bytes).

Note that the context parameter need not be a fixed length; it just needs to be known at the time of KDF invocation. My understanding of PKCS#11 v3.0 is that a KDF gets constructed "fresh" for each PK11_DeriveKey(...) invocation, so we can easily call it with these differing parameters.

----

The only open question is "how do we export non-key material derived by this KDF?" -- this was asked in comment#16 and again in email ("Re: RHCS QE willing to assist with NSS testing to get needed package in 8.2" - September 10th) -- admittedly, with a lot of other questions!

Currently the PKCS#11 v3.0 layer only seeming lets me export derived keys, though I haven't looked into if there's a way to get the raw bytes behind a symmetric key, or if there's a "NULL" key type that could be used and extracted.

Bob, is there a way to do this? I don't think I saw a reply to that -- though, I think we discussed it on #nss and you said we might need an extension to PKCS#11 to allow us to do that.

> Note that the context parameter need not be a fixed length;

well, that actually may be problematic from NIST/FIPS point of view, in the SP 800-108 they are ok with different order if the values are defined for given usage

If the KDF, in single protocol, sometimes can be called with one context and once with different context, it may not be compliant...

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1638