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


On 9/30/2013 6:08 AM, Stef Walter wrote:
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.

For 2.40, all necessary attributes have a value. For 3.0, I'm proposing to change that with a set of the key protection attributes. Mainly because the current way of doing things doesn't actually work and doing that change is the least intrusive as it only is obvious the value is unset if you use C_GetAttributeValue. Otherwise, the "behavior" of an unset object is that it takes on a default value and protection calculations are done using that default.

I considered creating a trinary type (or actually a quatenary type), but that would mostly mean deprecating all of the existing CKA_DERIVE, CKA_ENCRYPT etc attributes. This seemed less disruptive.



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.

Mostly won't work. Currently the 8 or so (not going back and counting right now) attributes that control the use of derives, encrypts etc are NOT sticky. They can be set or changed at any time (barring a specific token implementation that prohibits it). The appropriate default for any of this set of attributes is CK_FALSE, but you have to be able to then set at least one of these to CK_TRUE at some point, and you want CK_FALSE - as a set value, not a default unset value - to be sticky (read-only when set) giving me the need for a way of dealing with unset values.

Some Alternatives: Require the entire group of these attributes to be set at creation with all of the defaults being CK_FALSE; - OR- set the values at creation from the key type (e.g. all secret keys get sign, verify and encrypt and decrypt set to true, the rest set to false); - OR - set the non-specified values at creation to CK_TRUE. That last means that all the values would have to be explicitly set to ensure the appropriate key protection.

All of the above would still require CK_FALSE as a set value to be sticky.






  b) Rework PKCS#11 so that we have the concept of unset values (this
     brings a lot of complexity and needs associated benefits).
That's where I want to go I think. It is the cleanest approach to adding stickyness to the complete set of protection attributes.

  c) Actually make these a trinary value instead of CK_BBOOL.
Quaternary actually - CK_FALSE_UNSET, CK_TRUE_UNSET, CK_FALSE, CK_TRUE ??

Or CK_UNSET (which is represented by an error return these days) as a general value - but then need type specific versions for templates and arrays.


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.

If you create a non-modifiable object, and I can trivially change it by copying it, I would say that you haven't created a non-modifiable object.

I agree more discussion is necessary here. If it *is* possible to modify an non-modifiable object on copy, it needs to be clearly spelled out what happens on copy.


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.

No. There are 4 combinations of CKA_DESTROYABLE and CKA_TOKEN. Unless there is language similar to the above that explains that a session non-destroyable (CKA_DESTROYABLE = false, CKA_TOKEN=false) only persists through the end of the session, an implementer could believe that CKA_DESTROYABLE trumps CKA_TOKEN and that setting CKA_DESTROYABLE to false will prevent an object from being destroyed even if it is nominally a session object.



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.

Wrong. CKA_TOKEN is modifiable on copy. It says so right in the text for storage object.

The above text says if you copy a non-destroyable session object to become a token object (e.g. specify CKA_TOKEN=true in the copy attributes), and don't explicitly specify CKA_DESTROYABLE=false as one of the copy attributes, the token object takes on a CKA_DESTROYABLE=true attribute.

The last sentence needs to be removed though - I was thinking of calls to C_SetAttributeValue on CKA_TOKEN and you are correct that the attribute can't be modified that way.



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.
Nope. A read-only attribute is simply read-only. A sticky attribute is only read-only once it is set to a specific defined value.



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

2.40 vs 3.0. I'm willing to remove the unset language, but then we need to figure out language that works to make CKA_DERIVE et al sticky in a useful way.


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

Not exactly - and in fact for RSA private keys, not at all (because of the multiple ways of storing RSA private keys - its actually in the text). All appropriate values for any given object are supposed to have values.
, and ones that were
explicitly set are indistinguishable from ones that have assumed default
values.

With current language, maybe. But I can can still call C_GetAttributeValue and differentiate between set and unset attributes.


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.

Hmm... no, I think this needs to be changed back to private and secret. CKA_PRIVATE needs to apply to all storage objects. I'm not sure what the use of a CKA_SENSITIVE=true for a certificate would be as there aren't any "sensitive" fields. Same thing for a CKO_DATA object - if one of the fields is sensitive, how does it get used.

I'll fix this - nice catch.



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.

That's pretty much the goal here along with stickyness.


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,
As I noted in the commentary, I added text here to make sure I considered any interactions. This does need to be done as a separate proposal (and actually has been in a slightly different form).
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?

*sigh* I'll let you and Tim fight whether or not this should be applicable for more than just keys. I proposed that, Tim said I was overreaching and I didn't need to specify it for all objects. Hence the above which is specific to just keys and specific to keys that can wrap keys.

With respect to length - pick one. There's no need for arbitrary length and a lot of reasons to at least specify a minimum length. I'm not sure you gain anything with greater than 16 octets of randomness.



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?
Define a CKM_NO_MECHANISM mechanism and set it.  I'll add that.

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?

Goal: That this attribute become sticky, so that an attacker can't trivially add a mechanism we don't want him to add.

If you specify that the default is all of the mechanisms, then the stickyness has to be by mechanism (e.g. you have to be able to re-specify this array based attribute by specifying a new group of mechanisms which exclude one or more of the previous mechanisms.

And then this gets back into the whole "default unset" discussion.

Your turn - write a policy blurb for CKA_ALLOWED_MECHANISMS that can be defined as sticky.


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?

It can't be fixed. Not for the key wrapping use. Hence the CKA_WRAP_WITH_KEYID stuff.








[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]