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 "configurations" (D = Depends, R = Recommends, S = Suggests) D R D R classic D R R S slcs D R R S mlcs S|- S|- S|- - unaccredited (- = not at all, | = OR) > ...Not sure what this means but I could provide backports to older > flavours of Debian, Ubuntu, if there is enough demand. 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. > > 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... > you'd have to have a face-to-face at some > point and he gets around quite a lot... I have a indirect trustpath to the key... me->Ursula Epting (KIT)->David->signing key.. > 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 mean it's utterly important, that when you upload [new] versions of the key material you verify the IGTF bundle sources. https://dist.eugridpma.info/distribution/igtf/current/ There is e.g.: https://dist.eugridpma.info/distribution/igtf/current/igtf-policy-installation-bundle-1.46.tar.gz https://dist.eugridpma.info/distribution/igtf/current/igtf-policy-installation-bundle-1.46.tar.gz.asc The later is the signature with the EugridPMA distribution key... so you need a trust path to that... e.g. via David Groep. Meeting him in person, exchanging his OpenPGP (public) key... and so on. Clear what I meant and how this works? :) > 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 Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature