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