Problem Statement: Attribute and Object Schema

[Stef Walter <stefw@redhat.com>]

As requested in our last TC call, here is the problem statement for
introspection of attributes and objects in PKCS#11. What follows does
not yet contain a proposed solution ... but is brought forward to the TC
in the interest of outlining the issue at hand:


PKCS#11 lacks schema (or introspection) for objects, attributes, and (to
some extent) tokens.


1. Attribute data types

   It is not possible to discover the data type (ie: CK_ULONG,
   CK_BBOOL) of an CK_ATTRIBUTE_TYPE via PKCS#11.

   This becomes a problem when serializing objects and/or relaying
   attributes via messages. In particular one must know which
   objects are of typedef CK_ULONG. These attributes are the ones
   that vary in size and endianness during storage/transit.

   Many vendors have lists of known CK_ULONG attributes in their
   code.

   In a world where PKCS#11 is never extended this is somewhat
   acceptable. It quickly grows out of hand once extensions
   attributes come into play.


2. Attributes valid on an object

   It is not possible to discover which attributes are available
   on a given object via PKCS#11.

   While it is true that all objects in PKCS#11 are 'fully formed'
   and contain all the required attributes ... this breaks down
   once extension attributes and/or entire extension objects come
   into play.


3. Objects valid on a token

   It is not possible to discover what sort of objects can be
   created on a given token via PKCS#11.

   While it is possible to discover which key generation
   mechanisms are supported via the schema available from the
   C_GetMechanismInfo() (and friends), such schema is not
   available for objects that are to be created via
   C_CreateObject().

   Since not all tokens supported all and/or only the objects
   defined in PKCS#11, applications must fumble their way
   through trying to detect which types of objects may be stored
   on a token.


4. Object creation failures

   When an object creation or key generation fails due to
   unacceptable, invalid or missing attributes in the template
   it's is very difficult for applications to determine which of
   the attributes was the source of the problem.

   In some cases there are specific CKR_XXX return codes that
   point toward the source of the issue.

   The integration guide does solve this from one end. By making
   implementations more consistent in what attributes they accept
   and expect. However this is not a complete solution to the
   problem, especially if we have extension objects and/or
   mechanisms.


As discussed previously CK_MECHANISM is inherently not introspectable.
It is not possible to handle the pParameter argument generically due to
embedded pointers that many mechanisms expect. It is unlikely that we'll
choose to fix this for 3.x, and although related is out of scope of this
problem statement.

In summary, it seems that a PKCS#11 API to retrieve an token's
object/attribute schema would go a long way to resolving these issues
and result in more robust applications as well as inter-operable modules.

Cheers,

Stef