[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11] C_GetInterfaceList
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.Tim.On Fri, Aug 10, 2018 at 2:19 AM, Daniel Minder <Daniel.Minder@utimaco.com> wrote:Tim, All,
I fully agree on the expectation that there will many small interfaces in the future and that applications need to discover whatâs there. However, I come to a different conclusion.
If I understand you correctly, an application would work as follows:
- Call C_GetInterfaceLists to get the list of interfaces supported by the PKCS#11 API.
- Iterate through the returned list and check which of these names are known to the application (i.e. for which a matching function pointer structure exists)
- Select the final interface set the applications wants to work with and create new array(s) of names, max array size is 10 names.
- Pass this/these array/s to C_GetFunctionLists to get the actual function pointers for the interfaces.
However, itâs also possible to work without C_GetInterfaceLists since C_GetFunctionLists does not require to try out every possible combination â it just sets the pFunctions pointer to NULL it the interface does not exist:
- Application can have static arrays of names that it can work with (i.e. for which a matching function pointer structure exists). Again max array size is 10 names.
- Pass this/these array/s to C_GetFunctionLists to get the actual function pointers for the interfaces â or the information that this interface is not supported.
- Iterate through the returned array and check which interfaces are available and select the final interface set.
Going one step further: We expect that there will be many small interfaces. Thus, the limitation to 10 interfaces / function pointers seems to be small already. Moreover, itâs the first time and only example in the PKCS#11 API where an array is limited to an arbitrary number of elements. Therefore, I suggest to change the original proposal and remove this limitation.
There are different approaches to do so. Let me propose one that also fulfils Timâs requirements on getting an interface list.
CK_FUNCTION_LISTS stays almost as it is (IMO we donât need a ptrptr for pFunctions), but CK_INTERFACES can be removed:
typedef struct {
CK_CHAR *pInterface;
void *pFunctions;
} CK_FUNCTION_LISTS;
CK_DECLARE_FUNCTION(CK_RV, C_GetFunctionLists)(
CK_FUNCTION_LISTS_PTR_PTR ppFunctionLists
);
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 null-terminated 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.
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.
(Note: The last sentence also needs to be changed for C_GetFunctionList.)
Now, implementing this in the PKCS#11 library is quite easy:
CK_FUNCTIONS_LISTS MyP11LibFctLists[] = {
{ "PKCS 11 2.40", &MyP11Lib240Fcts },
{ "PKCS 11 3.0", &MyP11Lib30Fcts },
{ "Vendor Utimaco:Internals 1.0", &MyP11LibIntFcts },
{ NULL, NULL }
};
An application can now just do (for example, simplified):
CK_FUNCTIONS_LISTS_PTR pFunctionsLists, pCurrentInterface;
CK_FUNCTION_LIST_3_0_PTR pFunctions30 = NULL;
CK_FUNCTION_LIST_UTIMACO_INTERNALS_PTR pFunctionsUtiInt = NULL;
C_GetFunctionsLists(&pFunctionsLists);
for (pCurrentInterface = pFunctionsLists; pCurrentInterface->pInterface; ++pCurrentInterface)
{
if (strcmp(pCurrentInterface->pInterface, "PKCS 11 3.0") == 0)
pFunctions30 = pCurrentInterface->pFunctions;
else if (strcmp(pCurrentInterface->pInterface, " Vendor Utimaco:Internals 1.0") == 0)
pFunctionsUtiInt = pCurrentInterface->pFunctions;
}
// then check if pFunctions30 and pFunctionsUtiInt are NULL and act accordingly
Easy, no array restrictions, fully transparent and yet full control.
Best,
Daniel
From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Tim Hudson
Sent: Mittwoch, 8. August 2018 21:51
To: pkcs11@lists.oasis-open.org
Subject: Re: [pkcs11] C_GetInterfaceList
The expectation is that all those vendors that currently have their substantial lists of extension functions will break them into various smaller sets of interfaces and document them going forward.
You will need to know the matching function pointer structures to use them and there are existing applications which do "discovery" to figure such things out.
Being able to get a list of what is supported is important functionality to being able to know what is possible without basically trying every possible combination of which there will be more than 10 if vendors break things up in a fine grained manner.
And we will ourselves extend that list over time and need to know what standard versions are supported as vendors are not required to support all versions. Thinking ahead to PKCS#11 version 3.255 we could have many function lists and we may not want to have to carry around a full superset function table for everything always - we may move to a set of separate interfaces for groups of functions inside one version.
The concept was to avoid being in the situation where adding functions had a major barrier going forward.
And hopefully we can get some of the vendor extension ideas more visible and shared going forward.
Tim.
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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]