[Freeipa-devel] DNSSEC design page: PKCS#11 references

[Petr Spacek]

On 25.2.2014 18:26, 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.
>
>>
>> But I think Jan's doc is a good start where he explains which attributes
>> will be used by specific modules eg for searches.

This page contains couple interesting links to standards and related software:
https://wiki.opendnssec.org/display/DOCREF/PKCS11

-- 
Petr^2 Spacek