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. Thanks, Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel