Subject: RE: [pkcs11] C_GetInterfaceList
Agree. I didnât think about C_GetMechanismInfo. And for consistency there should be a interface enumeration.
However, for consistency, there should be no data structure and function with a fixed array length, which is the case with GetFunctionLists of the current working draft.
But I disagree that my proposal doesnât let an application discover available interfaces. In fact, it provides both: a list of ALL available interfaces and their associated function list pointers WITHOUT the array limitation.
To be more consistent, for example with C_GetMechanismInfo, it could also work like this:
C_GetFunctionLists obtains a pointer to the Cryptoki libraryâs list of supported interfaces and associated function pointer lists. ppFunctionLists points to a value which will receive a pointer to the libraryâs array of CK_FUNCTION_LISTS structures, which in turn contain a pointer to the interface name and a pointer to a list of function pointers for all the Cryptoki API routines in this interface. The pointers thus obtained may point into memory which is owned by the Cryptoki library, and which may or may not be writable. Whether or not this is the case, no attempt should be made to write to this memory. pulCount receivers the number of interfaces.
There are two ways for an application to call C_ GetFunctionLists:
1. If ppFunctionLists is NULL_PTR, then all that C_ GetFunctionLists does is return (in *pulCount) the number of interfaces, without actually returning them. The contents of
*pulCount on entry to C_ GetFunctionLists has no meaning in this case, and the call returns the value CKR_OK.
2. If ppFunctionLists is not NULL_PTR, then *pulCount MUST contain the size (in terms of CK_FUNCTION_LISTS elements) of the buffer pointed to by ppFunctionLists. If that buffer is large enough to hold the list of interfaces and function pointers, then the list is returned in it, and CKR_OK is returned. If not, then the call to C_ GetFunctionLists returns the value CKR_BUFFER_TOO_SMALL. In either case, the value *pulCount is set to hold the number of interfaces.
C_GetFunctionList and C_GetFunctionLists are the only Cryptoki function which an application may call before calling C_Initialize. It is provided to make it easier and faster for applications to use shared Cryptoki libraries and to use more than one Cryptoki library simultaneously.
From: email@example.com [mailto:firstname.lastname@example.org]
On Behalf Of Tim Hudson
The same thing could be said for mechanisms with parameters - you cannot use the mechanism without understanding the parameters structure - but we still have a discovery approach to be able to get the list of mechanisms.
It is not unreasonable wanting to be able to know what interfaces are supported - independent of being able to actually use the interfaces.
Your suggested changes still wouldn't let an application discover the range of interfaces available.
For a class of applications that is important functionality we have omitted.
On Fri, Aug 10, 2018 at 2:19 AM, Daniel Minder <Daniel.Minder@utimaco.com> wrote:
Utimaco IS GmbH
Germanusstr. 4, D.52080 Aachen, Germany, Tel: +49-241-1696-0, www.utimaco.com
Seat: Aachen â Registergericht Aachen HRB 18922
VAT ID No.: DE 815 496 496
Managementboard: Malte Pollmann (Chairman) CEO, Dr. Frank J. Nellissen CFO
This communication is confidential. We only send and receive email on the basis of the terms set out at https://www.utimaco.com/en/e-mail-disclaimer/