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. - 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. - 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. - Some packages may just create such certs, but not be configured to ever actually use them - 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. - 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. On the other hand, adding functionality, that assists people - who want to use it - to create their letsencrypt certificates is surely a nice thing :-) ... and integrating it into the existing tools of course as well. Best wishes, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature