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

[Chris Zimman <czimman@bloomberg.com>]

	> No.  Keys can already be tied to specific mechanisms.  That's the way to do it.  

Are you referring to using CKK_?	

	> And the "policy exception" stuff for a specifically designated key, will of course be enforced by C_Wrap/Unwrap -- where else would you do that?

It's up to other functions to reject the use of this key then too (e.g. C_Encrypt())

	> No.  But the application that is actually talking to the token may choose to do exactly that.   

What's an example use case for where an application wants to create a key, move it outside of a token, and then deal with where it lives by itself?  I believe you have one, I'd just like to understand it in order to getting a clearer understanding of the whole picture.

	> For this set of points, I'm going to defer.  Right now, the tokens only support role logins and not user logins.  And having a single key for the token and session to do 
	> sealing is probably sufficient.  The user is the token owner, regardless of who is actually using the user login.  That means that the "user" is responsible for content 	
	> consistency.  If we get to the point where there user based logins then we will need to readdress a bunch of things, this included.

Not that it would have to be solved for this to be potentially applicable, but I think it's useful to consider something like this because if it's pushed into a release, and then people potentially have to rework it for a near major release, there's probably going to be some frustration.

	> Fair.  But again, you're assuming the HSM is actually proof against hardware based attacks (DPA for example) and has better security than a blob at rest encrypted with 	> appropriately strong keys.  Given all I know about the general HSM marketplace, I'd rate them similar in resistance to attack. 

I think there's a pretty clear cut reason that there are levels 1 through 4 for FIPS 140.  I would not say by any means that all tokens are equal, especially after having pulled apart a handful of them.

	> What I'm saying is that this isn't actually an implementation guide per se.  Saying PKCS11 does not imply "FIPS 140-2 level 4" guarantees of protection or other external 	> guidance.  I'm not exactly sure we should go there.  (Mainly because that opens up a food fight where we become way too proscriptive and fight over each and every 	> MUST....)

I think it's important to consider stuff like this, even in an abstract form.  My point is not that PKCS11 should imply FIPS 140 level 4, but it definitely should not preclude it.