User types - discussion thread

[Michael StJohns <msj@nthpermutation.com>]

In PKCS11 there are currently two types of users, CKU_USER, CKU_SO and 
CKU_CONTEXT_SPECIFIC.  The USER type, when logged in, can access all the 
keys on the token, use them and change their attributes within the 
limits of PKCS11 policy.

The SO user type has only a single function defined in PKCS11 as far as 
I can tell  - marking keys as trusted.

The CONTEXT_SPECIFIC user seems to be used only for those keys that 
require authentication each time they're used.

The above provides only a minimal amount of role based policy 
protections.  Over the years I've found this minimal set of roles to be 
somewhat constricting in building PKCS11 applications as they don't 
provide granular enough control over the token.  We've added a few 
additional attributes (CKA_COPYABLE and CKA_DESTROYABLE) as of 2.40 that 
provide some improvements, but I think we should consider modifying the 
model either slightly or comprehensively:

Slightly:  One of the big issues I've encountered with PKCS11 is that 
the creators of the key materials are not always the users of the key 
materials.  That leads to complications in managing the token in that 
we'd (e.g. my customers) *really* like to prevent the users of the key 
materials from either creating or destroying key material.   
CKA_DESTROYABLE works for the destroying part, but there's no way to 
prevent the creation.  A slight modification to the above set of user 
types might be the addition of a CKU_SESSION_USER who's allowed 
read-only access to token key material for use, but can't create or 
destroy any CKA_TOKEN=true objects - the session user MAY create session 
key material as necessary.  A second slight modification might include 
the addition of a CKU_OWNER_USER who in addition to all the access a 
CKU_USER gets may set key protection attributes on the keys irrespective 
of normal policy (e.g. can violate the stickyness rules for 
attributes).    So CKU_OWNER_USER > CKU_USER > CKU_SESSION_USER in terms 
of access.

Comprehensive:  Another possible approach may be to go to a full user 
(vs role) based system where each object is tagged both with the owner 
(who gets to set attributes) and the users allowed to use the object.  
There's probably also the concept of a token owner who gets add and 
delete users. Obviously, this would be a bit more disruptive than the 
simple additions described above.    It would require a more 
comprehensive user management system than currently exists, and a set of 
functions to manage the access control lists for the objects.    But 
this approach may be required to support multi-party (m of n) 
authorization models.


A third option is to standardize both - but make the "comprehensive" 
version optional.


Thoughts?

Mike