[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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/

Attachment: smime.p7s
Description: S/MIME cryptografische ondertekening


Reply to: