[Freeipa-devel] DNSSEC design page

[Jan Cholasta]

On 25.2.2014 20:22, Simo Sorce wrote:
> On Tue, 2014-02-25 at 13:22 -0500, Rob Crittenden wrote:
>> Jan Cholasta wrote:
>>> On 25.2.2014 17:36, Ludwig Krispenz wrote:
>>>>
>>>> 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 ?
>>>
>>> They are all metadata related to PKCS#11 operation. I don't think you
>>> can easily encode them in PKCS#8 or certificate blob, so they actually
>>> need to be split off. You can find the full list of them in the PKCS#11
>>> spec (link below).
>>>
>>>>>
>>>>> 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.
>>>
>>> I use mainly
>>> <ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf>, as
>>> 2.30 is a draft ATM.
>>>
>>>>
>>>> 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 :-)
>>>
>>> OpenDNSSEC puts it in public key objects it generates, so it's needed at
>>> least for the sake of it.
>>>
>>> Actually, I think we should support all of the metadata attributes, so
>>> that our PKCS#11 module is reasonably generic and not tailored to needs
>>> of a specific consumer.
>>
>> We could hardcode some of these values but it will very likely cause
>> problems later. It seems simple enough to just define schema for all of
>> them and store them, except perhaps in the cases where they are easily
>> derived. If we, for example, store the prime numbers and exponents, they
>> need to be protected as carefully as the private key.
>
> This is something I meant to discuss too, how do we protect them ?
> Clearly we have ACIs but I am wondering if we want to encrypt them with
> keys not immediately or easily available via LDAP ?
>
> It's kind of catastrofic if they get inadvertently exposed like if
> someone does a ldapsearch as "Directory Manager", which is one of the
> reasons why we encrypt kerberos key material before storing it into the
> db.

PKCS#8 allows encryption, I guess we can use that. There needs to be 
some metadata on how to decrypt the blob though, so that the PKCS#11 
module can actually decrypt it when necessary.

>
> Simo.
>


-- 
Jan Cholasta