[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11] Re: Updates to CKA_GLOBAL, CKM_CERTIFY_KEY and CKM_SEAL_KEY
On 6/4/2013 2:28 PM, Chris Zimman wrote:
I'm pretty sure that is by design. By design, a key sealed with this mechanism is only guaranteed to be restorable (unsealed) to the token from which it originated. I consciously avoided specifying the actual cryptographic mechanism used to seal and the format of what was sealed and the format of the sealed blob for that reason.
Actually, no. It takes a conscious effort to bypass this - the only way the normal controls are bypassed is if you use the CKA_GLOBAL seal key (defined in the other document).
This should be fine. A number of devices already do this implicitly. And we're doing a device that uses this concept to deal with storage. I also refer you to several TPMs which support this and are FIPS140 certified.
I'll add this guidance to the draft, but I won't specify the mechanism. That's up to each and every token manufacturer to select. (But CKA_AES_KEYWRAP_PAD might be a good choice... ) The main reason for avoiding specifying this is that various regulatory domains (e.g. countries) may have specific guidance on which types algorithms can be used for this purpose.