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

[Chris Zimman <czimman@bloomberg.com>]

      Seal objects are always secret keys.  They may only be used with the CKM_SEAL_KEY mechanism 

So the enforcement of this then becomes the responsibility of C_(Un/)WrapKey() and also requires the concept of the CKA_GLOBAL for presence?  Would it make more sense to just make a new key type for this mechanism?
 
	The "sealed" data is not a PKCS11 object, and sealing a key does not delete it from the token.  The client has to explicitly delete it if it wants to recover space on the 	token. 
	Similarly, the client is responsible for "unsealing" the sealed data and re-creating a new key object (with generally a new CK_HANDLE).

	No.  This is tied to the token, not to the user.  If the key can be used by a particular user, it can be sealed.  This is all about extending the token storage outside the 	physical boundaries.  

I guess I'm sort of missing the point here then - is the intention for me to be a good citizen and every time I'm done using a key to seal it and move it to offline storage to make more room on the token?  As a user of a token, this is not something I'd generally want to have to concern myself with.

	But there's another point here that I need to think about.  If the key contains all the attributes, and an attribute changed once the key was sealed, unsealing the key is 	going to get you the old attributes and possibly reverse an access control decision.

It does present issues in terms of atomicity and revocation.  As you've pointed out, if a key is deleted intentionally, it can also potentially be restored unwantedly.

	Keep the same mechanism, but add way of generating/zeroizing persistent seal keys that are subordinate to the token seal key. That way you can group sealed keys by 	use, and zeroize a specific group of keys all by rolling over the key used to seal them.   Or still zeroize them all by re-initializing the token.

Doesn't this present the same issue that this is trying to solve in the first place?  Where do you keep record of which (or copies) of these subordinate sealing keys are valid?

      Actually, any key you can use is subject to various attacks - but most of them (like the offline attacks) are no better than brute force.

Yes, but the attack surface becomes much more open when you don't have to use the HSM to perform the attack against itself.  The "hardness" of the offline attack depends on the requirement that your sealing key is at least as strong as what it's sealing.

	A lot of times this is "don't be stupid" type of guidance to the implementer.  There are other places (e.g. FIPS) where it requires the relationship you mention above.  If I 	were going to try and fix this, I'd actually do it in the text for C_WrapKey and C_UnwrapKey rather than in this mechanism description.

Ignorant or misguided does not necessarily imply stupid, but can be just as dangerous.