OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: Please review proposal "Interfaces and Function Lists v2"


Hi Daniel –

 

I believe for #2 it could return 0 to N, where I don’t think we necessarily defined N (but it shouldn’t be an overly large number!). Initially, implementations will likely return both 2.40 & 3.0, but in time they may just return 3.0.

 

Returning 0 would be strange, and may be unexpected. We could define the behavior to always return 1 or more (up to N… N of 64?)

 

For #1 I am leaning toward option 3 (though in the document there seems to be 4? Variant 0, 1, 2, 3), I’m talking about 3 in this email.

 

Also, I agree, the interface names should have a max length. That should be added/used wherever referred to in the standard.

 

Thank you for doing this!


Valerie

 

From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of pkcs11-return-2186-valerie.fenwick=intel.com@lists.oasis-open.org
Sent: Thursday, September 6, 2018 1:37 AM
To: pkcs11@lists.oasis-open.org
Subject: [pkcs11] Please review proposal "Interfaces and Function Lists v2"

 

All,

 

as per yesterdays minutes, this is the friendly reminder to review my proposal "Interfaces and Function Lists v2".

The public download link is https://www.oasis-open.org/committees/download.php/63797/interfaces_and_functions_list_v2.docx

 

There are 2 main discussion points:

 

1. I’ve provided a proposal for C_GetInterfaceList and 3 variants of it. The proposal is similar to C_GetFunctionList, i.e. a pointer to the list of interfaces inside the library is returned. This is the most simple approach. In Variant 1, the application has to allocate a buffer for the char pointer array, but the actual interfaces names are still in the library. This was my original proposal but I think it does not really make sense. Variant 2 follows the style of C_GetAttributeValue when returning a template attribute. Big drawback is that you actually have to call it three times! I won’t recommend it but added it for completeness. In Variant 3 the interface name length is fixed. Actually, this is common in PKCS#11 and it might be preferred anyway. Thus, we could use variant 3 where the application allocates a buffer and library copies everything to that buffer, or we could use the proposal from the main part of the document, but set a fixed name length anyway.

 

2. Must “PKCS 11 2.40” and “PKCS 11 3.0” always be returned by C_GetInterfaceList or can C_GetInterfaceList also return only additional interfaces, which could be none?

 

Thanks,

Daniel

 

 



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]