[Freeipa-devel] DNSSEC design page

[Ludwig Krispenz]

On 02/25/2014 05:12 PM, Simo Sorce wrote:
> On Tue, 2014-02-25 at 16:18 +0100, Jan Cholasta wrote:
>> 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.
> Ah sorry, I hadn't looked at that one yet.
> It helps quite a bit.
>
> So are the class, key_type, id, label, token, 'sign' the only values we
> should really care to split off ?
>
> Can you describe what are these values ?
> What is class ? Why is it important, and how does it differ from
> key_type ?
> What is the token ? What is 'sign' ?
>
> Feel free to give references to specific documents to read up about
> these attributes.
I'm a newcomer to this area and am orienting myself at this doc: 
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf
and looking into opendnssec andsofthsm code.

It explains CKA_SIGN as:
"TheCKA_SIGN attribute of the signature key, whic h indicates whether 
the key supports signatures with appendix, must be CK_TRUE."
I cannot tell if this will be needed, just can make up an attribute and 
allow it in an objectclass :-)

But I think Jan's doc is a good start where he explains which attributes 
will be used by specific modules eg for searches.

>
> Thanks,
> Simo.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140225/dd6aa8bf/attachment.htm>