[Freeipa-devel] questions regarding ldap schema for pkcs11

[Petr Spacek]

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