[Defect]: Missing variable {dkLen} in HKDF[-{hashFunction}] variant of the algorithm family HKDF

[meghsaha-ibm]

Describe the defect

Missing variable {dkLen} in HKDF[-{hashFunction}] variant of the algorithm family HKDF.

Additional context

The issue is data-quality / naming defect in the Cryptography Registry and can be fixed without changing schema behavior or introducing new algorithms.

[stevespringett]

cc: @bhess

[bhess]

Hi @meghsaha-ibm, thank you for this suggestion. Are you referring to the parameter $L$ (length of output keying material) defined in RFC 5869?

I would argue that it shouldn't be part of the naming pattern because $L$ is a variable input parameter for a specific invocation, rather than a fixed part of the algorithm's parameter set.

However, I see the value in capturing this for CBOMs. Perhaps we should consider an extra property field for algorithms that allows for restricting or defining permitted input/output sizes when they are variable. I believe @jvdsn had a similar use case for defining length ranges. What do you think, @stevespringett?

[meghsaha-ibm]

Hi @bhess, the variant for the algorithm families PBKDF1 and PBKDF2 in the Cryptography Registry have the variable input parameter {dkLen}. Hence, I thought that the variant for the algorithm family HKDF must have the variable input parameter {dkLen}.

Please share your feedback.

[jvdsn]

I'd prefer to see this added to the core spec rather than the cryptography registry. Too much data in the cryptography families risks creating a "spec within a spec" as now the family name has to be parsed to obtain relevant properties.

[bhess]

I agree with @jvdsn, this should not be part of the registry, we should also revisit PBKDF1/2.