RE: pkcs11-GCM-CCMWrapIVnonceupdate

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 .

Function	Key type	Data length	Signature length
C_Sign	CKK_AES	any	Block size (16 bytes)
C_Verify	CKK_AES	any	Block size (16 bytes)

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
Draft 4 further updates tweaks. Proposal for allowing the token to
choose/generate the IV (GCM) or nonce (CCM)internally when wrapping in GCM
and CCM. New functions Authenticated wrapping.
Download Latest Revision
Public Download Link

Submitter: Hamish Cameron
Group: OASIS PKCS 11 TC
Folder: Working Drafts
Date submitted: 2023-09-26 14:17:21

From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> On Behalf Of JOHNSON Darren
Sent: Wednesday, June 21, 2023 8:10 PM
To: pkcs11@lists.oasis-open.org
Subject: [EXTERNAL] [pkcs11] pkcs11-GCM-CCMWrapIVnonceupdate_wd3.pdf comments

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

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.

What is the use case for the pParameter/ulParameterLen parameters of these two new APIs? In the case of the Message APIs, those make sense and are needed as some mechanism parameters are passed in during the C_EncryptMessageInit call while additional/new/fresh information is needed in the C_EncryptMessage (as an example). But here, the entire operation is one API call so the entire parameter can be passed in as part of the single API call.
Similar to the previous point, the C_WrapKeyAuthenticated example show the “gcmParams” structure being passed in as the mechanism parameter and as pParameter/ulParameter while the example for C_UnwrapKeyAuthenticated shows the mechanism parameter as NULL and “gcmParams” passed in via pParameter/ulParameter. Is there a reason to pass this in twice? Or is this just a copy/paste error from the message API examples? If “gcmParams” is supposed to be passed in, then the examples are missing the & in a few spots when taking the address of the structure.
The sample code for the two new APIs contain some extra constructs that are relevant for the Message APIs, but don’t belong here. Specifically, the two dimensional arrays for auth data, which makes the code much more complicated than it needs to be.

In section 1.3.3

The final text when tracking is removed for “Call C_UnapKeyAuthenticated() for CKM_AES_GCM mechanism, wrapping key wK, Wrapped, parameter, template for the new key, obtaining a key handle.” isn’t quite right. Specifically “, Wrapped, parameter,”. It should be “wrapped key”?
The last paragraph in 1.3.3 stats the following:

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:

Function	Key type	Data length	Signature length
C_Sign	CKK_AES	any	Block size (16 bytes)
C_Verify	CKK_AES	any	Block size (16 bytes)

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.

When wrapping an asymmetric key, how can ulDataLen be specified in the mechanism parameter? I suspect this was included in the mechanism parameter for encrypt/decrypt to facilitate multipart operations so that the first block could be constructed. I assume that this value MUST match the total data length eventually input for the encrypt/decrypt, otherwise an error is returned.

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

pkcs11 message