pkcs11 — archive

[Michael StJohns]

On 8/5/2013 1:32 PM, Dina Kurktchi wrote: On 08/05/13 10:10, Michael StJohns wrote: I took a look at this. I don't have a problem with the general addition of SHA512/224 and SHA512/256 to the pot, but I think I'm still not happy (as previously discussed) with adding a set of mechanism types that does nothing but truncate the result of the other mechanisms. The IV is different for each of the SHA512/t hashes. Thus: trunc( SHA512(text) , 224 ) ! = SHA512/224( text ), nor is trunc( SHA512/256(text) , 224) ! = SHA512/224( text ). It is not SHA512(text) "classic" truncated to some shorter length. I was talking about the CKM_SHA512_T etc mechanisms. Not the above. Section 1.3 on in your document. I note also that this proposal has new key types CKK_SHA512_224_HMAC et al - I think I agree with this, but did we actually agree to do these changes with 2.40? (E.g. adding mechanism specific typing for keys?) I was under the impression that it was a substantial enough change that affected a lot of things that it was deferred to 3.0. Followed the example of the other CKK_*_HMAC that I found in spec. *sigh* Yes. They are there. *sigh* Unfortunately there is still a problem with your text. In the CKM_SHA1_HMAC there is a statement that is missing from your text: The keys it uses are generic secret keys and CKK_SHA_1_HMAC. Or in your case CKK_SHA512_224_HMAC. E.g. you've got a manifest definition with no normative text to describe how that key is used - we can infer, but... The whole key usage for keyed CMAC's and HMAC's text (in the document, not your proposal) needs to be re-worked and cleaned up. Mostly these still use CKK_GENERIC_SECRET. I'd be happier if they used CKK_HMAC rather than something more specific and let the key creator use the CKA_ALLOWED_MECHANISMS attribute to lock the key to a particular HMAC algorithm. Add it to the list of bugs to resolve. Mike If this goes to ballot for 2.40, I'd like it to be a split ballot with yes/no for the two different groups of mechanisms. I'm not sure what to do about the new CKK_ stuff. Sure, if it needs splitting, I can accommodate. Thanks! D. Mike On 8/2/2013 7:12 PM, Dina Kurktchi wrote: Proposal: CKM_SHA512_224, CKM_SHA512_256, CKM_SHA512_T Addition of new hash algorithms defined in FIPS 180-4: SHA-512/224, SHA-512/256, and general case SHA-512/t. FIPS PUB 180-4, "Secure Hash Standard (SHS)", March 2012 http://www.nist.gov/manuscript-publication-search.cfm? pub_id=910977 The text attached can be inserted immediately after what is now section 2.21 in "PKCS #11 Cryptographic Token Interface Current Mechanisms Specification Version 2.40". The general case SHA-512/t is included for completeness. This proposal is independent of Robert Burns' "Proposal: Update references to FIPS PUB 180". The two ought to be complementary though. Thanks, D. --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php