Re: [pkcs11] Groups - pkcs11--protection-attrs.docx uploaded

[Michael StJohns <msj@nthpermutation.com>]

On 9/30/2013 11:47 AM, Michael StJohns wrote:
> Mainly because the current way of doing things doesn't actually work

I decided this needed a cleaner description.

The CKA_DERIVE et al attributes are non-sticky attributes in 2.40. They 
can be set to any value at any time either by copy, or by 
C_SetAttributeValue.  That pretty much makes them useless for enforcing 
key usages as anyone with the user credentials can change those usages.

The general rule I tend to follow in designing security things is "least 
privilege".  For these attributes, that would translate (for me) to "if 
the attribute is unspecified, it defaults to the most restrictive value" 
or CK_FALSE.  The problem with this specific set of attributes is that 
its desirable that those also be the "sticky" or final read-only 
values.  And that leads to some backwards compatibility issues where key 
creators may have first created the key without specifying the key usage 
attributes and then later set key usage attributes using 
C_SetAttributeValue.

That thought led to the language I used which mostly translates to "if 
unspecified, the attributes take on a value of CK_FALSE, but you still 
have one opportunity to set them to CK_TRUE.  If you specify them as 
CK_FALSE at any time, then they stay CK_FALSE forever."

But detecting a non-sticky CK_FALSE is problematic - hence the "trinary" 
approach which specified a default value that would be assumed for an 
unset attribute - but that a call to C_GetAttributeValue would get the 
error code indicating a missing attribute.  It allowed me to get the 
behavior I was looking for without massive changes.

Complex I know, but to be honest there's a lot of accreted cruft in the 
standard - I wouldn't do it this way if I were starting over.

I'm happy to go with "the sticky value for these attributes is CK_FALSE, 
and the default value applied during creation if not specified in the 
creation template is also CK_FALSE meaning that any desired usages must 
be fully specified during key creation"  as an alternative.  It may be a 
better - if more restrictive - approach the the one I proposed.

Mike