OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: User types - discussion thread

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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]