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: [pkcs11] Groups - pkcs11--protection-attrs.docx uploaded


In all I think it's very helpful to have this clearly spelled out for
implementers. I do have a few comments below though...

Cheers,

Stef

> 1.1. Protection Attributes ... Note: Most "boolean" attributes are 
> actually trinary in implementation.  They have three states: unset, 
> CK_TRUE, or CK_FALSE. The "unset" state has an operational default 
> value of either CK_TRUE or CK_FALSE as described.

All PKCS#11 attributes have a value, whether it was manually specified
or not, and are not "unset". If you wish to change this, then this is a
fundamental change, and needs corresponding reworking and related
infrastructure.

In particular it is not possible to differentiate between an attribute
that was not set and contains a documented default value, or one that
was explicitly set to the documented default value.

A trinary where you cannot differentiate between two of the states is
not a trinary at all.

It seems you'll need to either:

 a) rewording this section, so that we don't refer to these an trinary
    and make them work within the current PKCS#11 default value
    concepts.

 b) Rework PKCS#11 so that we have the concept of unset values (this
    brings a lot of complexity and needs associated benefits).

 c) Actually make these a trinary value instead of CK_BBOOL.

> 1.1.1.1. CKA_MODIFIABLE ... In addition, if an object is 
> non-modifiable, none of the attributes of the object may be modified 
> during a call to C_CopyObject.  The resultant object must have 
> exactly the same attribute set as the object from which it was 
> copied.

I'm not sure I agree with this point. One of the primary reasons for
copying an object is to make a second version with changed attributes.
Otherwise a copied object will be identical to the first. Again,
remember that all attributes in a PKCS#11 are set, and therefore even
those attributes not explicitly set during a C_CreateObject (or similar)
and which contain default values are protected by CKA_MODIFIABLE.

In the end, I don't think CKA_MODIFIABLE should affect C_CopyObject at
all. It doesn't make sense to have CKA_MODIFIABLE change C_CopyObject so
it just produces an identical object. Anyways, CKA_COPYABLE is the
attribute for controlling C_CopyObject behavior.

> 1.1.1.3. CKA_DESTROYABLE ... If this attribute is set to CK_FALSE, 
> then if the CKA_TOKEN attribute is set to CK_TRUE (e.g. a token 
> object), the object is persistent until the token is reinitialized 
> through a call to C_InitToken, or zeroized through non-PKCS11 means.
>  Otherwise, if the object is a session object, setting the attribute
>  to CK_TRUE causes the object to persist until the session is 
> terminated.

This sentences is confusing and/or uneccessary. When token is
reinitialized or session is terminated objects are handled identically
regardless of what CKA_DESTROYABLE is set to. The only difference is
whether C_DestroyObject can be called, which you already noted in
preceding text.

> 1.1.1.3. CKA_DESTROYABLE ... If a non-destroyable session object is 
> changed to a token object, unless the call to C_SetAttributeValue 
> includes a specific setting for CKA_DESTROYABLE, the call will
> remove the setting for that attribute on the token object (e.g. the
> object will take on the default value for CKA_DESTROYABLE).  This
> ensures that an implementation will not inadvertently create
> non-destroyable token objects. If a non-destroyable object is also a
> token object, it may NOT be changed into a session object.  E.g., if
> a token object is non-destroyable, its CKA_TOKEN attribute is
> read-only and has a value of CK_TRUE.

This text doesn't make sense. It is not possible to change an object
from a token to a session object or vice versa. CKA_TOKEN is never
modifiable.

> 1.1.2. General Sensitivity Attributes ... An attribute value of 
> CKA_TRUE is sticky; once the object has been set to private, it may 
> not be set to public; once set to sensitive, it may not be set to 
> non-sensitive.  These attributes never have an unset state.

We refer to non-changeable attributes as 'read-only' instead of 'sticky'
in the specification: among other things we have a
CKR_ATTRIBUTE_READ_ONLY return code. I suggest using 'read-only' here.

There are no attributes in PKCS#11 that have an unset state. So I don't
think we should refer to that here.

It is completely outside the spec if some implementation chooses to not
store attributes which have not been explicitly set. However with
regards to the spec, all attributes have values, and ones that were
explicitly set are indistinguishable from ones that have assumed default
values.

> 1.1.2.2. CKA_SENSITIVE ... This attribute is mandatory for all 
> storage objects.

This is not currently the case. Although I'm not against a proposal
which would make CKA_SENSITIVE a storage object attribute rather than
one specific to private and secret keys.

> 1.1.3. Key Usage Attributes [[NEW::::::  The above attributes are 
> inter-related and must be set as a group.  In any call to 
> C_SetAttributeValue, C_GenerateKey, C_DeriveKey, C_UnwrapKey or 
> C_GenerateKeyPair which contains at least one of these attributes in 
> the provided template or templates results in ALL of the 
> non-specified attributes from this list being set to CK_FALSE.  This 
> means that the key usage(s) for a key may be set once and not
> further modified. :::::]][[ This seems to be a reasonable approach -
> it allows the key creator to only specify the attributes it wants to
> set to true and locks all of the rest as false which is the usual
> case. Thoughts???  It's an optimization, but I don't see a lot of 
> downside]]

FWIW, Having a default value of an non-explicitly set attribute depend
on the value of an explicitly set attribute has precedent in the spec.

This would need to be clearly documented in all relevant places.

There is an one additional benefit to this new behavior: If a new key
usage attribute were to be added to the spec, then callers would not
need to be retrofitted to set it to its 'secure' or failsafe setting.

> 1.1.4.5. [[CKA_WRAPPING_KEYID]]

Although I'm not against the concept of having an "ETag" [1] type
identifier attribute in PKCS#11 which lets callers tell whether objects
have changed, or whether two objects are identical...

... I think this should be its own proposal, and should not be specific
to key objects. In addition I'm not sure why it's limited to 16 bytes.
Couldn't it be arbitrary length?

> 1.1.5.1. CKA_ALLOWED_MECHANISMS ... This attribute is used to
> restrict the set of mechanisms that may be used with a particular
> key.  The value of this attribute is an array of CK_MECHANISM_TYPE[]
> of any length.  It has a default value of a zero length array.  Once
> set to an array length of greater than 0, it becomes read-only.

Why does the attribute only become read-only when an array length
greater than zero? What if one wants to enforce that no mechanisms are
allowed?

And why is the default value a zero length array? Shouldn't it be the
all of the mechanisms that an implementation can use with a given key?

> 1.1.5.2. CKA_TRUSTED
...
> This boolean attribute has a default and unset value of CK_FALSE.  It
> may only be set to CK_TRUE by the CKU_SO or by proprietary means
> external to PKCS11.  Note that this implies that CKO_SECRET_KEY
> objects that require this attribute to be set to CK_TRUE will have to
> be public objects (CKA_PRIVATE == CK_FALSE) at some point to allow
> the attribute to be set.  The value of CK_FALSE is effectively sticky
> without the intervention of the security officer.

This is pretty broken, and we should fix this somehow rather than
enshrining the brokenness. What are the use cases that people expect here?




[1] http://en.wikipedia.org/wiki/HTTP_ETag


On 27.09.2013 00:05, Michael StJohns wrote:
> *Document Name*: pkcs11--protection-attrs.docx 
> <https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=50839>
>
>
>
>
>
>
>
>
>
> 
------------------------------------------------------------------------
> *Description* This is a replacement/augmentation for the description
>  of attributes used to describe the protection requirements for
> PKCS11 objects. Download Latest Revision 
> <https://www.oasis-open.org/apps/org/workgroup/pkcs11/download.php/50839/latest/pkcs11--protection-attrs.docx>
>
>
>
>
>
>
>
>
>
> 
Public Download Link
> <https://www.oasis-open.org/committees/document.php?document_id=50839&wg_abbrev=pkcs11>
>
>
>
>
>
>
>
>
>
> 
------------------------------------------------------------------------
> *Submitter*: Michael StJohns *Group*: OASIS PKCS 11 TC *Folder*: 
> Working Drafts *Date submitted*: 2013-09-26 15:05:16
> 



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