[debian-mysql] Bug#671534: Use case?

[Clint Byrum]

Excerpts from Nicholas Bamber's message of Sat May 05 12:00:49 -0700 2012:
> On 05/05/12 19:51, Russ Allbery wrote:
> > Nicholas Bamber<nicholas at periapt.co.uk>  writes:
> >
> >>     Although in general I am all for standardization, I am not
> >> actually clear about the use case here.
> >
> >>     The typical case to which you refer is a browser-like client
> >> talking to a webserver-like server using certificates checkable with
> >> external authorities.
> >
> >>     In the MySQL case both client and server must be using MySQL code
> >> at some level and the certificates are likely to be managed by an
> >> authority internal to the oganization.
> >
> > I don't really agree with your last assumption... or at least this isn't
> > true of us at Stanford.  We use commercial Comodo certificates for
> > anything internal that isn't just test/dev (and increasingly for that),
> > since we have a site-license for Comodo certificates and they're free.
> > There's no reason not to, and using a CA that's already built into various
> > software makes everything easier.  (This is likely common for US
> > universities that are part of Internet2, since Internet2 negotiated a
> > general agreement with Comodo.)
> >
> > But even apart from that, suppose it is managed by an authority internal
> > to the organization.  The obvious thing to do with the certificate for
> > that internal CA on a Debian system is to put it into
> > /usr/local/share/ca-certificates and then let ca-certificates add it to
> > all the other trusted CAs.  That way, certificates issued by your internal
> > CA will transparently work with anything on a Debian system that uses SSL,
> > not just web browsers.
> >
> > We use that same /etc/ssl/certs infrastructure for our internal Usenet
> > server, for the certificates for our LDAP servers, our SMTP servers, and
> > so forth.  (And indeed for LDAP and SMTP, even if you don't have free
> > commercial certificates, it's usually a good idea to get commercial
> > certificates so that you don't have to deal with the CA distribution
> > hassle.)
> >
> > Also, it's worth mentioning that anyone can get free trusted certificates
> > that will be verified by the /etc/ssl/certs infrastructure from
> > cacert.org.
> >
> > I suppose the drawback to using /etc/ssl/certs by default is that people
> > may not want to trust the commercial CA authorities by default, and there
> > are some reasons to be concerned about that.  But, there, I think the risk
> > for MySQL in most ways in which it's used is probably lower than for the
> > web browser, since the MySQL clients are more likely to be on controlled
> > networks and therefore less likely to be prone to easy man-in-the-middle
> > attacks.
> >
>  << fixed top post >>
> Russ,
> What if the location were configurable via debconf. (I  have not checked 
> if it is or not). The explanatory text could offer  your choice as a 
> possible location.
> 

I really dislike this idea. Debconf questions are for things that don't
have sane defaults. Perhaps if this were *low* priority and the default
was /etc/ssl/certs.

IMO, if you are centrally managing your own CA certs, you are more likely
to put them in /etc/ssl/certs than anywhere else. Why would we encourage
divergence from a positive pattern like that?

I think the idea is a good one, and would like to see it done at some
point.