[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Please review proposal "Interfaces and Function Lists v2"
|
All, this is a friendly reminder to review the "Interfaces and Function Lists v2" proposal since we want to finish this tomorrow. In fact, we really need to do so since I will not be available until Oct 31st. So far, only Valerie provided feedback
– thanks Valerie! Some comments: For #2: The proposal in current working draft actually sets an upper limit (N). But this is unique in the PKCS#11 standard: at no other place there is a size limit for an array. This was the main motivation for my proposal, removing this
upper limit. #2 was a question what needs to be expected at minimum. For #1: Sorry for the confusion:
„variant 0“ is the original proposal at page 5 of the document, the others alternative implementations denoted as variants 1-3 starting at page 7. Thus, your interpretation was correct. Thanks, Daniel From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org]
On Behalf Of Fenwick, Valerie 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!
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 All, as per yesterday’s 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]