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.

On Thu, 9 Aug. 2018, 2:47 am Daniel Minder, <Daniel.Minder@utimaco.com> wrote:

Tim, All,

Â

there is a list of two (2) standard interfaces according to the standard. All others are vendor defined.

Â

In order to use such an interface you need the structure of the function list anyway, for example CK_FUNCTION_LIST or CK_FUNCTION_LIST_2_42. (BTW: why _2_42 and not _3?) Sicne there is no reflection functionality, the vendor needs to deliver a matching struct together with his interface name. Youâll include both, the struct and the interface name and ask the lib if this specific interface is supported. If not, you cannot use it.

Â

But if a interface with an unknown name is supported you could not use it anyway. So why providing a function such as C_GetInterfaceList?

Â

And by the way: Looking at C_GetFunctionLists makes me shiver again. The number of interface_string elements is hidden in the interfaces structure, and why is there a limit of 10 elements? It would have been so much nices to have

C_GetFunctionLists(CK_CHAR **interface_string, CK_LONG ulInterfaceStringCount, void **pFunctions, CK_LONG flags);

Provide an array of ulInterfaceStringCount interface names and an empty array of void* with the same size as input and on output the void* is set to the function list ptr if the interface exists. Why does it need to be so complicated as proposed?

Yes, it was decided that way. It know that discussionâ

Â

Best,

Daniel

Â

Â

From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Tim Hudson
Sent: Dienstag, 7. August 2018 09:15
To: pkcs11@lists.oasis-open.org
Subject: [pkcs11] C_GetInterfaceList

Â

For 3.0 we have a function C_GetFunctionLists which lets us return the function lists for up to 10 named interfaces at a time - but we have no mechanism to return the full list of supported interfaces.

Â

I suggest we add a C_GetInterfaceList which returns the full list of known interfaces.

Â

CK_RV C_GetInterfaceList(CK_CHAR_PTR *pInterfaces);

Â

Where pInterfaces returns the pointer to the NULL terminated list of interfaces (in the same manner as C_GetFunctionLists requires it as the first parameter.

Â

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/

pkcs11 message