[Freeipa-devel] questions regarding ldap schema for pkcs11

[Rob Crittenden]

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

rob