On Wed, 2014-02-26 at 15:04 +0100, 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.
Yep, and we also need to decide what master key is used and where it is placed, and who access it, and how :-) Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
