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

     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

     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.

Petr^2 Spacek

Freeipa-devel mailing list

Reply via email to