OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [pkcs11] HMAC vs. generic-secret key type amendment

On 10/3/2013 8:05 PM, Peter Gutmann wrote:
Apparently this never made it to the list during yesterday's conference call,
this is a re-send:

-- Snip --

The document I mentioned, or at least a late draft, is still on the RSA


I had problems downloading this via a browser - it kept ending up getting stored as a zero length file. I had to break out the real ftp command and do it that way.

This isn't quite the final version (which vanished somewhere at RSA), but the
"Background" section should give enough of the rationale for why the change
was needed.  As I mentioned on the call, at the time the users that were
affected by this were using HMAC so this is a point solution rather than an
attempt to redefine MAC usage in general, which would presumably have required
much bigger changes.

The explanation in the document is PKCS11 centric (e.g. you can't actually use HMACs and be compliant with PKCS11 so here's the fix) rather than security centric (You shouldn't use the same key for HMACs, CMACs and key derivation because there are security issues with that, and you probably shouldn't use the same key for encryption and CMAC because there may be security issues with that).

I think both narratives are helpful. But the explanatory text that was appropriate when this was proposed as a standalone amendment should probably not be incorporated into the final text if this becomes an integrated part of the standard.

Going back to the above document, it specifies individual types for each of the hash functions. I collapsed this slightly into specifying types only for families of hash functions. I have a slight preference for the latter because of how I think something like CKA_DERIVE_TEMPLATE will need to be specified: in a way that allows you to support the negotiation of a set of crypto suites from a single master secret key (yup -TLS is rearing its ugly head again). Thoughts?

I also specified a set of CMAC key types (which also get used for GMAC) which are the same as the set of known symmetric key types with a specific bit set in the manifest constant.

I'm on travel during the next call. I'd like to ask that someone propose a straw poll(s) to figure out where we're going.

Poll 1: a) don't split off HMAC types - fix the language to allow generic secrets to be used with HMAC; b) split off HMAC types, one per hash function; c) split off hmac types one per family of hash functions. For (b) and (c) ensure the language for C_Sign and C_Verify deprecates and eventually prohibits the use of generic secrets and non-HMAC symmetric key types with HMAC signature modes. For the purposes of evaluating this - if the sum of the votes for (b) and (c) are greater than the number of votes for (a), then the result is "split off HMAC types" (if this needs to be split into two different votes to get that result, then please do so)

Poll 2: a) don't split off CMAC types - ensure the language for symmetric secret key types includes their use in CMAC signature functions; b) split off CMAC types, one per symmetric key type - ensure the language for C_Sign and C_Verify deprecates and eventually prohibits the use of generic secrets and non-CMAC symmetric key types with CMAC signature modes.

Poll 3: a) don't split off master secret types - ensure the language for generic secrets is appropriate going forward for key derivation; b) split off CKK_MASTER_SECRET - ensure the language for C_DeriveKey deprecates and eventually prohibits the use of generic secrets and non master secret keys for key derivation.

For the above "deprecates and eventually prohibits" means that for 3.0 we support both, but provide a mechanism to lock out generic secrets and non-appropriate types for a specific token, for 4.0 generic secrets are locked out of the use (as well as non-CMAC symmetric keys for CMAC)

If anyone else would like to propose an alternative straw poll or set of straw polls, be my guest.



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:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]