Re: cleaning up courier-* packages

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 with 
> 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 subjectAlternativeName 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 that 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 should 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

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.

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.

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.