pkcs11-GCM-CCMWrapIVnonceupdate_wd3.pdf comments

[JOHNSON Darren <darren.johnson@thalesgroup.com>]

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