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
I'll add my opinion for the record:
I don't think it is a problem. We have *huge* schema full of almost never-used
attributes. Look at printerAbstract objectClass ...
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
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
Pros & Cons
pro 1] : one ldap attribute for each pkcs11 attribute.
* direct mapping of pkcs11attributes
* required or allowed attributes are defined in an objectclass
* huge number of schema attributes, which will probably not be needed
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!)
pro 2]: one ldap attribute with pkcs11 attributes as values
* smaller schema definition
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.
* possible to add new attributes/flags without extending the schema
IMHO any IPA-specific booleans should go to a separate object class to
separate them from pure PKCS#11 schema.
* 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 : One ldap attribute for each pkcs11
Freeipa-devel mailing list