[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [pkcs11] ARRAY_ATTRIBUTE attributes
Darren, Tim, all, I also agree. And there is already a way to query at least a subset of attribute *values* by not setting ulValueLen and pValue for every array element and accepting
CKR_BUFFER_TOO_SMALL as final and expected answer… I think it’s difficult to find another solution due to the “unknown type” vs. CKA_CLASS ambiguity. I wish the original specification would have been different: in case of an array of attributes the pValue buffer will contain the index array AND all values, and each pValue
element inside the array is only an offset to the beginning of the buffer. Thus, any CKF_ARRAY_ATTRIBUTE attribute could be retrieved with 2 C_GetAttribute calls and 1 allocation only. Sigh… So, my proposal for the text would be (additions in bold): In the special case of an attribute whose value is an array of attributes, for example CKA_WRAP_TEMPLATE,
where it is passed in with pValue not NULL, *then its length specified in ulValueLen MUST be large enough to hold all attributes in the array*. If the pValue of elements within the array is NULL_PTR then the ulValueLen of elements within the array will
be set to the required length. If the pValue of elements within the array is not NULL_PTR, then the ulValueLen element of attributes within the array MUST reflect the space that the corresponding pValue points to, and pValue is filled in if there is sufficient
room. Therefore it is important to initialize the contents of a buffer before calling C_GetAttributeValue to get such an array value. *Note that the type of elements is always ignored on input and is always set in the output.* If any ulValueLen within
the array isn't large enough, it will be set to CK_UNAVAILABLE_INFORMATION and the function will return CKR_BUFFER_TOO_SMALL, as it does if an attribute in the pTemplate argument has ulValueLen too small. *Thus, it is possible to retrieve only a subset
of the element values by not allocating space and not setting ulValueLen and pValue for every element.* Note that any attribute whose value is an array of attributes is identifiable by virtue of the attribute type having the CKF_ARRAY_ATTRIBUTE bit set. Daniel From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org]
On Behalf Of Johnson Darren I agree with you. Given the current text in the standard, that is the only approach that makes sense. Trying to interpret the “type” values in the array becomes confusing/ambiguous.
The feature could be extend to allow retrieval of an individual attribute or subset of attributes, but I don’t see a strong need for that. Darren From:
pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org]
On Behalf Of Tim Hudson When looking into array attributes (like WRAP_TEMPLATE, UNWRAP_TEMPLATE, DERIVE_TEMPLATE) the specification text is a little on the under-detailed side of things. The discussion at
https://github.com/opendnssec/SoftHSMv2/issues/292 is worth reading through if you have had to tackle this. There are two ways to look at this item: 1) the attribute array is a single attribute you can fetch in one block as all-or-nothing 2) the attribute array is a collection of attributes and each attribute should follow the same rules This all comes down to when fetching the value with the usual "dance" a) set type b) set pValue = NULL c) set ulValueLength = 0 Call C_GetAttributeValue d) malloc space for pValue according to the ulValueLength value Call C_GetAttributeValue again When working with an array attribute the ulValueLen is the number of bytes to hold the array of CK_ATTRIBUTE values ... which you have to then malloc and initialise. For the malloced attribute array you then have to to the pValue=NULL, ulValueLength=0 dance to get the values back - but you don't have the type value to specify - as you don't know if. So should there be a call to get the type values or should they be explicitly ignored? S hould they be filled in by the implementation with the users input ignored? Is it possible/desirable to be able to fetch a subset of the array? The specification text is rather silent on this (it seems). C_GetAttributeValue "In the special case of an attribute whose value is an array of attributes, for example CKA_WRAP_TEMPLATE, where it is passed in with pValue not NULL, then if the pValue of elements within the array is NULL_PTR then the ulValueLen of elements
within the array will be set to the required length. If the pValue of elements within the array is not NULL_PTR, then the ulValueLen element of attributes within the array MUST reflect the space that the corresponding pValue points to, and pValue is filled
in if there is sufficient room. Therefore it is important to initialize the contents of a buffer before calling C_GetAttributeValue to get such an array value. If any ulValueLen within the array isn't large enough, it will be set to CK_UNAVAILABLE_INFORMATION
and the function will return CKR_BUFFER_TOO_SMALL, as it does if an attribute in the pTemplate argument has ulValueLen too small. Note that any attribute whose value is an array of attributes is identifiable by virtue of the attribute type having the CKF_ARRAY_ATTRIBUTE
bit set." I think a simple interpretation that it is an all-or-nothing fetch is appropriate and the implementation should explicitly ignore any type values specified by the caller (and ignore any array results which would not fit the whole array)
and when returning the lengths it should also return the type values (and when returning the actual results too). Tim. This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole
or partial, is prohibited. 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]