-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
is there any documentation available that tells how to use the directory structure in /etc/pki?
Some applications (e.g. bittorrent and dovevot) create directories /etc/pki/[appname] and store their own certificates inside. Others (e.g. openldap-servers) put their certificates in /etc/pki/tls/certs.
I think there should be a consistent behavior regarding /etc/pki.
Joachim - -- B. Sc. Joachim Selke Universität Hannover, Institut für Theoretische Informatik Appelstraße 4, 30167 Hannover, Germany http://www.thi.uni-hannover.de/
On Thu, 2006-07-20 at 12:41 +0200, Joachim Selke wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
is there any documentation available that tells how to use the directory structure in /etc/pki?
Some applications (e.g. bittorrent and dovevot) create directories /etc/pki/[appname] and store their own certificates inside. Others (e.g. openldap-servers) put their certificates in /etc/pki/tls/certs.
I think there should be a consistent behavior regarding /etc/pki.
would you be willing to go through all the packages in extras and core and find the ones and what they're doing?
You should be able to use repoquery to do the lookup of what packages are putting files in there pretty quickly.
-sv
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
seth vidal wrote:
I think there should be a consistent behavior regarding /etc/pki.
would you be willing to go through all the packages in extras and core and find the ones and what they're doing?
I will do that. I also have some ideas how /etc/pki should be used. Give me one or two days for thinking about it and creating the package list.
Joachim - -- B. Sc. Joachim Selke Universität Hannover, Institut für Theoretische Informatik Appelstraße 4, 30167 Hannover, Germany http://www.thi.uni-hannover.de/
On Thu, 2006-07-20 at 14:23 +0200, Joachim Selke wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
seth vidal wrote:
I think there should be a consistent behavior regarding /etc/pki.
would you be willing to go through all the packages in extras and core and find the ones and what they're doing?
I will do that. I also have some ideas how /etc/pki should be used. Give me one or two days for thinking about it and creating the package list.
Great. Thanks, -sv
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
seth vidal wrote:
I think there should be a consistent behavior regarding /etc/pki.
would you be willing to go through all the packages in extras and core and find the ones and what they're doing?
Here we go.
/etc/pki/ * It is created empty by the filesystem package.
/etc/pki/rpm-gpg/ * It is created by the fedora-release package and contains the package certificates of the standard yum repositories.
/etc/pki/CA/ /etc/pki/CA/private/ * They are created empty by the openssl package. I think they are intended to be used for a local certificate authority. If so, then /etc/pki/CA/private/ contains the keys generated. Maybe a directory for storing public certs is missing.
/etc/pki/tls/ /etc/pki/tls/certs/ /etc/pki/tls/private/ /etc/pki/tls/misc/ * They are created by the openssl package. I am not sure what /etc/pki/tls/ is supposed to contain. By its name I assume that is should contain all "TLS related stuff". But I think it is hard to decide what certs used on the system are solely "TLS related" and what not. * /etc/pki/tls/certs/ contains the file ca-bundle.crt, a collection of trusted certificate authorities. This file is taken over from Mozilla and Red Hat certificate have been added to it. Unfortunately this directory also contains a Makefile and a script for creating certificates. This should be placed in /etc/pki/tls/misc/. * /etc/pki/tls/private/ is created empty. I think it is intended to contain private keys. * /etc/pki/tls/misc contains a collection of simple scripts used for working with certificates (create hash value, get infos about certs, ...).
Now we look at all applications using /etc/pki:
/etc/pki/tls/certs/slapd.pem * This file is created by openldap-servers. I think that in general it is a bad idea if packages come with default certificates. Certificates should be included or generated by the admin.
/etc/pki/dovecot/ * This one is created by dovecot. It contains a openssl example config file for creating dovecot certs. It also comes with default certs in subdirectories certs/ and private/. Again, I think that default certs are a bad idea.
/etc/pki/pure-ftpd/ * This dir is created empty by pure-ftpd.
/etc/pki/cyrus-imapd/ * This dir is created by cyrus-imapd. It contains a default cert file.
/etc/pki/tls/certs/imapd.pem /etc/pki/tls/certs/ipop3d.pem * These files are created by uw-imap. Again, we have default certs.
/etc/pki/nessus /etc/pki/nessus/CA/ /etc/pki/nessus/private/CA/ * These directories are created by the nessus-server package and contain some default certs.
/etc/pki/nessus/nessus_org.pem * This default cert comes with libnasl
/etc/pki/bittorrent/ * It comes with bittorrent and contains a cert.
Now we have a short look at packages not using /etc/pki. Most of them should use it in my opinion.
/etc/openldap/cacerts * This dir is created empty by openldap.
/etc/raddb/certs * This dir contains certificate related stuff (certs and tools) from the freeradiu package.
/var/run/cups/certs/ * This dir is created by the cups package. I don't know what it is used for.
/usr/share/doc/perl-IO-Socket-SSL-0.991/certs/ * This dir contains a collection of certs and it created by perl-IO-Socket-SSL.
/etc/racoon/certs/ * Created empty by ipsec-tools.
/usr/share/psi/certs/ * Created containing some files by the psi package. I don't know what it is for.
/usr/lib/erlang/lib/inets-4.7.4/examples/server_root/ssl/ /usr/lib/erlang/lib/ssl-3.0.12/examples/certs/ * These directories contain many certs and tools, created by the erlang package.
/usr/lib/erlang-R10B/lib/inets-4.7.2/examples/server_root/ssl/ /usr/lib/erlang-R10B/lib/ssl-3.0.11/examples/certs/ * These directories contain many certs and tools, created by the compat-erlang package.
/var/lib/dirmngr/extra-certs/ * This dir is created empty by the dirmngr package.
/etc/plague/server/certs/ * Created empty by the plague package.
/etc/plague/builder/certs/ * Created empty by the plague-builder package.
/usr/share/cone/rootcerts/ * This dir is created by the cone package and contains many trusted CA certs.
/usr/lib/pl-5.6.16/doc/packages/examples/ssl/etc/ * By the pl package and contains some certs.
/usr/share/ssl/certs/exim.pem /usr/share/ssl/private/exim.pem * Both files are created by the exim package.
/usr/lib/ruby/site_ruby/1.8/puppet/sslcertificates/ * Some files of the puppet package.
/usr/share/openvpn/easy-rsa/1.0/ /usr/share/openvpn/easy-rsa/2.0/ * These dirs contain some cert related scripts of the openvpn package.
As you see there is a large variety on how packages store their certificate related stuff. I think there should be created some guidelines that make clear how and where to store digita certificates. Here are some suggestions:
(1) Many applications have a own certificate used for crypted communication (e.g. TLS). Usually it is split it two files (public and private part) that must be specified in the apllication's config files. Openldap, for example, uses the config commands "TLSCertificateFile" and "TLSCertificateKeyFile" for this. Other apps do it in a similar way.
My suggestion: Every application that uses digital certificates should create a directory /etc/pki/$appname with subdirectories "public" and "private" where its certificates are stored. The default config files of these applications should reflect this by corresponding entries (commented out). Additionally the /etc/pki/tls/ should be removed from the openssl package since certs should not be stored there.
(2) In order to check what certificates of communication partners can be trusted many applications can be given a list of CA certs that are trusted. Openldap, for example, uses configuration entries "TLSCACertificateFile" and "TLSCACertificatePath". The first entry refers to a file like ca-bundle.crt of the openssl package that contains a list of CA certs. The second entries refers to a directory that contains cert files.
My suggestion: Remove the default collection of trusted certs from the openssl package and create a new package for those certs. These certs then should be stored in /etc/pki/cacerts (one file per cert). Applications should use this by default as CA directory (openldap: "TLSCACertificatePath"). The file ca-bundle.crt is not needed anymore but should be there (in /etc/pki) for compatibility issues. In addition there should be a script that automatically creates this file from the contents of /etc/pki/cacerts. With cacerts in an extra package is it possible to use CA cert "modules". There could be other packages that contain futher CA certs. Every admin then can decide what certs to trust. This centralized directory /etc/pki/cacerts additionally makes it possible to add own CA certs without getting into trouble.
What do you think about this?
Joachim - -- B. Sc. Joachim Selke Universität Hannover, Institut für Theoretische Informatik Appelstraße 4, 30167 Hannover, Germany http://www.thi.uni-hannover.de/
On Fri, 2006-07-21 at 11:16 +0200, Joachim Selke wrote:
(2) In order to check what certificates of communication partners can be trusted many applications can be given a list of CA certs that are trusted. Openldap, for example, uses configuration entries "TLSCACertificateFile" and "TLSCACertificatePath". The first entry refers to a file like ca-bundle.crt of the openssl package that contains a list of CA certs. The second entries refers to a directory that contains cert files.
My suggestion: Remove the default collection of trusted certs from the openssl package and create a new package for those certs. These certs then should be stored in /etc/pki/cacerts (one file per cert). Applications should use this by default as CA directory (openldap: "TLSCACertificatePath"). The file ca-bundle.crt is not needed anymore but should be there (in /etc/pki) for compatibility issues. In addition there should be a script that automatically creates this file from the contents of /etc/pki/cacerts. With cacerts in an extra package is it possible to use CA cert "modules". There could be other packages that contain futher CA certs. Every admin then can decide what certs to trust. This centralized directory /etc/pki/cacerts additionally makes it possible to add own CA certs without getting into trouble.
What do you think about this?
I have a comment only about the cacerts situation. If I worked as admin I'd never use all the ca certs shipped in the current CA bundle as trusted for all apps. For web clients maybe, but for verification of LDAP server certificate? Never. Most probably even an internal CA would be used so I'd have to add its certificate anyway. So perhaps there should be individual cacerts directories for individual apps.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tomas Mraz wrote:
I have a comment only about the cacerts situation. If I worked as admin I'd never use all the ca certs shipped in the current CA bundle as trusted for all apps. For web clients maybe, but for verification of LDAP server certificate? Never. Most probably even an internal CA would be used so I'd have to add its certificate anyway. So perhaps there should be individual cacerts directories for individual apps.
Good point. I think we could do the following.
(1) /etc/pki/cacerts is created empty by default (by package filesystem)
(2) This directory is filled with default CA certs by (new) packages cacerts-mozilla and cacerts-redhat. (There of course might be many other cacert-* packages available).
(3) Every application using digital certificates (and capable of checking certs against a list of trusted CA certs) creates the directories /etc/pki/$appname/private, /etc/pki/$appname/public and /etc/pki/$appname/cacerts for storing certs. The last one by default is a symlink pointing to /etc/pki/cacerts.
This in my opinion has some advantages:
(A) Admins can chose which CAs to trust by installing the best fitting cacert-* package. Additionally they can simply add own CA certificates into one directory that from then on all applications trust by default.
(B) If needed for some application the list of trusted CAs can be modified individually.
Do you agree?
Joachim - -- B. Sc. Joachim Selke Universität Hannover, Institut für Theoretische Informatik Appelstraße 4, 30167 Hannover, Germany http://www.thi.uni-hannover.de/
On Fri, 2006-07-21 at 14:24 +0200, Joachim Selke wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tomas Mraz wrote:
I have a comment only about the cacerts situation. If I worked as admin I'd never use all the ca certs shipped in the current CA bundle as trusted for all apps. For web clients maybe, but for verification of LDAP server certificate? Never. Most probably even an internal CA would be used so I'd have to add its certificate anyway. So perhaps there should be individual cacerts directories for individual apps.
Good point. I think we could do the following.
(1) /etc/pki/cacerts is created empty by default (by package filesystem)
(2) This directory is filled with default CA certs by (new) packages cacerts-mozilla and cacerts-redhat. (There of course might be many other cacert-* packages available).
(3) Every application using digital certificates (and capable of checking certs against a list of trusted CA certs) creates the directories /etc/pki/$appname/private, /etc/pki/$appname/public and /etc/pki/$appname/cacerts for storing certs. The last one by default is a symlink pointing to /etc/pki/cacerts.
AFAIK directory as symlink in a package creates problems on package upgrades so it would be best to leave them simply as empty directories. The rest of your proposal is fine I think.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tomas Mraz wrote:
(3) Every application using digital certificates (and capable of checking certs against a list of trusted CA certs) creates the directories /etc/pki/$appname/private, /etc/pki/$appname/public and /etc/pki/$appname/cacerts for storing certs. The last one by default is a symlink pointing to /etc/pki/cacerts.
AFAIK directory as symlink in a package creates problems on package upgrades so it would be best to leave them simply as empty directories.
What kind of problems do you mean? Looking e.g. in /etc I see many directory symlinks.
The rest of your proposal is fine I think.
Great. As mentioned, I think there should be some "official" guidelines on how to deal with digital certificates. I would like to write a draft and publish it at some "official" place for further discussion (where?). How should I proceed?
Joachim - -- B. Sc. Joachim Selke Universität Hannover, Institut für Theoretische Informatik Appelstraße 4, 30167 Hannover, Germany http://www.thi.uni-hannover.de/
On 7/21/06, Joachim Selke selke@thi.uni-hannover.de wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tomas Mraz wrote:
(3) Every application using digital certificates (and capable of checking certs against a list of trusted CA certs) creates the directories /etc/pki/$appname/private, /etc/pki/$appname/public and /etc/pki/$appname/cacerts for storing certs. The last one by default is a symlink pointing to /etc/pki/cacerts.
AFAIK directory as symlink in a package creates problems on package upgrades so it would be best to leave them simply as empty directories.
What kind of problems do you mean? Looking e.g. in /etc I see many directory symlinks.
The problem is if you later want to make the sym-link into a directory. That is the reason for the many directory symlinks... someone forgets to make a directory and creates a symlink and poof you can't later decide on having a directory.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Stephen John Smoogen wrote:
The problem is if you later want to make the sym-link into a directory. That is the reason for the many directory symlinks... someone forgets to make a directory and creates a symlink and poof you can't later decide on having a directory.
OK. Next try (number 3 has changed, 4 and 5 are new):
(1) /etc/pki/cacerts is created empty by default (by the filesystem package)
(2) This directory is filled with default CA certs by (new) packages cacerts-mozilla and cacerts-redhat. (There of course might be many other cacert-* packages available).
(3) Every application using digital certificates (and capable of checking certs against a list of trusted CA certs) creates empty directories /etc/pki/$appname/private, /etc/pki/$appname/public and /etc/pki/$appname/cacerts for storing certs.
(4) Every application as mentioned in (3) should use /etc/pki/$appname/private, /etc/pki/$appname/public and /etc/cacerts as default directories for storing certs and looking for CA certs. These configuration entries should be commented out by default.
(5) No application should come with "default" or "example" certificates contained in its RPM, because certificates should be created by the admin for security reasons. To support this, applications may include a config file for openssl, that is stored in /etc/pki/$appname.
Any comments on this?
Joachim - -- B. Sc. Joachim Selke Universität Hannover, Institut für Theoretische Informatik Appelstraße 4, 30167 Hannover, Germany http://www.thi.uni-hannover.de/
Joachim Selke wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Stephen John Smoogen wrote:
The problem is if you later want to make the sym-link into a directory. That is the reason for the many directory symlinks... someone forgets to make a directory and creates a symlink and poof you can't later decide on having a directory.
OK. Next try (number 3 has changed, 4 and 5 are new):
(1) /etc/pki/cacerts is created empty by default (by the filesystem package)
(2) This directory is filled with default CA certs by (new) packages cacerts-mozilla and cacerts-redhat. (There of course might be many other cacert-* packages available).
(3) Every application using digital certificates (and capable of checking certs against a list of trusted CA certs) creates empty directories /etc/pki/$appname/private, /etc/pki/$appname/public and /etc/pki/$appname/cacerts for storing certs.
(4) Every application as mentioned in (3) should use /etc/pki/$appname/private, /etc/pki/$appname/public and /etc/cacerts as default directories for storing certs and looking for CA certs. These configuration entries should be commented out by default.
(5) No application should come with "default" or "example" certificates contained in its RPM, because certificates should be created by the admin for security reasons. To support this, applications may include a config file for openssl, that is stored in /etc/pki/$appname.
Any comments on this?
Starting to sound very good. Would you be willing to write this up on the wiki, somewhere under http://fedoraproject.org/wiki/PackagingDrafts maybe http://fedoraproject.org/wiki/PackagingDrafts/Pki (I'm sure there probably exists a better URL to use).
-- Rex
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Rex Dieter wrote:
Starting to sound very good. Would you be willing to write this up on the wiki, somewhere under http://fedoraproject.org/wiki/PackagingDrafts maybe http://fedoraproject.org/wiki/PackagingDrafts/Pki (I'm sure there probably exists a better URL to use).
Sure. I'll start working on this tomorrow. What about the name http://fedoraproject.org/wiki/PackagingDrafts/DigitalCertificates?
Joachim - -- B. Sc. Joachim Selke Universität Hannover, Institut für Theoretische Informatik Appelstraße 4, 30167 Hannover, Germany http://www.thi.uni-hannover.de/
Joachim Selke wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Rex Dieter wrote:
Starting to sound very good. Would you be willing to write this up on the wiki, somewhere under http://fedoraproject.org/wiki/PackagingDrafts maybe http://fedoraproject.org/wiki/PackagingDrafts/Pki (I'm sure there probably exists a better URL to use).
Sure. I'll start working on this tomorrow. What about the name http://fedoraproject.org/wiki/PackagingDrafts/DigitalCertificates?
WORKSFORME.
-- Rex
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Rex Dieter wrote:
Would you be willing to write this up on the wiki
I tried to create the page http://fedoraproject.org/wiki/PackagingDrafts/Certificates but I get the messages that I am not allowed to edit it.
Could someone give me the authorization to do that? My user name in the wiki is "Joachim Selke".
Joachim - -- B. Sc. Joachim Selke Universität Hannover, Institut für Theoretische Informatik Appelstraße 4, 30167 Hannover, Germany http://www.thi.uni-hannover.de/
Joachim Selke wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Rex Dieter wrote:
Would you be willing to write this up on the wiki
I tried to create the page http://fedoraproject.org/wiki/PackagingDrafts/Certificates but I get the messages that I am not allowed to edit it.
Could someone give me the authorization to do that? My user name in the wiki is "Joachim Selke".
Hmm... page didn't exist yet at all. I just created a template containing the contents of your last email proposal.
-- Rex
"JS" == Joachim Selke selke@thi.uni-hannover.de writes:
JS> Could someone give me the authorization to do that? My user name JS> in the wiki is "Joachim Selke".
Have you completed the CLA (Contributor License Agreement)? If so, what is your Fedora account ID? I don't see anything matching your name on the list. See http://fedoraproject.org/wiki/Extras/Contributors#GetAFedoraAccount for info on getting a Fedora account and completing the CLA. Note that you don't have to worry about the sponsorship stuff or getting cvsextras membership if you're not submitting packages for Extras at this time.
- J<
On Mon, Jul 24, 2006 at 07:06:40PM +0200, Joachim Selke wrote:
(5) No application should come with "default" or "example" certificates contained in its RPM, because certificates should be created by the admin for security reasons. To support this, applications may include a config file for openssl, that is stored in /etc/pki/$appname.
Any comments on this?
Yes. I would like to point out that this rule would leave the default installs of imap/pop/whatever servers either uncapable of encryption or completely useless, whichever you prefer.
With default certificates, you should be able to do the "leap of faith" style authentication: your mail/web/etc client stores the certificate and alerts you if things go wrong with it. It seems to work fine for ssh (although tls clients could be a bit more intelligent in this regard).
I would assert that a leap of faith (or even completely without server authentication), tls is a better solution that completely open communication. So generating a self-signed certificate (if none exists for the server) in %post scriptlet is IMO a good thing.
The admin will very quickly find out that the service uses self-signed, default cert if he tests it at all (so they can be either content with that or generate different certificate or use one from ca or disable tls or whatever). And if they never even test it, how do you expect them to generate certificates :-).
Also note that certificates are never shipped inside an RPM, that would not make any sense -- the certificate needs to be unique in each installation.
Yours, Peter.
On Tuesday 25 July 2006 16:45, Peter Rockai wrote:
Yes. I would like to point out that this rule would leave the default installs of imap/pop/whatever servers either uncapable of encryption or completely useless, whichever you prefer.
SSH doesn't include one in rpm, its generated the first time you start the ssh service.
The same could be done for the mail servers. Or if they do it in %post, then its not included in the rpm, but that's a bit uglier.
On Tue, Jul 25, 2006 at 04:52:22PM -0400, Jesse Keating wrote:
SSH doesn't include one in rpm, its generated the first time you start the ssh service.
The same could be done for the mail servers. Or if they do it in %post, then its not included in the rpm, but that's a bit uglier.
They are generated in %post, see the last paragraph. The files probably show up in rpm lists because they are marked ghost/noreplace/missingok config files.
Yours, Peter.
Hi.
On Wed, 26 Jul 2006 09:20:23 +0200, Peter Rockai wrote:
They are generated in %post, see the last paragraph. The files probably show up in rpm lists because they are marked ghost/noreplace/missingok config files.
This may be a wild idea, but how about creating a self signed CA (by %post in the package which owns /etc/pki), and have all other programs that need certificates automatically create certificates under that CA?
So all autocreated ceritificates are still not "valid" in the sense that they can be validated by an outsider, but at lease all have the same root.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ralf Ertzinger wrote:
They are generated in %post, see the last paragraph. The files probably show up in rpm lists because they are marked ghost/noreplace/missingok config files.
This may be a wild idea, but how about creating a self signed CA (by %post in the package which owns /etc/pki), and have all other programs that need certificates automatically create certificates under that CA?
That sounds good to me.
Tomorrow I am going to rewrite the draft at http://fedoraproject.org/wiki/PackagingDrafts/Certificates and include your comment and others.
Joachim - -- B. Sc. Joachim Selke Universität Hannover, Institut für Theoretische Informatik Appelstraße 4, 30167 Hannover, Germany http://www.thi.uni-hannover.de/
On Wed, 2006-07-26 at 22:49 +0200, Joachim Selke wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ralf Ertzinger wrote:
They are generated in %post, see the last paragraph. The files probably show up in rpm lists because they are marked ghost/noreplace/missingok config files.
This may be a wild idea, but how about creating a self signed CA (by %post in the package which owns /etc/pki), and have all other programs that need certificates automatically create certificates under that CA?
That sounds good to me.
Tomorrow I am going to rewrite the draft at http://fedoraproject.org/wiki/PackagingDrafts/Certificates and include your comment and others.
Also if the certificates are going to be created automatically you have to make sure it won't overwrite the ones that are already there.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Joachim Selke wrote:
Tomorrow I am going to rewrite the draft at http://fedoraproject.org/wiki/PackagingDrafts/Certificates and include your comment and others.
Done. The draft is far from being perfect. In particular, the linguistic quality is poor, as English is not my first language. Feel free to improve the text. :-)
Joachim - -- B. Sc. Joachim Selke Universität Hannover, Institut für Theoretische Informatik Appelstraße 4, 30167 Hannover, Germany http://www.thi.uni-hannover.de/
On Wed, Jul 26, 2006 at 10:49:17PM +0200, Joachim Selke wrote:
Tomorrow I am going to rewrite the draft at http://fedoraproject.org/wiki/PackagingDrafts/Certificates and include your comment and others.
Hmm, i may have missed the part where move from /etc/pki to /etc/certs was discussed, is that change intentional in the draft? I just don't see the benefit of changing things around, specially since many of the existing packages mostly agree on /etc/pki/tls/appname or somesuch, slight shuffle within /etc/pki should be much less pain than moving to /etc/certs.
Yours, Peter.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Peter Rockai wrote:
Tomorrow I am going to rewrite the draft at http://fedoraproject.org/wiki/PackagingDrafts/Certificates and include your comment and others.
Hmm, i may have missed the part where move from /etc/pki to /etc/certs was discussed, is that change intentional in the draft?
Yes, it is intentional, but I forgot to mention the change.
I think a "public key infrastructure" is some kind service or organization that includes a certificate authority, a registration authority, a directory service, a certificate revocation list, a certificate policy and many other things. Hence, the name /etc/certs should be better in my opinion.
In addition, the new name makes clear that there have been many changes in Fedora's certificate handling. Also I think the name "certs" is more precise and understandable; there are more people who know what "certs" are that those who know the term "pki".
I just don't see the benefit of changing things around, specially since many of the existing packages mostly agree on /etc/pki/tls/appname or somesuch, slight shuffle within /etc/pki should be much less pain than moving to /etc/certs.
Since nearly all certificate related packages have to be changed, I think it makes no difference whether the name is changed to /etc/pki or /etc/certs. Also with a new name it is easier to see what packages have been changed already to follow the guidelines, and what still need to be changed.
What do others think about this?
Joachim - -- B. Sc. Joachim Selke Universität Hannover, Institut für Theoretische Informatik Appelstraße 4, 30167 Hannover, Germany http://www.thi.uni-hannover.de/
On Thu, Jul 27, 2006 at 02:33:34PM +0200, Joachim Selke wrote:
Yes, it is intentional, but I forgot to mention the change.
[snip]
In addition, the new name makes clear that there have been many changes in Fedora's certificate handling. Also I think the name "certs" is more precise and understandable; there are more people who know what "certs" are that those who know the term "pki".
[snip]
Since nearly all certificate related packages have to be changed, I think it makes no difference whether the name is changed to /etc/pki or /etc/certs. Also with a new name it is easier to see what packages have been changed already to follow the guidelines, and what still need to be changed.
There is a not-completely-trivial migration cost for every change. If one file moves (eg for dovecot, it would only be the public part of cert moving, private is in right place already), the breakage risk is lower. I would love to get this done for once and ever, i already have quite some /usr/share -> /etc/pki migration cruft accumulated.
Moving certificates in scriptlets is non-nice, breaking your tls setup is not much better. I recognize that things would be better if locations are standardized... but it's getting more boring every time the preferred location changes. So in the end, i am left unconvinced, it's the poor maintainers (including me) who need to handle all the resulting mess.
Also, if we are trying to get some consensus, consulting ssl maintainer would be a good thing to do (i believe he's currently unreachable though, holidays or somesuch, but not sure).
The bottom line is, that yes, if it is widely believed that /etc/certs is a better place than /etc/pki (which i'm not convinced about either), sure, why not. Just don't change mind right after a first FC release with the new certificate-location-of-the-year gets out.
Yours, Peter.
On Thu, 2006-07-27 at 16:19 +0200, Ralf Ertzinger wrote:
Hi.
On Thu, 27 Jul 2006 14:33:34 +0200, Joachim Selke wrote:
Yes, it is intentional, but I forgot to mention the change.
Since we already moved from somewhere else to /etc/pki not so very long ago I think we should stick with it for the time being.
+1
certs was not used before because there are not only certificates but also keys. It is used for example for rpm-gpg keys and gpg doesn't have certificates at all. So please stick with pki.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tomas Mraz wrote:
Since we already moved from somewhere else to /etc/pki not so very long ago I think we should stick with it for the time being.
+1
certs was not used before because there are not only certificates but also keys. It is used for example for rpm-gpg keys and gpg doesn't have certificates at all. So please stick with pki.
Good point. I changed this back in the draft.
I am going to extend the draft and clarify things soon. Unfortunately, this might be not until September as I'm currently writing my master's thesis and so there is little time for other things. I will report to this list when the update is done.
Joachim - -- B. Sc. Joachim Selke Universität Hannover, Institut für Theoretische Informatik Appelstraße 4, 30167 Hannover, Germany http://www.thi.uni-hannover.de/
-
Jason L Tibbitts III -
Jean-Rene Cormier -
Jesse Keating -
Joachim Selke -
Peter Rockai -
Ralf Ertzinger -
Rex Dieter -
seth vidal -
Stephen John Smoogen -
Tomas Mraz