[Freeipa-devel] DNSSEC design page

[Rob Crittenden]

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

Splitting hairs, I think that one can search based on the cert DER which 
I guess represents the public key. You mean search by private key?

How do you plan to generate the CKA_ID? IIRC it needs to be unique per 
token and since this will be rather dynamically available. I think it's 
just a set of bytes so maybe a UUID is adequate.

I think you're on the right path defining these as discrete attributes. 
IMHO it will be worth submitting this as an RFC once the schema design 
is complete. So I wonder if the 'ipa' string should be dropped from the 
proposed schema. I guess that would also require specifying the other 
CKA values for other key types (e.g. DSA and DH).

In the schema ipaPkcs11prim1 is missing an 'e' I think and the comment 
should be CKA_PRIME_1.

rob