On Fri, 2014-04-04 at 13:19 +0200, Petr Spacek wrote: > On 4.4.2014 10:20, Ludwig Krispenz wrote: > > In the review discussion for the ldap schema for pkcs11 there was one topic, > > which we wanted to get the opinion from a broader audience before making a > > final decision. > I'll add my opinion for the record: > > > In pkcs11 there are many boolean attributes, like CKA_EXTRACTABLE, > > CKA_DERIVE, > > CKA_VERIFY and there are two suggestions how to represent them in ldap. > > > > > > 1] one ldap attribute for each pkcs11 attribute. > > This was my initial proposal to define a ldap attribute with boolean syntax. > > Most attributes have default values and need not to be present > > > > example: > > pkcs11extractable: true > > pkcs11derive: false > > pkcs11verify: true > > > > 2] one ldap attribute with pkcs11 attributes as values > > During the review Simo suggested to have a single attribute (or a few of > > them, > > key,cert,...) and for each pkcs11 attribute with value true add it as a > > value > > > > example: > > pkcs11keyFlags: CKA_EXTRACTABLE > > pkcs11keyFlags: CKA_VERIFY > > > > > > Pros & Cons > > > > pro 1] : one ldap attribute for each pkcs11 attribute. > > * direct mapping of pkcs11attributes > > * required or allowed attributes are defined in an objectclass > > > > con 1]: > > * huge number of schema attributes, which will probably not be needed > I don't think it is a problem. We have *huge* schema full of almost > never-used > attributes. Look at printerAbstract objectClass ... > > > pro 2]: one ldap attribute with pkcs11 attributes as values > > * smaller schema definition > IPA schema + all the RFCs created a huge pile of schema definitions already > and 389 can cope with it. (We are speaking about adding tens of attributes, > not hundreds or thousands!) > > > * possible to add new attributes/flags without extending the schema > Schema change is a little problem in comparison with updating clients (to get > any value from the new flag). Note that we are talking about booleans defined > by PKCS#11 standard so we can't add any boolean anyway. > > IMHO any IPA-specific booleans should go to a separate object class to > separate them from pure PKCS#11 schema. > > > > con 2]: > > * no input validation, application could set undefined flags > > * since presence of a flag means TRUE, and absence FALSE all default > > true values need to be present > > To conclude it - I like approach [1]: One ldap attribute for each pkcs11 > attribute. >
After much consideration I think one attribute per boolean is ok, I think the most convincing argument came from Honza when he said sometimes the default may depend on additional factors not explicit in the object, in that case setting or not setting a string would always be wrong and we would need to end up with additional definitions like: CKA_VERIFY_TRUE/CKA_VERIFY_FALSE as opposed to them missing which could indicate default (or we end up adding also CKA_VERIFY_DEFAULT ...). Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
