On 02/08/15 17:44, Christoph Anton Mitterer wrote: > On Sun, 2015-08-02 at 16:37 +0200, Daniel Pocock wrote: >> I apologize for not being more explicit, this is the sort of thing I >> was thinking too, it wouldn't be up to dpkg or postinst to guess or >> insist on a particular CA. Rather, it would be an optional prompt >> and there would be some script or function that postinst can call to >> help out. >> >> Having such a script would then mean having some menu where people >> can choose between letsencrypt or manual CSR or anything else that >> appears in future. >> >> Having the certificates in standard locations and using standard >> filenames would mean such a script could use existing certificates, >> sharing them between packages. This may also require some attention >> to managing groups for reading the private keys. >> >> A further issue that comes to mind is automatically managing >> different variations of PEM file. Some applications require the >> intermediate certs to be in the same PEM file as the server cert. >> Some require a PEM file containing both server cert and private key. >> Having standard filenames and locations for each permutation and a >> utility to recreate all the permutations each time the cert is >> renewed would make TLS much easier to support. > > Something like that should at least not automatically happen during > package installation. > > Some ideas that pop up in my mind: > - Would be yet another location of privacy leak in Debian, where the > system automatically calls "home" to some more commercial than > community organisations.
This would not be automatic. It would at least have to prompt people, "do you want to configure your SSL web server manually or do you want this postinst script to help you?". If people are running dpkg without showing questions of priority medium or low, it may leave SSL unconfigured for that package, so no privacy leak occurs. > - Why should Debian - as a neutral community organisation - push > Mozilla's letsecnrypt? > It has more or less the same inherent problems than the other CAs that > offer "free" certs,... so why not pushing for CAcert? Or StartSSL? > I think it's a bad development, that we get more and more "corporate" > into Debian. > We shouldn't push it any more than we push any other package. Just giving people the option of using it. If other CAs offer such a utility, that option could appear in some randomized order in the menu too. There would be some abstraction layer on top of the letsencrypt utility. > - People may automatically start using these certs, but given the > inherent problems of the strict hierarchical X.509 system, this also > means that one gives up control to e.g. letsencrypt, compared to self > -signed certificates where "I'm" under complete control, and not > potentially rogue or governmentally forced CA could issue forged > certificates for my name. There are obviously valid concerns about this. If this was a major showstopper though, then Debian wouldn't ship ANY libraries or applications for SSL/TLS. If such things are going to be part of Debian, we can make them easier to install. > - Some packages may just create such certs, but not be configured to > ever actually use them > That may depend on the quality of the postinst script. > - Your idea mentioned above, of using the same cert for different > services... > This has advantages and disadvantages, so both should be possible or at > least any such automatic handling shouldn't make it impossible for > users to do whatever they like. > If a user already has a suitable cert, it saves them the effort of requesting it again. There are various strategies for sharing the private key between different processes that need access to it. This sharing could be authorized by some prompt during package installation or using some utility. Behind the scenes, it may mean having a group for each key pair and adding all relevant applications to that group. > - And that later point is actually another concern. > Automatically handling such things (e.g. the certificates) often means > that certain constraints come up how things are expected in order to > work. > So any such automatic handling should be better darn good and > completely transparent. > That is why I suggest file locations as a first step in this project: if we document the file locations, permissions and strategies for the groups/owners before writing any new scripts, it will be transparent and robust. It will be possible for people to inspect and satisfy themselves that it is secure and people will be able to tweak it manually in cases where they are not satisfied with the scripts. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55be4a0c.80...@pocock.pro
