[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: pkcs11-GCM-CCMWrapIVnonceupdate_wd3.pdf comments
|
HI Darren, I believe I have updated the doc as per your suggestions. WD6 now there
https://www.oasis-open.org/apps/org/workgroup/pkcs11/download.php/71557/pkcs11-GCM-CCMWrapIVnonceupdate_wd6.docx Thanks for all the input on this I believe we are good to go now. Hamish From: JOHNSON Darren <darren.johnson@thalesgroup.com>
THALES GROUP LIMITED DISTRIBUTION to email recipients
Hi Hamish, I still have some editorial questions/comments. And my more important comments about the
ulDataLen field in the mechanism structures still stands. I still don’t see how an application can fill in this field when wrapping keys. See below. In 1.2.1, The description of C_WrapKeyAuthenticated, it states “pMechanism points to the wrapping mechanism with the
message params either CCM/GCM”. We probably don’t want to explicitly name CCM/GCM like this, as it tightly binds this text with the various mechanism definitions of the specification. And will likely mean
that we will need to update this section with any new mechanisms that we add. I don’t have a clear suggestion as to how to word this though. I think at a minimum, we can just drop “either CCM/GCM”. IMO, I think “pMechanism points to the wrapping mechanism”
is enough. And the actual mechanism definitions can be more explicit as to which APIs the mechanism parameters are valid for. We already have this in the current spec for the various GCM/CCM mechanisms. The only part missing in the later sections is stating
which mechanism parameter structure is valid for C_WrapKeyAuthenticated/C_UnwrapKeyAuthenticated. I could be wrong, but I always viewed the he API descriptions are more generic when it comes to the various algorithms/mechanisms that can be used, and the mechanism
definitions are more specific about where/how they can be used. Thoughts? Later, it states
Primary use case to wrap any secret or private key using an AES Authenticated mechanisum. But I don’t think it should be explicitly limited to AES. It should be “using an AEAD mechanisms”. Or some similar wording I think. Just nothing algorithm or mechanism specific.
The sample code no longer has “auth” defined… but it still shows “auth” being used as a multi-dimensional array: “&auth[0][0], sizeof(auth[0]),”. So we need to re-add the definition of “auth”
and should make it a single dimensional array. 1.2.2 Most of the comments from 1.2.1 apply here as well. This section doesn’t have the “Primary use case…” note. So does it need to be added? or is it simpler to just remove it from section 1.2.1? I guess this inconsistency is carried over from C_WrapKey
and C_UnwrapKey. But the new sections should try to be more consistent. In the sample code the same comment about “auth” also applies. 13.5 I still have questions/comments on the definition for CCM authenticated wrap/unwrap. Some of them are repeated from my initial email I agree and understand that the previous definitions for CCM and wrap/unwrap were not well defined. We should try to fix that a bit now. And for Authenticated wrap/unwrap,
we should also try to be more explicit and not repeat those mistakes. For the normal Wrap case, it currently says “Set the message/data length
ulDataLen in the parameter block.”, but we should fix that. Possibly say “Set the message/data length
ulDataLen in the parameter block to zero. The token will determine the message/data length during the wrap operation based on the key being wrapped. Previous versions of the specification state that the application should populate this field. As such,
tokens SHALL ignore any value provided in this field”. For normal Unwrap case, it states “Set the message/data length
ulDataLen to Zero in the parameter block.This returns a key handle”. The first part “setting it to zero” is fine as the API is a single shot API, but the reason given, “This returns a key handle” doesn’t
make sense. It should just state something line “Set the message/data length
ulDataLen to zero in the parameter block.” The token will get the ciphertext length from
ulWrappedKeyLen. That should be all it needs. For the WrapKeyAuthenticated description, we can’t state “Set the message/data length
ulDataLen in the parameter block.”. The ulDataLen is not known by the calling application because private key encoding is variable in length. So we should state that it should be set to zero, and that
the length will be defined by the token based on the key being wrapped. We don’t need to allow for any other values as this is the first time this is being introduced to the spec. For the UnWrapKeyAuthenticated description, should it be “UnwrapKeyAuthenticated” to be consistent with C_UnwrapKeyAuthenticated? Similar to the text for Unwrap, we shouldn’t say “Set the message/data length
ulDataLen to zero as a key handle will be returned.” The fact that a handle is returned isn’t relevant to the value of this field. Similar to Unwrap, I think “Set the message/data
length ulDataLen to Zero in the parameter block. “ is sufficient to say. Thanks Darren From: Hamish Cameron <Hamish.Cameron@entrust.com>
Here is a link V5 avaialble. Thanks Hamish |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]