On z/OS, an application can be running in either single address
space mode, or in cross memory mode. The PKCS #11 standard has no
concept of cross memory mode, so there is no predefined expected behavior
for a PKCS #11 application running in cross memory mode.
When running in cross memory mode, the unit of work is running
with PRIMARY set to an address space that differs from HOME. This
PRIMARY space may be another address space that is logically part
of the overall application (for example, if the application was designed
to be cross memory aware) or it may be a daemon or subsystem address
space dedicated to some system service that the calling application
has invoked using a Program Call (PC). Either way, you should be aware
of the following z/OS PKCS #11 application behaviors and associated
guidelines.
- The C API invokes Language Environment (LE) services that are
not supported in cross memory mode.
Guideline: To
use PKCS #11 in cross memory mode, you must call the PKCS #11 ICSF
callable services directly.
- Tokens, token objects, and session objects belonging to installation-defined
PKCS #11 tokens (but not to the omnipresent token) are protected by
RACF access control. Additionally, the ICSF callable services themselves
may also be protected by RACF access control. In both cases, the user
ID that is used for the access check is always associated with the
unit of work. This is either the user ID assigned to the HOME ASCB
or the user ID assigned to the Task Control Block (TCB) or System
Request Block (SRB).
Guideline: If the PRIMARY
address space function invoked by a PC uses PKCS #11 services, the
user ID associated with the caller’s unit of work must be appropriately
permitted to the CRYPTOZ or CSFSERV resource being checked. If this
is a system service, then all such callers must have access.
- FIPS140 compatibility mode behavior is also controlled by resources
in the CRYPTOZ Class.
Guideline: If the system
is configured for FIPS140 compatibility mode and the PRIMARY address
space function invoked by a PC is expected to adhere to FIPS 140-2
restrictions, the user ID associated with the caller’s unit of
work should not be permitted to the CRYPTOZ FIPSEXEMPT resource being
checked. If this is a system service, then all such callers should
not to be given access.
- By definition, session objects (including those belonging to the
omnipresent token) are scoped to a single address space. For session
objects belonging to installation defined PKCS #11 tokens, the scoping
is to the HOME address space at the time of object creation, even
if PRIMARY does not equal HOME. These objects are accessible to all
units of work belonging to the HOME address space only, even if the
PRIMARY address space function invoked by a PC is intended to be the
logical owner of the PKCS #11 object.
In contrast, session objects
belonging to the omnipresent token are scoped to the PRIMARY address
space at the time of object creation and are addressable by all units
of work running with that address space set as PRIMARY. For session
objects created by system services invoked by a PC, such session objects
would not be addressable by the caller once returning from the service
call.
Guideline: System services invoked
by a PC should use the omnipresent token instead of an installation
defined PKCS #11 token when creating session objects that are to be
owned by the system service.
- For certain multipart PKCS #11 cryptographic operations, ICSF
will save session-state information across calls. This state
information is scoped to the PRIMARY address space, similar to the
scoping for omnipresent token objects. Such state objects are only
addressable to units of work running with that address space set as
PRIMARY.
Guideline: If you begin a multipart
PKCS #11 cryptographic operation, you must remain running in the same
PRIMARY address space in order to continue the operation.