Bug#666229: ITP: igtf-policy-bundle -- IGTF profiles for Authority Root Certificates
Hi. Was on a dCache workshop and hadn't time to answer before... On Mon, 2012-04-16 at 16:08 +0200, Dennis van Dok wrote: I'm not sure what I prefer: a) ship/create symlinks for both formats I went with a) at the moment. That is what 'upstream' does and it's really handy for legacy software. Well,.. as said I'm unsure myself... I think software wise it's not needed for Debian,.. the transition to ssl1.x is complete, isn't it, so there is no legacy software in Debian. One argument against shipping both formats is, that openssl always at least stats all files in the respective dirs... So this could mean that for every access you get twice as many stats on files as needed... But I guess this is a separate debconf thingy,... configuring what you put in /etc/grid-security and not the one from ca-certificates? yes :) /etc/grid-security should then _only_ contain symlinks, IMHO. Agreed, and that's how it works. :) Rather than start a lot of fuss here...maybe TERENA could be included in the ca-certificates package. It takes only a couple of sponsors IIRC. Would perhaps make sense... I haven't given the metapackage a thought yet. I also don't see the need as there are just three packages for all the accredited stuff. Better to make it a conscious choice. I personally usually prefer having meta-packages, well at least if they don't force you to install more than really necessary (e.g. the gnome metapackages in debian depend one many useless crap, where a recommends would be enough IMHO). Anyway,... given that you need to somehwere put the logic for the /etc/grid-security handling,... a ca-certificates-igtf (meta-)package could be a good place, IMHO No I don't mean older versions... IGTF updates quite often... once the packages are in stable (e.g. wheezy) we still would need to update it... I guess stable-updates is what this is called in the meantime. Sure, if upstream brings out a new version, the Debian stable package would have to be updated. Isn't this essentially a security fix? Well not sure... strictly speaking I don't think so... If a CA was broken, and therefore be removed,.. that would be a security fix. If a CA was no longer member of IGTF,.. that could be a security fix,... but already questionable. If just adding CAs surely no security fix. I thought David Groep is from NIKHEF? And he signed the key that is used to sign the eugridpma distripution key... Well, sure. And I'll take his word that it's the right bundle ;-) He's practically in the next office. :) I can promise that I will diligently check the signatures, but then you'll have to trust me that I will do as I say... Obviously,... but that's the trust relation users have to Debian ;) Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#666229: ITP: igtf-policy-bundle -- IGTF profiles for Authority Root Certificates
Op 31-03-12 04:47, Christoph Anton Mitterer wrote: On Sat, 2012-03-31 at 01:38 +0200, Dennis van Dok wrote: It's better not to get these things mixed up too much. Definitely. I agree that the actual PEM files should be placed in /usr/share/ca-certificates/ and I'd propose a structure like this: /usr/share/ca-certificates/igtf/classic /usr/share/ca-certificates/igtf/slcs /usr/share/ca-certificates/igtf/mlcs That's *almost* how I've packaged it. One thing I just recall: OpenSSL hash links... pre/post 1.0 format. I'm not sure what I prefer: a) ship/create symlinks for both formats b) ship/create symlinks for post 1.0 only I went with a) at the moment. That is what 'upstream' does and it's really handy for legacy software. But I guess this is a separate debconf thingy,... configuring what you put in /etc/grid-security and not the one from ca-certificates? yes /etc/grid-security should then _only_ contain symlinks, IMHO. Agreed, and that's how it works. Not sure if this is easily possible, but it would be nice, if the cert selection was somehow sorted by the respective PMA.. and perhaps when you see the country code of the respective CA. I'm not sure how I could easily implement this. I don't see this as such an urgent matter, and as I'm apolitical I don't understand what the fuss is about. Splitting the file hierarchy would make sense here, as people quickly recognise which type (i.e. MLCS/SLCS) a cert is of. This is indeed split into different packages. I revised my idea,.. ALL (that are installed) should show up... but one should be able to see where they're belonging to, which is easily possible via the path. Agreed. but there may even be some from the 'unaccredited' set that you would want to have in ca-certificates (e.g. the TERENA-SSL-CA). TERENA is in unaccredited,.. damn... Nevertheless, I think if you follow my idea to split the packages and make one metapackage, I would NOT depend on the -unaccredited package at most suggest it.. but even that is questionable, because while specifically TERENA is likely generally useful, for the main purpose of IGTF it's not. Rather than start a lot of fuss here...maybe TERENA could be included in the ca-certificates package. It takes only a couple of sponsors IIRC. For the ca-certifcates part... it's anyway up the the admin to decide (if he configured ask,... if he did not one can't help him ;) ) Well on the other hand... uhm... I'm just thinking what a meta package should do (if you split up) I haven't given the metapackage a thought yet. I also don't see the need as there are just three packages for all the accredited stuff. Better to make it a conscious choice. No I don't mean older versions... IGTF updates quite often... once the packages are in stable (e.g. wheezy) we still would need to update it... I guess stable-updates is what this is called in the meantime. Sure, if upstream brings out a new version, the Debian stable package would have to be updated. Isn't this essentially a security fix? When you're from NIKHEF you can probably easily get David's OpenPGP key in a secure way to add only securely downloaded igtf bundles to Debian :) Nothing NIKHEF specific here, I thought David Groep is from NIKHEF? And he signed the key that is used to sign the eugridpma distripution key... Well, sure. And I'll take his word that it's the right bundle ;-) He's practically in the next office. I can promise that I will diligently check the signatures, but then you'll have to trust me that I will do as I say... I'm all for a further discussion of how to do this properly for Debian; I've put a lot of my own thought into this and I've reflected this with others, notably the upstream maintainer, but I still consider this very much as an initial attempt. Well I guess you're on a good way... especially your idea to separate between ca-certificates an another debconf for grid-security = +1 Thanks, Dennis -- D.H. van Dok :: Software Engineer :: www.nikhef.nl :: www.biggrid.nl Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666229: ITP: igtf-policy-bundle -- IGTF profiles for Authority Root Certificates
Hi Dennis. Running the LMU-LRZ Tier-2 this is quite good news, however.. On Thu, 2012-03-29 at 23:29 +0200, Dennis van Dok wrote: The certificates are kept in /usr/share/igtf-policy/ and /usr/share/ca-certificates/igtf-*/. Why two locations (i.e. why the one outside of /usr/share/ca-certificates/) They are meant to be placed in /etc/grid-security/certificates, where the commonly used grid middleware will look for it; it is also possible to include (some of) the certificates in /etc/ssl/certs by using dpkg-reconfigure ca-certificates. Well here the problems start, IMHO. I always considered the whole /etc/grid-security/ quite broken and not more than a quite and dirty hack to ease up life with multiple grid apps. It more or less contradicts the way certificates are meant to be handled in Debian (i.e. ca-certificates). Are you going to automatically create /etc/grid-security/certificates and put links in there? Will it be possible to configure only selected CAs? Will you integrated into ca-certificates (i.e. which certs-get enabled and not)? Probably not all certificates in IGTF should show up in what ca-certificates creates (i.e. SLCS and MLCS). btw: Are you going to provide backports or better said volatile support? When you're from NIKHEF you can probably easily get David's OpenPGP key in a secure way to add only securely downloaded igtf bundles to Debian :) Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#666229: ITP: igtf-policy-bundle -- IGTF profiles for Authority Root Certificates
Op 30-03-12 13:40, Christoph Anton Mitterer schreef: Hi Dennis. Hi Chris, Running the LMU-LRZ Tier-2 this is quite good news, however.. (H'm, coincidentally I'm just back from LRZ after the EGI community forum.) On Thu, 2012-03-29 at 23:29 +0200, Dennis van Dok wrote: The certificates are kept in /usr/share/igtf-policy/ and /usr/share/ca-certificates/igtf-*/. Why two locations (i.e. why the one outside of /usr/share/ca-certificates/) There is an easy answer and a more complicated answer. The easy answer is that the IGTF CAs come with several files besides just the certificates. The info, namespaces, crl_url and signing_policy files are used by tools such as fetch-crl. And each certificate is also available as hash.0. They would pollute the certificate collection if they were installed under /usr/share/ca-certificates. I now just put the certificates there for convenience; dpkg-reconfigure ca-certificates will pick them up, and they can be enabled for general-purpos uses. The more complicated answer is that the IGTF collection has a different purpose than the general ca_certificates. It covers different use cases, has different security controls (the IGTF works with CRLs) and covers different risks. It's better not to get these things mixed up too much. The fact that the same technology is involved is not enough of a reason to place them together. They are meant to be placed in /etc/grid-security/certificates, where the commonly used grid middleware will look for it; it is also possible to include (some of) the certificates in /etc/ssl/certs by using dpkg-reconfigure ca-certificates. Well here the problems start, IMHO. I always considered the whole /etc/grid-security/ quite broken and not more than a quite and dirty hack to ease up life with multiple grid apps. Nevertheless, this is a location used by many, many systems. It more or less contradicts the way certificates are meant to be handled in Debian (i.e. ca-certificates). Are you going to automatically create /etc/grid-security/certificates and put links in there? Yes; right now the package works (you can try already as it is in mentors[1]) by symlinking the files in /etc/grid-security/certificates. 1. http://mentors.debian.net/package/igtf-policy-bundle Will it be possible to configure only selected CAs? Yes, through debconf. It's either exclusion based (install all but a selected few) or inclusion based (only install a selected few). Will you integrated into ca-certificates (i.e. which certs-get enabled and not)? There is some integration; running dpkg-reconfigure on ca-certificates after installing an igtf package with ca-certificates/trust_new_crts: ask will give you the option to select the IGTF certificates. This choice is independent of what's installed in /etc/grid-security/certificates (again, different use cases!) Probably not all certificates in IGTF should show up in what ca-certificates creates (i.e. SLCS and MLCS). Probably not; but there may even be some from the 'unaccredited' set that you would want to have in ca-certificates (e.g. the TERENA-SSL-CA). We could make a hand-picked selection but a) who would do the choosing and b) what would be the criteria? Neither a or b are very clear to me. At least in the current setup it's clear that the choice and the responsibility fall to the sysadmin. btw: Are you going to provide backports or better said volatile support? ...Not sure what this means but I could provide backports to older flavours of Debian, Ubuntu, if there is enough demand. When you're from NIKHEF you can probably easily get David's OpenPGP key in a secure way to add only securely downloaded igtf bundles to Debian :) Nothing NIKHEF specific here, you'd have to have a face-to-face at some point and he gets around quite a lot... Not sure what you mean by 'securely downloaded'. Do you mean over an SSL connection, or do you mean that it's verified that the downloaded sources are the same as the original? I'm all for a further discussion of how to do this properly for Debian; I've put a lot of my own thought into this and I've reflected this with others, notably the upstream maintainer, but I still consider this very much as an initial attempt. Cheers, Dennis -- D.H. van Dok :: Software Engineer :: www.nikhef.nl :: www.biggrid.nl Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/ smime.p7s Description: S/MIME cryptografische ondertekening
Bug#666229: ITP: igtf-policy-bundle -- IGTF profiles for Authority Root Certificates
Hi. On Sat, 2012-03-31 at 01:38 +0200, Dennis van Dok wrote: (H'm, coincidentally I'm just back from LRZ after the EGI community forum.) Hope you had a nice stay in Garching. The easy answer is that the IGTF CAs come with several files besides just the certificates. The info, namespaces, crl_url and signing_policy files are used by tools such as fetch-crl. And each certificate is also available as hash.0. Yeah that's all clear... even though the hash.N is no IGTF specialty but a SSL thing, the same for .rN files. The more complicated answer is that the IGTF collection has a different purpose than the general ca_certificates. It covers different use cases, has different security controls (the IGTF works with CRLs) and covers different risks. Well CRLs could be encoded in X.509 certs themselves, too, but I guess we don't need to discuss the weirdness of the grid world,.. things are as they are :( It's better not to get these things mixed up too much. Definitely. I agree that the actual PEM files should be placed in /usr/share/ca-certificates/ and I'd propose a structure like this: /usr/share/ca-certificates/igtf/classic /usr/share/ca-certificates/igtf/slcs /usr/share/ca-certificates/igtf/mlcs For the package structure it may make sense to split this, too, e.g. ca-certificates-igtf (meta package, depending on the following three) ca-certificates-igtf-classic ca-certificates-igtf-slcs ca-certificates-igtf-mlcs Maybe one could add (withOUT depending, recommending or suggesting) ca-certificates-igtf-experimental ca-certificates-igtf-unaccredited etc. But if you don't split up the packages like this and have just one big package, I would generally exclude -experimental, -unaccredited, etc. (for security reasons). One thing I just recall: OpenSSL hash links... pre/post 1.0 format. I'm not sure what I prefer: a) ship/create symlinks for both formats b) ship/create symlinks for post 1.0 only a) has the advantage that you can e.g. NFS export the files and they can be used by older systems b) doesn't clutter debian with old style stuff, that is no longer needed (Debian has already OpenSSL 1.x). I guess I tend to (b),... from a Debian point of view there is no need to support foreign legacy systems. And if someone really wants the hashes, he can create them manually. Yes; right now the package works (you can try already as it is in mentors[1]) by symlinking the files in /etc/grid-security/certificates. 1. http://mentors.debian.net/package/igtf-policy-bundle Will do so once I find the time :) Yes, through debconf. It's either exclusion based (install all but a selected few) or inclusion based (only install a selected few). But I guess this is a separate debconf thingy,... configuring what you put in /etc/grid-security and not the one from ca-certificates? If so, good. /etc/grid-security should then _only_ contain symlinks, IMHO. Not sure if this is easily possible, but it would be nice, if the cert selection was somehow sorted by the respective PMA.. and perhaps when you see the country code of the respective CA. I mean this makes it quickly possible to sort out CAs, when this demanded by law (i.e. Iran as of now). There is some integration; running dpkg-reconfigure on ca-certificates after installing an igtf package with ca-certificates/trust_new_crts: ask will give you the option to select the IGTF certificates. This choice is independent of what's installed in /etc/grid-security/certificates (again, different use cases!) Great. Splitting the file hierarchy would make sense here, as people quickly recognise which type (i.e. MLCS/SLCS) a cert is of. I guess the certs installed via ca-certificates, are installed by functions of ca-certificates, so it is responsible for choosing the hash format (hopefully it does only post 1.x). Probably not all certificates in IGTF should show up in what ca-certificates creates (i.e. SLCS and MLCS). Probably not; I revised my idea,.. ALL (that are installed) should show up... but one should be able to see where they're belonging to, which is easily possible via the path. but there may even be some from the 'unaccredited' set that you would want to have in ca-certificates (e.g. the TERENA-SSL-CA). TERENA is in unaccredited,.. damn... Nevertheless, I think if you follow my idea to split the packages and make one metapackage, I would NOT depend on the -unaccredited package at most suggest it.. but even that is questionable, because while specifically TERENA is likely generally useful, for the main purpose of IGTF it's not. We could make a hand-picked selection but a) who would do the choosing and b) what would be the criteria? No,.. for get about this :) For the ca-certifcates part... it's anyway up the the admin to decide (if he configured ask,... if he did not one can't help him ;) ) Well on the other hand... uhm... I'm just thinking what a meta package should do (if you split up) I could think about those
Bug#666229: ITP: igtf-policy-bundle -- IGTF profiles for Authority Root Certificates
Package: wnpp Severity: wishlist Owner: Dennis van Dok denni...@nikhef.nl * Package name: igtf-policy-bundle Version : 1.46 Upstream Author : David Groep i...@eugridpma.org * URL : http://www.igtf.net/ * License : Apache 2 Programming Lang: X.509 CA certificates Description : IGTF profiles for Authority Root Certificates The International Grid Trust Federation (IGTF) maintains a common trust base for the benefit of distributed science and research computing infrastructures by maintaining a list of trust anchors, for accredited authorities. The distribution contains root certificates, certificate revocation list (CRL) locations, contact information, and signing policies. The package is split up according to the different profiles of the IGTF (each profile covers a different set of rules and policies). The most important ones are classic, mics (member integrated credential service) and slcs (short lived credential service). The trust anchors maintained by the IGTF form a trust backbone for many large-scale science communities, among which the European Grid Infrastructure (http://www.ige.eu/) and the World-wide LHC Computing Grid (http://lcg.web.cern.ch/lcg/). The certificates are kept in /usr/share/igtf-policy/ and /usr/share/ca-certificates/igtf-*/. They are meant to be placed in /etc/grid-security/certificates, where the commonly used grid middleware will look for it; it is also possible to include (some of) the certificates in /etc/ssl/certs by using dpkg-reconfigure ca-certificates. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
