Key Groups

A Key group defines a set of keys in a partition. It allows defining a CORE user role that specifies permitted operations:

  • at a granularity of a single key or set of keys
  • without explicitly stating UIDs of the keys that are addressed by the role.

In particular, a role that allows certain usage of a particular key automatically applies to its rotated descendants or derived keys.

CORE implements a key membership in a group by tagging the key with a tag that identifies the key group. A tag is a string of characters without spaces. See Key-group Name Special Characters.

Note
A Key Group (tag) is not a managed element in CORE. A key group is implicitly created just by mentioning it in the following settings:
- the groups setting of a key.
- the permissions setting of a role.

The Default Key Group

All objects are members of at least one group - the default group. It has the following properties:

  • The membership in the default group cannot be revoked.
  • When an object is created and tagged with a "<group-name>", it is also added to the "default" group

The static CORE roles USER and SOClosedSecurity officer - UKC partition administrator role. (see Static Roles) specify the default key group in their permissions. Therefore, the CORE users possessing these roles have access to all key material in their partitions.

Key Groups and Custom Roles

We use key groups to specify a role restricted to use the specified group of keys, certificates, and secrets. In addition, we restrict their use by operations in the allowed-list. The bundle of allowed objects and allowed operations is a Permission. A role is a set of one or more permissions.

Operation permissions for a key group

For further details and examples of key group use, see User Permissions.

Notes:

  1. A custom role may refer to the all-inclusive default key group while restricting the use to a set of operations.
  2. The default user of a partition may be reassigned to a custom role.
  3. Note
    Such a reassignment is required to achieve the least permissions principle when CORE client-based applications must operate in a partition without user-level authentication. In such a case, CORE acts on behalf of the default user using its default password. However, by default, this user has access to all keys in the partition. To restrict the default user's scope without impacting the application that depend on it, reassigning the default user to a custom role. Make sure that the custom role specifies only the required keys and only the required operations.

  4. The default so of a partition cannot be reassigned to a custom role.
  5. It may be added to a user group that provides additional privileges, but its basic privileges granted by the static SOClosedSecurity officer - UKC partition administrator role. role can not be reduced.

Managing Key Group Membership

When a crypto object (key, certificate, secret) is created, it is automatically assigned to the "default" key group. You may also instantly add it to other groups or modify its groups settings later.

Create
The following create operations allow specifying membership in crypto groups (in addition to the mandatory membership in the default key group).
Generate-Key
Generate-KeyPair
Import
Link
The following creation methods preserve group membership of their origins:
Derive
Re-key
Re-keyPair
Read
Object membership in crypto groups is listed when the object is shown.
Update
To update object membership, replace the current membership list with the updated one. Membership in the "default" group is permanent.
Delete
To delete a membership in particular groups, use the Update method.