Debian Bug report logs - #666229
ITP: igtf-policy-bundle -- IGTF profiles for Authority Root Certificates

Package: wnpp; Maintainer for wnpp is wnpp@debian.org;

Reported by: Dennis van Dok <dennisvd@nikhef.nl>

Date: Thu, 29 Mar 2012 21:33:02 UTC

Owned by: Dennis van Dok <dennisvd@nikhef.nl>

Severity: wishlist

Fix blocked by 702329: RFS: igtf-policy-bundle/1.56-2 [ITP] -- The International Grid Trust Federation CA distribution)

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org, wnpp@debian.org:
Bug#666229; Package wnpp. (Thu, 29 Mar 2012 21:33:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dennis van Dok <dennisvd@nikhef.nl>:
New Bug report received and forwarded. Copy sent to debian-devel@lists.debian.org, wnpp@debian.org. (Thu, 29 Mar 2012 21:33:04 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Dennis van Dok <dennisvd@nikhef.nl>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: ITP: igtf-policy-bundle -- IGTF profiles for Authority Root Certificates
Date: Thu, 29 Mar 2012 23:29:23 +0200
Package: wnpp
Severity: wishlist
Owner: Dennis van Dok <dennisvd@nikhef.nl>

* Package name    : igtf-policy-bundle
  Version         : 1.46
  Upstream Author : David Groep <info@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.




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Dennis van Dok <dennisvd@nikhef.nl>:
Bug#666229; Package wnpp. (Fri, 30 Mar 2012 11:45:11 GMT) Full text and rfc822 format available.

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Dennis van Dok <dennisvd@nikhef.nl>. (Fri, 30 Mar 2012 11:45:23 GMT) Full text and rfc822 format available.

Message #10 received at 666229@bugs.debian.org (full text, mbox):

From: Christoph Anton Mitterer <calestyo@scientia.net>
To: 666229@bugs.debian.org
Cc: 666229-subscribe@bugs.debian.org
Subject: Re: Bug#666229: ITP: igtf-policy-bundle -- IGTF profiles for Authority Root Certificates
Date: Fri, 30 Mar 2012 13:40:08 +0200
[Message part 1 (text/plain, inline)]
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 (application/x-pkcs7-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#666229; Package wnpp. (Sat, 31 Mar 2012 00:03:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dennis van Dok <dennisvd@nikhef.nl>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Sat, 31 Mar 2012 00:03:07 GMT) Full text and rfc822 format available.

Message #15 received at 666229@bugs.debian.org (full text, mbox):

From: Dennis van Dok <dennisvd@nikhef.nl>
To: Christoph Anton Mitterer <calestyo@scientia.net>, 666229@bugs.debian.org
Cc: 666229-subscribe@bugs.debian.org
Subject: Re: Bug#666229: ITP: igtf-policy-bundle -- IGTF profiles for Authority Root Certificates
Date: Sat, 31 Mar 2012 01:38:17 +0200
[Message part 1 (text/plain, inline)]
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 (application/pkcs7-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Dennis van Dok <dennisvd@nikhef.nl>:
Bug#666229; Package wnpp. (Sat, 31 Mar 2012 02:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Dennis van Dok <dennisvd@nikhef.nl>. (Sat, 31 Mar 2012 02:51:03 GMT) Full text and rfc822 format available.

Message #20 received at 666229@bugs.debian.org (full text, mbox):

From: Christoph Anton Mitterer <calestyo@scientia.net>
To: 666229@bugs.debian.org
Subject: Re: Bug#666229: ITP: igtf-policy-bundle -- IGTF profiles for Authority Root Certificates
Date: Sat, 31 Mar 2012 04:47:40 +0200
[Message part 1 (text/plain, inline)]
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.
[smime.p7s (application/x-pkcs7-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#666229; Package wnpp. (Mon, 16 Apr 2012 13:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dennis van Dok <dennisvd@nikhef.nl>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Mon, 16 Apr 2012 13:48:04 GMT) Full text and rfc822 format available.

Message #25 received at 666229@bugs.debian.org (full text, mbox):

From: Dennis van Dok <dennisvd@nikhef.nl>
To: debian-devel@lists.debian.org
Cc: 666229@bugs.debian.org
Subject: Adding CA certficates outside of ca-certificates (see ITP #666229)
Date: Mon, 16 Apr 2012 15:44:51 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I would like to include the CA distribution of the IGTF
(www.igtf.net), which is an international collaboration of CAs for use
in the e-science communities (i.e. scientific grid computing & cloud
computing).

The certificates in this collection are typically used for service
certificates (compute & storage endpoints, authentication services,
etc.) and user certificates. They are not commonly used for normal web
servers. That is why I don't think they should be included in the
ca-certificates package.

There seems to be no real way to include extra ca-certificates-*
packages at the moment. I've tried to conform as much as possible to
the structure of the ca-certificates package, and the way I've
packaged it right now is that the administrator has the choice to
include individual certificates from IGTF in /etc/ssl upon
reconfiguring ca-certficates.

http://mentors.debian.net/package/igtf-policy-bundle

The policy bundle offers a choice of opt-in or opt-out, so it's easy
to enable 'all but a few' or 'none but a few' certificates. And
enabling here means placing symlinks in
/etc/grid-security/certificates, which is the de facto place for grid
middleware to look for certificates.

I welcome thoughts and comments on this work.

Best,

Dennis van Dok
- -- 
D.H. van Dok :: Software Engineer :: www.nikhef.nl :: www.biggrid.nl
Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+MIk4ACgkQIITq5lEwLHe5+gCeI2/DS4xpSkJxLmHpyR8VkQqX
2LkAn1veYyGNIdzx9QiLVvkQ0dCivRhK
=JeQF
-----END PGP SIGNATURE-----




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#666229; Package wnpp. (Mon, 16 Apr 2012 14:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dennis van Dok <dennisvd@nikhef.nl>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Mon, 16 Apr 2012 14:12:03 GMT) Full text and rfc822 format available.

Message #30 received at 666229@bugs.debian.org (full text, mbox):

From: Dennis van Dok <dennisvd@nikhef.nl>
To: Christoph Anton Mitterer <calestyo@scientia.net>, 666229@bugs.debian.org
Subject: Re: Bug#666229: ITP: igtf-policy-bundle -- IGTF profiles for Authority Root Certificates
Date: Mon, 16 Apr 2012 16:08:33 +0200
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/




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Dennis van Dok <dennisvd@nikhef.nl>:
Bug#666229; Package wnpp. (Tue, 17 Apr 2012 07:42:39 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Thijs Kinkhorst" <thijs@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Dennis van Dok <dennisvd@nikhef.nl>. (Tue, 17 Apr 2012 07:42:39 GMT) Full text and rfc822 format available.

Message #35 received at 666229@bugs.debian.org (full text, mbox):

From: "Thijs Kinkhorst" <thijs@debian.org>
To: "Dennis van Dok" <dennisvd@nikhef.nl>
Cc: debian-devel@lists.debian.org, 666229@bugs.debian.org
Subject: Re: Adding CA certficates outside of ca-certificates (see ITP #666229)
Date: Tue, 17 Apr 2012 09:26:46 +0200
Hi Dennis,

On Mon, April 16, 2012 15:44, Dennis van Dok wrote:
> I would like to include the CA distribution of the IGTF
> (www.igtf.net), which is an international collaboration of CAs for use
> in the e-science communities (i.e. scientific grid computing & cloud
> computing).

> http://mentors.debian.net/package/igtf-policy-bundle

You're probably aware that there's already an APT-compatible repository
that contains Debian packages for the current IGTF distribution?
https://dist.eugridpma.info/distribution/igtf/current/

How does this package relate to that? What goal do you want to reach by
uploading to Debian proper? In the IGTF community it's more or less
expected that relying parties update their trust anchors not too long
after new IGTF updates are released - if a relying party uses packages
from Debian (old)stable they can easily be two or three years old and are
not easily updated. I'm not sure if newly accredited CA's would be
enthusiastic to wait that long, for example.

> The policy bundle offers a choice of opt-in or opt-out, so it's easy
> to enable 'all but a few' or 'none but a few' certificates. And
> enabling here means placing symlinks in
> /etc/grid-security/certificates, which is the de facto place for grid
> middleware to look for certificates.

I think that makes sense: placing or linking them in
/etc/grid-security/certificates/ 'enables' them from a grid middleware
point of view. As I understand it, you're not doing anything with /etc/ssl
or ca-certificates.crt. This means that the certificates will not change
the trust anchors for 'regular' tools on the system (curl, system daemons,
etc).

I'm unfortunately not at the upcoming EUgridPMA meeting in Karlsruhe this
May, but perhaps there's another opportunity where we can meet to discuss
the ideas and specifics.


Cheers,
Thijs





Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Dennis van Dok <dennisvd@nikhef.nl>:
Bug#666229; Package wnpp. (Tue, 17 Apr 2012 07:51:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Charles Plessy <plessy@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Dennis van Dok <dennisvd@nikhef.nl>. (Tue, 17 Apr 2012 07:51:05 GMT) Full text and rfc822 format available.

Message #40 received at 666229@bugs.debian.org (full text, mbox):

From: Charles Plessy <plessy@debian.org>
To: Dennis van Dok <dennisvd@nikhef.nl>
Cc: debian-devel@lists.debian.org, 666229@bugs.debian.org
Subject: Re: Adding CA certficates outside of ca-certificates (see ITP #666229)
Date: Tue, 17 Apr 2012 16:46:49 +0900
Le Mon, Apr 16, 2012 at 03:44:51PM +0200, Dennis van Dok a écrit :
> 
> There seems to be no real way to include extra ca-certificates-*
> packages at the moment. I've tried to conform as much as possible to
> the structure of the ca-certificates package, and the way I've
> packaged it right now is that the administrator has the choice to
> include individual certificates from IGTF in /etc/ssl upon
> reconfiguring ca-certficates.
> 
> http://mentors.debian.net/package/igtf-policy-bundle

Dear Dennis and everyboyd,

perhaps a broader package would be useful ?  I am still looking
for a sane place for the Amazon EC2 public certificate, see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573857

I also welcome comments.

Cheers,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#666229; Package wnpp. (Tue, 17 Apr 2012 08:09:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dennis van Dok <dennisvd@nikhef.nl>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Tue, 17 Apr 2012 08:09:10 GMT) Full text and rfc822 format available.

Message #45 received at 666229@bugs.debian.org (full text, mbox):

From: Dennis van Dok <dennisvd@nikhef.nl>
To: Thijs Kinkhorst <thijs@debian.org>
Cc: debian-devel@lists.debian.org, 666229@bugs.debian.org
Subject: Re: Adding CA certficates outside of ca-certificates (see ITP #666229)
Date: Tue, 17 Apr 2012 10:06:23 +0200
Hi Thijs,

Op 17-04-12 09:26, Thijs Kinkhorst schreef:
> Hi Dennis,
> You're probably aware that there's already an APT-compatible repository
> that contains Debian packages for the current IGTF distribution?
> https://dist.eugridpma.info/distribution/igtf/current/
> 
> How does this package relate to that? What goal do you want to reach by
> uploading to Debian proper?

Yes, I'm aware of the APT repository of the IGTF; the maintainer is a
close colleague. The current packages are not made with the Debian
Policy in mind. Although they're not outright awful, we've discussed how
we could bring the IGTF distribution more in-line with the Debian way of
packaging.

For administrators it's always an extra hurdle to enable or install
extra repositories. Having the IGTF distribution in Debian proper would
remove this burden.

> In the IGTF community it's more or less
> expected that relying parties update their trust anchors not too long
> after new IGTF updates are released - if a relying party uses packages
> from Debian (old)stable they can easily be two or three years old and are
> not easily updated. I'm not sure if newly accredited CA's would be
> enthusiastic to wait that long, for example.

Worse than that, CAs that lose their accreditation should be removed.
Isn't it possible to have intermediate updates in stable in such cases?
In the same way security updates are done?

> I'm unfortunately not at the upcoming EUgridPMA meeting in Karlsruhe this
> May, but perhaps there's another opportunity where we can meet to discuss
> the ideas and specifics.

Yes, sure. My contact details are below.

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/




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Dennis van Dok <dennisvd@nikhef.nl>:
Bug#666229; Package wnpp. (Tue, 17 Apr 2012 11:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Dennis van Dok <dennisvd@nikhef.nl>. (Tue, 17 Apr 2012 11:54:07 GMT) Full text and rfc822 format available.

Message #50 received at 666229@bugs.debian.org (full text, mbox):

From: Christoph Anton Mitterer <calestyo@scientia.net>
To: <666229@bugs.debian.org>
Subject: Re: Bug#666229: Adding CA certficates outside of ca-certificates (see ITP #666229)
Date: Tue, 17 Apr 2012 13:50:31 +0200
Am 17.04.2012 09:46, schrieb Charles Plessy:
> I also welcome comments.

In principle ca-certificates should make it possible to add any number 
of certs in it, given, that it allows selection which should be enabled 
and which not.
So generally there's no need for many sub packages.... BUT...

- the IGTF bundle is already an example where more logic is needed that 
doesn't fit in ca-certificates-
- it seems somewhat cleaner to me, having more small packages (more 
modular) than one big with just everything.


Maybe, ca-certificates istself should be "demoted" to be just the 
framework package,.. and all current certs in it should be put in group 
sub packages...

e.g. ca-certificates-mozilla
or ca-certificates-cacert

or so.

Chris.




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Dennis van Dok <dennisvd@nikhef.nl>:
Bug#666229; Package wnpp. (Fri, 20 Apr 2012 12:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Christoph Anton Mitterer <calestyo@scientia.net>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Dennis van Dok <dennisvd@nikhef.nl>. (Fri, 20 Apr 2012 12:30:07 GMT) Full text and rfc822 format available.

Message #55 received at 666229@bugs.debian.org (full text, mbox):

From: Christoph Anton Mitterer <calestyo@scientia.net>
To: 666229@bugs.debian.org
Subject: Re: Bug#666229: ITP: igtf-policy-bundle -- IGTF profiles for Authority Root Certificates
Date: Fri, 20 Apr 2012 14:17:49 +0200
[Message part 1 (text/plain, inline)]
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 (application/x-pkcs7-signature, attachment)]

Added blocking bug(s) of 666229: 684102 Request was from Bart Martens <bartm@quantz.debian.org> to control@bugs.debian.org. (Tue, 07 Aug 2012 04:21:07 GMT) Full text and rfc822 format available.

Added blocking bug(s) of 666229: 702329 Request was from Bart Martens <bartm@quantz.debian.org> to control@bugs.debian.org. (Tue, 05 Mar 2013 16:21:07 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#666229; Package wnpp. (Thu, 05 Dec 2013 09:39:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dennis van Dok <dennisvd@nikhef.nl>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Thu, 05 Dec 2013 09:39:04 GMT) Full text and rfc822 format available.

Message #64 received at 666229@bugs.debian.org (full text, mbox):

From: Dennis van Dok <dennisvd@nikhef.nl>
To: 666229@bugs.debian.org
Subject: updated to 1.55
Date: Thu, 05 Dec 2013 10:17:11 +0100
Hi,

just to let everyone know I'm still doing this. I've uploaded the latest
release (1.55) and updated the RFS.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702329

Dennis



Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Mon Apr 21 06:54:01 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.