Re: cleaning up courier-* packages

Buchan Milne wrote:

>> 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
If there is no standard directories for them, I think they could be kept
either in /etc/pki/tls directly (as openssl.cnf), or in
/etc/pki/tls/conf eventually. And flagged as config files, of course.

>> - standard handling of those files
>> - standard locations for SSL certs themselves
> 
> The directory to contain them seems to be fixed (and standardised between us, 
> RH/Fedora and SUSE IIRC) as /etc/pki/tls/certs, with keys 
> in /etc/pki/tls/private
I'd prefered /etc/pki/tls/keys :(

I guess combined certs+keys files should go in keys directory also.

> - standard locations for CRLs (without which, PKI can be entirely 
> compromised).
/etc/pki/tls/crls ?

> - standard locations for CA certs (taking into account different 
> assumptions/uses for CA certs, eg you wouldn't want to 
> use 'tls_cacertdir /etc/pki/tls/rootcerts' in /etc/ldap.conf).
From my current /etc/pki content, I guess it should be
/etc/pki/CA/certs, but I don't understand the need to keep them
separated from others.


>> 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 
> 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 generate 
> (and possibly sign) the cert isn't hardcoded into a macro, but rather a 
> 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 useless 
> for someone who has more stringent requirements (eg Sarbannes-Oxley-type 
> stuff).
> 
> And, let's be careful in noting different uses for SSL certs (eg trusting a 
> cert signed by a CA to provide access to a host vs trusting a cert to provide 
> some kind of verification for an online transaction are two very different 
> things).
We need a starting point anyway, so let's try different scenarios,
hardcoding command in spec file first. We can use courier-imap as a test
package, ssl certs handling have been removed from initscripts anyway :)

Here is a simple auto-signed certs generation scenario:
1) ship ssl upstream cert configuration file as /etc/pki/tls/imap.cnf,
tagged as configuration files
2) generate self-signed certificate in %post in initial installation only:
openssl req -new -x509 -days 365 -config /etc/pki/tls/imap.cnf -keyout
/etc/pki/tls/private/imap.pem -out /etc/pki/tls/certs/imap.pem

Sysadmin could just replace /etc/pki/tls/imap.cnf with its own one, and
use it as he want thereafter, without troubles during following upgrades.

This is achievable right now, and could already benefit from
standardising all our ssl-dependant packages.

A more complexe would be:
1) ship ssl upstream cert configuration file as /etc/pki/tls/imap.cnf
2) generate certificate request in %post:
openssl req -new -config /etc/pki/tls/imap.cnf -keyout
/etc/pki/tls/private/imap.pem -out /etc/pki/tls/req/imap.pem
3) generate crl in %post:
?
4) sign them using local CA:
openssl ca -in /etc/pki/tls/req/imap.pem -out /etc/pki/tls/certs/imap.pem

However, this is likely to require CA key passphrase, which would
prevent non-interactive installation, unless we have the passphrase
stored somewhere. This reminds me about automatic database creation on
installation discussions :/