On 01.10.2013 12:32, Jan Cholasta wrote: > On 13.9.2013 11:05, Jan Cholasta wrote: >> On 13.9.2013 10:53, Martin Kosek wrote: >>> On 09/13/2013 10:51 AM, Jan Cholasta wrote: >>>> On 5.9.2013 10:28, Jan Cholasta wrote: >>>>> On 3.9.2013 18:16, Dmitri Pal wrote: >>>>>> On 09/02/2013 04:49 AM, Petr Spacek wrote: >>>>>>> It reminds me problems with key-rotation for DNSSEC. >>>>>>> >>>>>>> Could we find common problems and use the same/similar solution for >>>>>>> both problems? >>>>>>> >>>>>>> An extension for certmonger? Oddjob? Or a completely new daemon? >>>>>>> >>>>>> Certmonger already has a way to: >>>>>> 1) Check things periodically >>>>>> 2) Hand certs in different places >>>>>> 3) Run post op scripts >>>>>> >>>>>> IMO it is a good candidate but I would leave it to Nalin to chime in. >>>>>> >>>>> >>>>> I would expect more things that require periodic checking on clients >>>>> beyond certificates to come in the future, so I'm not sure if doing >>>>> this >>>>> in certmonger is the right thing to do. Also, SSSD already does a >>>>> similar thing for realm domains, right? >>> >>> Are you suggesting extending SSSD to handle that? >> >> Yes. >> >>> >>>>> >>>>> Honza >>>>> >>>> >>>> So, does anyone have any strong opinions on this? >>> >>> Not at this point. BTW, is there any reason why we cannot go the >>> simple way and >>> just utilize cron and a script? Previously we just dropped conf to >>> /etc/cron.d >>> for ipa-compliance script and it worked quite well. >> >> Hmm, that's so simple it might just work. At least until there is a >> better way. > > I have been thinking about this for some time now and came up with this > solution: > > Write a library implementing the PKCS#11 API (Cryptoki), which would > provide the shared CA certificates and associated information > (nicknames, trust flags). The library would get the certificates from > SSSD, which in turn would get them from IPA (and do the usual stuff like > caching). > > This library could then be used by IPA NSS databases as a source of > trust information for IPA services (see modutil). It could also be used > by p11-glue to provide the trust information to the rest of the system. > > Pros: > * Automatic support for getting trust information stored in IPA in all > the applications that understand PKCS#11. > * Certificates are fetched from IPA on-demand, not periodically like > in the previous solutions. > > Cons: > * Complexity of implementation? (I don't know about this one, I > briefly looked at the source code of the p11-kit PKCS#11 module and it > looked manageable to me.) > > Does this sound reasonable?
This sounds like the right approach to me. I've written several PKCS#11 modules, and am willing to help with a starter implementation, if that's needed. Stef _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
