Re: cleaning up courier-* packages

--nextPart2486504.ue1bNThyBP
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Wednesday 24 May 2006 12:00, Guillaume Rousse wrote:
> Buchan Milne wrote:
> >> Second issue, the SSL stuff handling. Is there any specific instruction
> >> how to handle certs configuration, cert files and cert files generation
> >> now ?
> >
> > I've been meaning to discuss this issue, but haven't had enough time ...
> >
> >
> > There are separate use cases to consider.
> >
> > 1)Where you want to trust all commercial CAs (eg web service/browser wi=
th
> > commercial certs)
> >
> > 2)Where you want to trust only a specific CA (eg VPN server with
> > authentication via SSL certs, LDAP server allowing access based on SSL
> > cert - sasl-external - authentication).
> >
> > Secondly, it would be nice to have tools to handle the different ways to
> > generate certs:
> >
> > -self-signed
> > -local trivial CA (eg openssl ca, or CA.pl etc)
> > -full-blown CA with SCEP or OCSP support (eg with OpenCA as CA, which
> > supports SCEP enrolment)
> >
> >
> > I am more interested in the last case, and it is also the more complex
> > one, but there is some software to look after certificates:
> >
> > -CertNanny (http://www.cynops.de/oss/CertNanny/)
> > -autosscep (http://autosscep.spe.net/eng/) (in contrib)
> >
> > Both of these are derived from sscep (http://www.klake.org/%7Ejt/sscep/=
),
> > however it hasn't been updated for some recent changes to SCEP (which
> > OpenCA seems to expect - so OpenCA gets the SCEP request but most
> > attributes are missing).
> >
> >
> > autosscep seems a more comprehensive tool (multiple certs, different CAs
> > for each cert, various uncommon attributes such as subjectAlternativeNa=
me
> > etc), but CertNanny has a patched version of sscep which should be able
> > to enrol to OpenCA (I haven't tested yet). I've been meaning to try and
> > patch autosscep with the changes shipped in the patch to sscep with
> > CertNanny ... but well ...
> >
> > IMHO, ideally we would want autosscep, with a %post_ssl or similar macro
> > to add a cert to the autosscep config file (or a separate config file in
> > a specific directory), and a cron job in an autosscep package to check
> > each cert/config daily (or similar).
> >
> > Finally, the remaining issues of CRLs etc, which is an important aspect
> > of PKI which is not addressed by any standards (in terms of ensuring th=
at
> > all software gets an up-to-date CRL). The various SCEP tools can/should
> > be able to update CRLs, and it would be a good idea to try and ensure
> > that CRLs are configured.
> >
> > (I am trying to finish up packaging of eas - http://eas.strchr.net/ -
> > which may have wider requirements for this, as each node using eas shou=
ld
> > have it's own cert - and ideally you want every node to use eas).
> >
> > If we can find the common-ground required by the different scenarios, we
> > can start writing some scripts/macros which implement the various
> > options.
>
> They are two issues here, achievability and desirability.
>
> For achieability, the scenario seems a bit complex, and I'd prefer to
> start with simpler issues, such as:
> - standard locations for SSL configuration files used to create
> certificates - standard contents for those files
> - standard handling of those files
> - standard locations for SSL certs themselves

The directory to contain them seems to be fixed (and standardised between u=
s,=20
RH/Fedora and SUSE IIRC) as /etc/pki/tls/certs, with keys=20
in /etc/pki/tls/private

=2D standard locations for CRLs (without which, PKI can be entirely=20
compromised).
=2D standard locations for CA certs (taking into account different=20
assumptions/uses for CA certs, eg you wouldn't want to=20
use 'tls_cacertdir /etc/pki/tls/rootcerts' in /etc/ldap.conf).

> For desirability, your prefered scenario (the most complex) seems to
> involve too much assumptions about user specific needs. As packagers,
> we're supposed to polish softwares issued from different developement
> teams, and provide the minimal stuff needed to run them, not replace
> sysadmins.

Indeed, but no point doing an implementation which precludes re-use by=20
sysadmins to implement the preferred scenario.

> My point is that over-configuration hurts, and we should rather focus on
> minimal harmonisation between packages, letting sysadmins finish
> configuration, rather than arguing about the ultimate default
> configuration everyone will have to change anyway. And the more advanced
> use-case you try to automatically enforce, the higher the chance they
> will differ from user own needs.

Well, no, as long as the tool called (and it's arguments) to actually gener=
ate=20
(and possibly sign) the cert isn't hardcoded into a macro, but rather a=20
configureable script, it should not be that different.

> For all of those reasons, I'd prefer to try to achieve the intermediate
> scenario only (local trivial CA), and see thereafter if further
> enhancement is really needed.

Let's just not make short-sighted assumptions that would make it all useles=
s=20
for someone who has more stringent requirements (eg Sarbannes-Oxley-type=20
stuff).

And, let's be careful in noting different uses for SSL certs (eg trusting a=
=20
cert signed by a CA to provide access to a host vs trusting a cert to provi=
de=20
some kind of verification for an online transaction are two very different=
=20
things).

Regards,
Buchan

=2D-=20
Buchan Milne
B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592)

--nextPart2486504.ue1bNThyBP
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBEdDwMrJK6UGDSBKcRAoxaAJ9p8O1LBF7k7ye3Zlo3tPxJ4tpC2wCbBwgf
9V0dqoN1m6Ve9GGMD5Laozk=
=X91l
-----END PGP SIGNATURE-----

--nextPart2486504.ue1bNThyBP--