[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: pkcs11-GCM-CCMWrapIVnonceupdate_wd3.pdf comments
I have another think about further and still think the C_WrapKeyAuthenticate has value I have started a v5 which removes the Params as part of the additional args and is just part
of the mech as usual. Thanks Hamish From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org>
On Behalf Of Hamish Cameron Hi Darren,
Hi Darren, Finally found some cycles to reply to the comments. The actual proposal was to be able address the return of an IV generated by the provider such that this could then
be random and passed into the unwrap.
I proposed two alternatives trying to follow the new convention with the Message based Encrypt/Decrypt sign/verify etc. When wrapping using AESGCM or CCM you can provide additional data in the
standard. When I first proposed this, I was torn by providing just a new mech Params structure for the existing C_WrapKey and C_UnwrapKey. The description about the method was adapted from the encrypt/decrypt and was trying to follow conventions for GCM and
CCM as per 3.0/3.1 . I proposed two versions the New params structure is to only be used with the original C_WrapKey and C_UNWrapKey as stated in the new description. The existing CK_GCM/CCM_MESSAGE_PARAMS would be used for the new C_WrapKeyAuthenticated.
I would not expect to pass in the parms with the mech. Proposal updates I have tidied up the examples and removed the excess. I have removed the line mentioning CKM_AES_ECB this, pasto error form the encrypt/decrypt message description and has no meaning
here. I tried to leave it generic and follow convention and from the fact that it is in the GCM /CCM sections felt that this was what mechs I was talking about.
The GCM/CCM section was introduced in 3.0 see also latest spec
https://docs.oasis-open.org/pkcs11/pkcs11-spec/v3.1/csd01/pkcs11-spec-v3.1-csd01.html#_Toc98177340,
which was first created and in the accepted spec of v3.0 so followed the convention for the wrap and unwrap and would help users when using wrap and unwrap. The table description you mention as an AES example .
These are not present for the encryptmessage functions and so I followed convention in section
6.13
https://docs.oasis-open.org/pkcs11/pkcs11-spec/v3.1/csd01/pkcs11-spec-v3.1-csd01.html#_Toc98177340 as this seemed to be a way of describing the complexing of how to use the new functions.
I presented this and two option to the TC and it was felt that both were plausible solutions I was divided no strong opinion for either. I am happy to remove the C_WrapKeyAuthenticate
new functions is now not seen incorrect but it was decided to use both for so that legacy users could use the older C_Wrap/UnWrapKey functions with the new params as a way of getting back a provider randomly generated IV (FIPS 140-3 level3 requirement) but
going forward use the Authenticated using the standard message params that is passed into the function and not as part of the mech. Agreed it looks over kill as the functions are single shot but they could be used for other mechs. Using
CK_CCM_MESSAGE_PARAMS for Authenticated Wrap functions:
“Because Wrap/Unwrap is a single part operation, we don’t need ulDataLen in the parameter structure. This would be fine for CK_CCM_WRAP_PARAMS as it is only for the C_WrapKey and C_UnwrapKey APIs. But if we want to share the CK_CCM_MESSAGE_PARAMS
for the new authenticated APIs, that won’t work well.” The original CK_CCM_PARAMS also has the Data len param and there for would assume that this would be left blank for the wrap and is not used. in previous specs prior to 3.0 the use of the params
for wrapping was not well described. The Authenticated wrapping mech params could be moved back as part of the mechanisms themselves but are still one Shot mechs however the output from the wrap the params info mac that is returned then must be passed to
the unwrap nonce etc. I have updated the spec. Before we make a proposal to accept I think the decision to weather the Authenticated wrapping functions should be included or not?
Thanks Hamish Document Name:
pkcs11-GCM-CCMWrapIVnonceupdate_wd4
Description Submitter: Hamish Cameron From:
pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org>
On Behalf Of JOHNSON Darren WARNING: This email originated outside of Entrust. Hi, sorry for bringing these up last minute. But for some reason, I never looked at this proposal. Some of the items below may be minor and can be ignored, some are editorial. But some I think are more important. For the new APIs, I have the following question.
In section 1.3.3
The key type for K must be compatible with CKM_AES_ECB and the C_WrapKey()/C_UNWrapKey()/C_WrapKeyAuthenticated()/C_UnWrapKeyAuthenticated() calls shall behave,
with respect to K, as if they were called directly with CKM_AES_ECB, K and NULL parameters. First, it should use “wK” instead of “k” to be consistent with the previous text.
Second, is this the way we want to describe this? Shouldn’t it out right say that it must be a key type that is supported for AES-GCM; or just state CKK_AES? Nearly all sections for all
mechanisms have a simple table to define the supported functions and supported key types. For example:
But some of the more recent additions (GCM and CCM) have moved away from this. Did we make a conscious decision to move away from this format? It seems much cleaner/clearer and is consistent
with the rest of the spec. In the specific case of the C_WrapKey()/C_UNWrapKey()/C_WrapKeyAuthenticated()/C_UnWrapKeyAuthenticated() calls, it should NOT behave as if they were called directly with CKM_AES_ECB, K
and NULL parameters. There are a lot of parameters to check and validate, not to mention that the APIs perform a complete operation start to finish. This description “may” make sense for the MessageInit APIs, but even then I would argue that they should
be (either expected to, and certainly allowed) doing a lot more than what is done when CKM_AES_ECB with NULL parameters is called. I didn’t go over the CCM content in as much detail. It uses the same style. So some of the questions above apply here as well.
But the encoding of an asymmetric key is not always known by the calling application. DER INTEGER types may or may not have leading zeros, etc. Isn’t this a problem? Because Wrap/Unwrap is a singlepart operation, we don’t need ulDataLen in the parameter structure. This would be fine for CK_CCM_WRAP_PARAMS as it is only for the C_WrapKey and C_UnwrapKey
APIs. But if we want to share the CK_CCM_MESSAGE_PARAMS for the new authenticated APIs, that won’t work well. On general follow up question… I didn’t think this through at all, but do we need new APIs here? What is the advantage? What are we solving? We are allowing authenticated wrapping and addressing the IV issues with C_WrapKey
and introducing wrapping specific mechanism parameters like CK_CCM_MESSAGE_PARAMS. Or did I miss something? Thanks Darren Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent
to you in error, you must not copy, distribute or disclose of the information it contains.
Please notify Entrust immediately and delete the message from your system.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]