[Freeipa-devel] DNSSEC design page

[Jan Cholasta]

On 25.2.2014 16:11, Simo Sorce wrote:
> On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote:
>> On 25.2.2014 15:11, Simo Sorce wrote:
>>> On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote:
>>>>> Any reason why we should follow in detail what softshm does ?
>>>> because I did't know what is really needed. If you want to have a
>>>> pkcs11
>>>> module, which stores data in ldap, I though it should have all the
>>>> attributes potentially needed.
>>>> Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP,
>>>> CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE,
>>>> CKA_EXTRACTABLE,
>>>> so there is at least one requirement for fine grained attributes.
>>>
>>> Does OpenDNSSEC store them as separate entities and need access to them
>>> independently ?
>> AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP schema
>> doesn't matter as long as our PKCS#11 module can derive all values defined by
>> standard.
>>
>> Honza, you did investigate OpenDNSSEC integration, please add some details if
>> you can.
>>
>>> Or is this internal use that can be satisfied by unpacking a blob in
>>> OpenDNSSEC ?
>>>
>>> What does bind9 uses ? Petr, can you provide example key files ?
>>
>> Private+public keys stored in files:
>> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html
>>
>> Private keys stored in HSM and public keys in files:
>> https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html
>> (I.e. some values in .private file are replaced by PKCS#11 label.)
>
> Ok it seem clear to me we do not need to spell out a lot of values when
> using pkcs#11 as bind doesn't need them in the key files. So I assume it
> can query the pkcs#11 module to find what it needs.
>
> I would use these key files as a sort of guide to understand what we
> need in LDAP. I would try to put in a single blob as much as we can that
> we do not explicitly need by a client querying LDAP directly.
>
> I think in order to nail down exactly what we need, at this point, we
> require some example use cases and queries the various clients would
> perform with spelled out what they are looking for to identify or
> manipulate keys.
>
> Simo.
>

See "How applications interact with PKCS#11" at 
<http://www.freeipa.org/page/V3/PKCS11_in_LDAP>. Tl;dr: applications 
don't search for keys by key data, but by metadata, so like I said in 
the other thread, key data can be in a single blob, but metadata should 
be in separate attributes.

-- 
Jan Cholasta