RE: [pkcs11] ARRAY_ATTRIBUTE attributes

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
Sent: Wednesday, September 06, 2017 7:54 AM
To: pkcs11@lists.oasis-open.org
Subject: [pkcs11] ARRAY_ATTRIBUTE attributes

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.

pkcs11 message