RE: [pkcs11] Re: Updates to CKA_GLOBAL, CKM_CERTIFY_KEY and CKM_SEAL_KEY

[Chris Zimman <czimman@bloomberg.com>]

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

So who can use the CKA_GLOBAL seal key?  What happens if the key I happen to want is "paged out" at the time I request it?

	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.

The idea of wrapping a blob and exporting it doesn't inherently concern me.  It's the concept of being able to wrap any key and export it, even if I don't want it being done.

	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.

There is already specific guidance around which mechanisms can be used to wrap keys for other mechanisms.  The basic idea being that you cannot wrap a key for export with a mechanism/key that is weaker than the key which you're wrapping, since it'd become the weakest link in the chain.  How do you do something like that on a global scale?