On Mon, 2007-10-15 at 16:07 -0400, seth vidal wrote: > On Mon, 2007-10-15 at 16:01 -0400, Karl MacMillan wrote: > > If you plan to use this cert infrastructure more broadly then my > > concerns about the weaknesses grow quite a bit. > > We can use the cert signing portion of the infrastructure for whatever > needs help communicating with certificates as auth. > > examples: > - yum can use the certs to talk to mod_auth_cert on apache to have > authenticated access to repositories > > - nagios can use it as a transport mechanism to do system checks and to > send alerts > > - cacti can use it as a better-authenticated way to gather system stats > > - puppet can use the certs as it does currently. > I certainly agree that cert infrastructure is useful and important. I would argue a few things: * It would be nice to abstract this kind of authentication / encryption where possible to allow the use of other methods (using things like SASL). I know you don't like kerberos, but it has many nice properties. Sometimes kerberos is better and sometimes certs are better - allowing admins to choose is probably best. * Putting this all on a distribution mechanism that appears to be vulnerable to man-in-the-middle attacks is only providing false security. * I know that you want very low infrastructure, but I think that you are quickly going to want a little more than you currently have if you succeed in getting certs widely distributed. Most obvious to me is revocation and automated renewal. We are working on similar things as part of freeipa.org. I'd appreciate it if you took a look at that and provided some feedback about how that doesn't meet your needs. > > But ssh would just be the transport / authentication mechanism that > > could be hidden. It could immediately exec a bit of python code that has > > the good parts of your current system. > > and then we don't get the benefit of the above, and we get to wrestle > with various layers in between. > What layers? For some of the projects above I agree that ssh wouldn't be a good option, but for func it would prevent you from exposing another very powerful daemon to the network. Karl