Hello,
I reviewed section 6.40 as I found several mistakes a few months back
when I was reading the spec to implement the relevant mechanism in my
token[1].
I see that since 3.1 some of the most glaring errors in the name of the
mechanisms have already been fixed in WD05, however there remains some
open issues that should be resolved.
Because all of these issues are not minor editorial changes (like
names) I wasn't sure how to highlight them and propose changes so I
added comments in a doc copy where I left only the section of interest
and put my suggestions as list of items in this email.
I also generate a pdf with said comments for quicker viewing.
Fundamentally there are 2 main issues:
The CKM_TLS_MAC/CKM_TLS12_MAC and CKM_TLS_KDF/CKM_TLS12_KDF seem to be
just duplicated mechanism IDs with no discernible difference except for
their different names and numbers.
CKM_TLS_MAC is specified but missing from the initial table.
CKM_TLS12_MAC is required for keys generated by
CKM_TLS12_MASTER_KEY_DERIVE and CKM_TLS12_MASTER_KEY_DERIVE_DH but is
completely unspecified.
CKM_TLS_KDF and CKM_TLS12_KDF are both specified, their text is
completely identical and there is no discerning difference to be found.
I suggest:
- that paragraph 6.40.3 adds a reference to CKM_TLS12_MAC stating that
this mechanism is fundamentally an alias of CKM_TLS_MAC (or the other
way around).
- that paragraphs 6.40.8 and 6.40.9 are merged and the text specify
that CKM_TLS_KDF and CKM_TLS12_KDF are basically aliases.
- that CKM_TLS_MAC and CKM_TLS_KDF are marked as deprecated and
CKM_TLS12_MAC and CKM_TLS12_KDF should be used in preference.
- that in paragraphs 6.40.4 and 6.40.5 CKM_TLS_MAC and CKM_TLS_KDF are
ether added to the CKA_ALLOWED_MECHANISMS attribute stored on the keys,
or otherwise that the spec suggests implementations should treat
allowance of CKM_TLS12_KDF as also allowing CKM_TLS_KDF (and similarly
for CKM_TLS[12]_MAC)
HTH,
Simo.
[1] for the curious:
https://github.com/latchset/kryoptic--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc