Re: cleaning up courier-* packages

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

On Monday 22 May 2006 16:49, Guillaume Rousse wrote:
> Oden Eriksson wrote:
> > s=F6ndagen den 14 maj 2006 17.39 skrev Guillaume Rousse:
> >> I started a large cleanup of courier packages (courier-authlib, and
> >> courier-imap). I already get rid of triggers, duplicated config files,
> >> and replaced original initialisation system with a standard one.
> >>
> >> I'm curious however about the usefulness of conditional build options
> >> and care about packages non included in the distribution, such as
> >> vpopmail support in courier-authlib, and renaming of maildirmake in
> >> courier-imap to avoid conflict with qmail. Are they really useful ?
> >> Because otherwise, I'd rather drop them: simpler packages are easier to
> >> maintain.
> >
> > No, you can do what you want here. If you choose to upgrade courier-imap
> > to 4.x there is no more vpopmail support.
> >
> > Thanks for taking the time.
>
> I'm currently investigating the dlopen issue with upstream developpers,
> but I have other issues in mind.
>
> The first one is package and file naming. Current one strictly reflect
> upstream distribution:
> - courier-authlib subpackages are named courier-authlib-foo
> - courier-authlib subpackages have their configuration in
> /etc/courier-autlib
> - courier-imap subpackages are named courier-imap-foo
> - courier-imap subpackages have their configuration in /etc/courier-imap
>
> Another repartition would be to only keep a short courier-prefix to all
> subpackages, whatever their exact upstream distribution:
> - courier-authdaemon
> - courier-imap
> - courier-pop
> - courier-authlib
> And to have all configuration files under /etc/courier
>
> I find the second one more logical from user point of view.
>
> 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 with=20
commercial certs)

2)Where you want to trust only a specific CA (eg VPN server with=20
authentication via SSL certs, LDAP server allowing access based on SSL cert=
 -=20
sasl-external - authentication).

Secondly, it would be nice to have tools to handle the different ways to=20
generate certs:

=2Dself-signed
=2Dlocal trivial CA (eg openssl ca, or CA.pl etc)
=2Dfull-blown CA with SCEP or OCSP support (eg with OpenCA as CA, which sup=
ports=20
SCEP enrolment)


I am more interested in the last case, and it is also the more complex one,=
=20
but there is some software to look after certificates:

=2DCertNanny (http://www.cynops.de/oss/CertNanny/)
=2Dautosscep (http://autosscep.spe.net/eng/) (in contrib)

Both of these are derived from sscep (http://www.klake.org/%7Ejt/sscep/),=20
however it hasn't been updated for some recent changes to SCEP (which OpenC=
A=20
seems to expect - so OpenCA gets the SCEP request but most attributes are=20
missing).


autosscep seems a more comprehensive tool (multiple certs, different CAs fo=
r=20
each cert, various uncommon attributes such as subjectAlternativeName etc),=
=20
but CertNanny has a patched version of sscep which should be able to enrol =
to=20
OpenCA (I haven't tested yet). I've been meaning to try and patch autosscep=
=20
with the changes shipped in the patch to sscep with CertNanny ... but=20
well ...

IMHO, ideally we would want autosscep, with a %post_ssl or similar macro to=
=20
add a cert to the autosscep config file (or a separate config file in a=20
specific directory), and a cron job in an autosscep package to check each=20
cert/config daily (or similar).

=46inally, the remaining issues of CRLs etc, which is an important aspect o=
f PKI=20
which is not addressed by any standards (in terms of ensuring that all=20
software gets an up-to-date CRL). The various SCEP tools can/should be able=
=20
to update CRLs, and it would be a good idea to try and ensure that CRLs are=
=20
configured.

(I am trying to finish up packaging of eas - http://eas.strchr.net/ - which=
=20
may have wider requirements for this, as each node using eas should have it=
's=20
own cert - and ideally you want every node to use eas).

If we can find the common-ground required by the different scenarios, we ca=
n=20
start writing some scripts/macros which implement the various options.

Regards,
Buchan

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

--nextPart1239450.jCWxrso7Sh
Content-Type: application/pgp-signature

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

iD8DBQBEceMdrJK6UGDSBKcRAgr2AJ9W4y0OUgC+XNZBvSfw3cv8lSGC4QCfdhbi
jyEV/9wAYijGLrqZLyDZWCM=
=B3cF
-----END PGP SIGNATURE-----

--nextPart1239450.jCWxrso7Sh--