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: Optional Parameters?


Based on some recent threads regarding the addition of the CKA_PUBLIC_KEY_INFO attribute as an *optional* attribute, I realized that the use of optional parameters is becoming ‘more’ prevalent than in the past.  Which is not a judgment by any means, but something which caught me by surprise based on my older experiences with P11.  My recollection was that the general spirit of it was captured in the generalized statement from P11, Section 10, which is:

 

“Objects are always “well-formed” in Cryptoki—that is, an object always contains all

required attributes, and the attributes are always consistent with one another from the

time the object is created. This contrasts with some object-based paradigms where an

object has no attributes other than perhaps a class when it is created, and is uninitialized

for some time. In Cryptoki, objects are always initialized.”

 

Again, this is a statement about ‘spirit’ and obviously not a binding statement by any means, but I think captured it well.  The general feeling was that we wanted to avoid having application developers have to deal with multiple exception paths through their code where they had to do queries of every possible ‘optional’ parameter and then deal with the consequences of some times parameters being there and sometimes not.  Generally speaking, support for ‘default empty’ parameters creates the same sort of parsing requirement, although subtly different due to a check for ‘no value’ versus ‘not supported’.

 

Finally, although the current taxonomy strategy in the document is a little bit confusing (e.g. using footnotes on object attributes to indicate disposition during object instantiation operations), it doesn’t currently/accurately indicate which attributes might also be optional?

 

Regardless, I wanted to start a separate thread to discuss the concept of supporting optional parameters on objects in P11 – are people generally for them?  What are the pros/cons for each?  Right now, optional parameters are the exception, not the rule, so if we believe they add value, what changes to the spec are required to help out implementers and developers?  Should we change the wording the the spec to better document this fact?  Should we augment the taxonomy to more readily call out those parameters which are optional?

 

Thanks,

 

Bob

 

Robert Burns

Security Principal

THALES Information Systems Security

Phone: 954.888.6215

robert.burns@thalesesec.com

 



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