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] Sensitivity and extractability of derived keys


Michael,

Can you point me to the section of the spec which mentions 3) ?

Also, I believe 3) is an option, an open option. 
You do 3) only if you absolutely need it.
Otherwise, by default, one should not do 3).

Thanks!

-Oscar







----- Original Message -----
From: msj@nthpermutation.com
To: pkcs11@lists.oasis-open.org
Sent: Sunday, August 11, 2013 12:25:45 PM GMT -08:00 US/Canada Pacific
Subject: [pkcs11] Sensitivity and extractability of derived keys

I'm editing the TLS12 mechanism section and I keep bumping up against 
the appropriate values for CKA_SENSITIVE and CKA_EXTRACTABLE for derived 
keys.

There are basically three different cases that are described in PKCS11 
document (pretty much over and over in different locations)

1) Keys get the same sensitivity values as the base key.
2) Keys can be set the same or more sensitive than the base key, but not 
less sensitive - e.g. CKA_SENSITIVE=false for the base key can get you a 
CKA_SENSITIVE=true for the derived key and CKA_EXTRACTABLE=true for the 
base key can get you a CKA_EXTRACTABLE=false for the derived key.
3) Keys can be set to any sensitivity level regardless of the base key's 
sensitivity settings.


TLS10 uses (1) for KEY_AND_MAC_DERIVE and (3) for the master key derivation.

CKM_EXTRACT_KEY_FROM_KEY uses (2).

The draft TLS1.2 document currently follows TLS10, but I'm not sure 
that's the most correct approach.


There are a few things I'd like some comments on:

1) Would it make sense to move the three cases to their own section and 
then use the superscript approach to tag each mechanism with how the 
derive sensitivity is handled (e.g. table 15 provides superscripts for 
how CKA_ values are treated - so do something similar for derives)?  If 
so, can this just be done as an editorial change?

2) Does (3) ever make sense?
2a) If (3) always makes sense, then how do you ensure that derived keys 
can be kept within the HSM?
2b) if (3) never makes sense how do you export session keys so they can 
be used in software (e.g. HSM is the public key accelerator, but most of 
the encryption is done using a generic processor).
2c) if (3) only sometimes makes sense, then how do we configure the HSM 
to do the sensible thing for different cases?


Mike






---------------------------------------------------------------------
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 



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