[Freeipa-devel] questions regarding ldap schema for pkcs11

[Jan Cholasta]

On 7.4.2014 15:07, Rob Crittenden wrote:
> 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.

Over the weekend I prepared a great argument about this and look, I am 
sick for one day and suddenly don't have to post it anymore :-)

Glad we reached an agreement on this.

Honza

-- 
Jan Cholasta