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.
--
Petr^2 Spacek
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
