Simo Sorce wrote:
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

      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

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 ...).

I prefer the one-per-boolean as well and for the same reason: it doesn't require magic values defined elsewhere.


Freeipa-devel mailing list

Reply via email to