[Freeipa-devel] DNSSEC design page

Wed Feb 26 14:28:44 UTC 2014

Jan Cholasta wrote:
> 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.

Yes but if you are also storing the primes, modulus and exponents as 
attributes those will need to be protected as well. I don't think these 
need to, or should, be stored. They can be derived from the private key 
which as you point out, can be encrypted.

I'll note that the CA-specific design page doesn't call for storing 
these but the schema in the DNSSEC defines attributes for them. So I 
don't mean to suggest that you are advocating for storing them.

rob