Re: libnss consolidation (was: Re: X.509 and CA certificates for other purposes (i.e. the IGTF))
Le 10 juin 2013 07:06, Florian Weimer f...@deneb.enyo.de a écrit : * Bastien ROUCARIES: Maybe crypto consolidation arround libnss will greatly help here. jessie release goal ? NSS has lots of global state, and its proper initialization from another library is difficult. Could you give some pointer? Switching over to it is probably doable, but it's not really straightforward. On the other hand, the TLS implementation in NSS has been doing host name validation for a long time, which is still problematic with some of the other implementations. NSS has its own problems with SUID/SGID binaries, but these could be addressed by switching PR_GetEnv to secure_getenv. Could you also give some pointer? I will open a wiki page -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vc5mtuzr.fsf...@mid.deneb.enyo.de
Re: X.509 and CA certificates for other purposes (i.e. the IGTF)
Le dimanche 26 mai 2013 à 20:02 +0200, Bastien ROUCARIES a écrit : Maybe crypto consolidation arround libnss will greatly help here. jessie release goal ? If we consolidate on a crypto library, it would be good for it to use ca-certificates and not a pre-compiled list of certificates. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1370855048.3721.245.camel@pi0307572
Re: X.509 and CA certificates for other purposes (i.e. the IGTF)
On Mon, Jun 10, 2013 at 11:04 AM, Josselin Mouette j...@debian.org wrote: Le dimanche 26 mai 2013 à 20:02 +0200, Bastien ROUCARIES a écrit : Maybe crypto consolidation arround libnss will greatly help here. jessie release goal ? If we consolidate on a crypto library, it would be good for it to use ca-certificates and not a pre-compiled list of certificates. See #704180 and we could share trust between gnome and mozilla (NSS) -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1370855048.3721.245.camel@pi0307572 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cae2spazuchzatxku0phx8w6jnbh5x6fuxfccgnnojrbrbn7...@mail.gmail.com
Re: X.509 and CA certificates for other purposes (i.e. the IGTF)
Le lundi 10 juin 2013 à 11:47 +0200, Bastien ROUCARIES a écrit : On Mon, Jun 10, 2013 at 11:04 AM, Josselin Mouette j...@debian.org wrote: Le dimanche 26 mai 2013 à 20:02 +0200, Bastien ROUCARIES a écrit : Maybe crypto consolidation arround libnss will greatly help here. jessie release goal ? If we consolidate on a crypto library, it would be good for it to use ca-certificates and not a pre-compiled list of certificates. See #704180 and we could share trust between gnome and mozilla (NSS) It looks like we can fix this long-standing issue. Thanks for the pointer! -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1370859292.3721.256.camel@pi0307572
libnss consolidation (was: Re: X.509 and CA certificates for other purposes (i.e. the IGTF))
* Bastien ROUCARIES: Maybe crypto consolidation arround libnss will greatly help here. jessie release goal ? NSS has lots of global state, and its proper initialization from another library is difficult. Switching over to it is probably doable, but it's not really straightforward. On the other hand, the TLS implementation in NSS has been doing host name validation for a long time, which is still problematic with some of the other implementations. NSS has its own problems with SUID/SGID binaries, but these could be addressed by switching PR_GetEnv to secure_getenv. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vc5mtuzr.fsf...@mid.deneb.enyo.de
Re: libnss consolidation (was: X.509 and CA certificates for other purposes (i.e. the IGTF))
On Fri, May 31, 2013 at 4:42 AM, brian m. carlson sand...@crustytoothpaste.net wrote: On Thu, May 30, 2013 at 04:04:47PM +0200, Bastien ROUCARIES wrote: Cons: - not all crypto libraries are equivalent; choosing one will exclude some functionality provided by others SEE compat layer - we somehow have to deal with legacy systems that can't convert - adoption of new software that uses something else is harder NSS does not support TLS 1.2. Since RC4 is not used securely in TLS, and the only other choice in TLS 1.1 and earlier is block ciphers with CBC, this means that there are no secure choices. I know the lack of TLS 1.2 support has caused customers of $DAYJOB endless heartache with regard to PCI compliance. Not true anymore: https://hg.mozilla.org/projects/nss/rev/5a9fa031aca5 Please open a debian bug NSS supports fewer algorithms than either OpenSSL or GnuTLS. Please fill bug: Gnutls is really crappy about suid see http://lists.debian.org/debian-devel/2010/03/msg00298.html See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543941 And openssl has problem about license -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cae2spazib3iezzla-sd3r0ft7ff6pdxkvkrzgxdsn1d7foz...@mail.gmail.com
Re: libnss consolidation (was: X.509 and CA certificates for other purposes (i.e. the IGTF))
On 31 May 2013 20:19, Bastien ROUCARIES roucaries.bast...@gmail.com wrote: Gnutls is really crappy about suid see http://lists.debian.org/debian-devel/2010/03/msg00298.html 2+ years later or 2 Debian releases later, I would have hoped these issues would be, somehow, magically, fixed by now :-( Basically makes libpam-ldap + TLS broken with certain programs. libnss-ldap is probably also broken, but seems you should be using libnss-ldapd these days which may (?) avoid these problems. (I stopped using LDAP for authentication as a direct result of these problems - hardly a good selling point for Debian; so if something has changed I may not have noticed) -- Brian May br...@microcomaustralia.com.au
Re: libnss consolidation (was: X.509 and CA certificates for other purposes (i.e. the IGTF))
On Fri, May 31, 2013 at 12:19:27PM +0200, Bastien ROUCARIES wrote: On Fri, May 31, 2013 at 4:42 AM, brian m. carlson sand...@crustytoothpaste.net wrote: NSS does not support TLS 1.2. Since RC4 is not used securely in TLS, and the only other choice in TLS 1.1 and earlier is block ciphers with CBC, this means that there are no secure choices. I know the lack of TLS 1.2 support has caused customers of $DAYJOB endless heartache with regard to PCI compliance. Not true anymore: https://hg.mozilla.org/projects/nss/rev/5a9fa031aca5 Upstream bug 480514 is still open, and while it may have landed in the main HEAD, it is not in any released version, and not in Debian. It would be irresponsible to transition to NSS when that would mean a regression in security for users. NSS supports fewer algorithms than either OpenSSL or GnuTLS. Please fill bug: Gnutls is really crappy about suid see http://lists.debian.org/debian-devel/2010/03/msg00298.html See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543941 And openssl has problem about license I'm not saying these problems don't exist, but they have no bearing on the fact that OpenSSL and GnuTLS support far more algorithms. Also, it's hard to tell what algorithms and protocols are supported (and how to use NSS at all), since Debian does not include documentation and much of the d.m.o documentation is seriously out of date. We can't expect everyone to switch to NSS without accurate, maintained, and distributed documentation. NSS is also slow to accept patches and new features upstream. It took quite a long time to get TLS 1.1 and TLS 1.2 in, even when not having them in had negative security implications. Finally, does NSS support OpenSSL-style algorithm specifications to select the protocols and algorithms used? Lots of programs expect to be able to pass this information to the library, and parts of e.g. the Postfix configuration would fail to work without it. This functionality is required for PCI compliance, which I'm sure is something lots of Debian's users want. I'm all for crypto consolidation, but only if doing so doesn't cause regressions in security or functionality. Right now, that doesn't seem to be the case. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: X.509 and CA certificates for other purposes (i.e. the IGTF)
On 26-05-13 20:02, Bastien ROUCARIES wrote: On Sat, May 25, 2013 at 2:27 PM, Charles Plessy ple...@debian.org wrote: Hi Dennis and everybody, somewhat related to this, I would like to know if there is a package that could host Amazon's EC2 public certificate ? In Ubuntu it is added to the euca2ools package, because a program of this package can use it, but it is not part of the upstream source (which is not Amazon), so I really would prefer to ship the certificate somewhere else. I proposed ca-certificates earlier, but the result was inconclusive. http://bugs.debian.org/573857 Would there be a volunteer to maintain new package from scratch if needed ? Maybe crypto consolidation arround libnss will greatly help here. jessie release goal ? Could you elaborate on what it is you propose exactly, because I could interpret this in many different ways. D. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a72ee6.7040...@nikhef.nl
Re: X.509 and CA certificates for other purposes (i.e. the IGTF)
On Thu, May 30, 2013 at 12:50 PM, Dennis van Dok denni...@nikhef.nl wrote: On 26-05-13 20:02, Bastien ROUCARIES wrote: On Sat, May 25, 2013 at 2:27 PM, Charles Plessy ple...@debian.org wrote: Hi Dennis and everybody, somewhat related to this, I would like to know if there is a package that could host Amazon's EC2 public certificate ? In Ubuntu it is added to the euca2ools package, because a program of this package can use it, but it is not part of the upstream source (which is not Amazon), so I really would prefer to ship the certificate somewhere else. I proposed ca-certificates earlier, but the result was inconclusive. http://bugs.debian.org/573857 Would there be a volunteer to maintain new package from scratch if needed ? Maybe crypto consolidation arround libnss will greatly help here. jessie release goal ? Could you elaborate on what it is you propose exactly, because I could interpret this in many different ways. Using only one lib for crypto (libnss) will allow to use only one trust certificate format D. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cae2spaa4bn36e02xmyrady7p7jkln6cbm+nclyn1j-yz-f+...@mail.gmail.com
Re: X.509 and CA certificates for other purposes (i.e. the IGTF)
On Thu, May 30, 2013 at 12:50 PM, Dennis van Dok denni...@nikhef.nl wrote: On 26-05-13 20:02, Bastien ROUCARIES wrote: On Sat, May 25, 2013 at 2:27 PM, Charles Plessy ple...@debian.org wrote: Hi Dennis and everybody, somewhat related to this, I would like to know if there is a package that could host Amazon's EC2 public certificate ? In Ubuntu it is added to the euca2ools package, because a program of this package can use it, but it is not part of the upstream source (which is not Amazon), so I really would prefer to ship the certificate somewhere else. I proposed ca-certificates earlier, but the result was inconclusive. http://bugs.debian.org/573857 Would there be a volunteer to maintain new package from scratch if needed ? Maybe crypto consolidation arround libnss will greatly help here. jessie release goal ? Could you elaborate on what it is you propose exactly, because I could interpret this in many different ways. See also https://fedoraproject.org/wiki/FedoraCryptoConsolidation D. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAE2SPAa1qk-zLMb2Dau_H1vB9CzJKKye6=cz2re0o_stw9k...@mail.gmail.com
Re: libnss consolidation (was: X.509 and CA certificates for other purposes (i.e. the IGTF))
On 30-05-13 13:16, Bastien ROUCARIES wrote: Using only one lib for crypto (libnss) will allow to use only one trust certificate format 'Allow only one' doesn't immediately strike me as beneficial, but I see what you mean. The discussion is similar to others (such as about which init system to support) where the question is 'why do we have X implementations of Y?' where X 1. There are pros and cons to such a bold plan as you propose. I can think of a few, and I'm sure others can think of many more. But more importantly, it takes effort to work out the plan, inventory the pros and cons, calculate the required efford and herd it along. Most work on Debian is on a voluntary basis, the available effort depends on what people will want to invest (even just to read this e-mail!). I'm not volunteering. But to seed the discussion (maybe): Pros: having only one crypto system will simplify the handling of certificates. Cons: - not all crypto libraries are equivalent; choosing one will exclude some functionality provided by others - we somehow have to deal with legacy systems that can't convert - adoption of new software that uses something else is harder Cheers, Dennis van Dok -- D.H. van Dok :: Software Engineer :: www.nikhef.nl/grid :: Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a74103.5040...@nikhef.nl
Re: libnss consolidation (was: X.509 and CA certificates for other purposes (i.e. the IGTF))
Le 30 mai 2013 14:08, Dennis van Dok denni...@nikhef.nl a écrit : On 30-05-13 13:16, Bastien ROUCARIES wrote: Using only one lib for crypto (libnss) will allow to use only one trust certificate format 'Allow only one' doesn't immediately strike me as beneficial, but I see what you mean. The discussion is similar to others (such as about which init system to support) where the question is 'why do we have X implementations of Y?' where X 1. There are pros and cons to such a bold plan as you propose. I can think of a few, and I'm sure others can think of many more. But more importantly, it takes effort to work out the plan, inventory the pros and cons, calculate the required efford and herd it along. Most work on Debian is on a voluntary basis, the available effort depends on what people will want to invest (even just to read this e-mail!). I'm not volunteering. But to seed the discussion (maybe): Pros: having only one crypto system will simplify the handling of certificates. Simplify security audit and get faits certification Avoid lice se issue with openssl ans GPL Avoid problem with gnutls ans suid Cons: - not all crypto libraries are equivalent; choosing one will exclude some functionality provided by others SEE compat layer - we somehow have to deal with legacy systems that can't convert - adoption of new software that uses something else is harder Cheers, Dennis van Dok -- D.H. van Dok :: Software Engineer :: www.nikhef.nl/grid :: Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/
Re: X.509 and CA certificates for other purposes (i.e. the IGTF)
On Wed, 2013-05-29 at 12:19 +0200, Dennis van Dok wrote: ...which is included in mozilla. That discussion should be taken there (indeed was[1]) as in Debian it was agreed we're not going to do better than Mozilla at judging CAs[2]. Yeah... sure... I was just mentioning it... Given that Mozilla performs pretty poorly with respect to security (not only in terms of certificates), that decision was probably not so good ;) Cheers, Chris smime.p7s Description: S/MIME cryptographic signature
Re: X.509 and CA certificates for other purposes (i.e. the IGTF)
On 30/05/13 13:19, Bastien ROUCARIES wrote: On Thu, May 30, 2013 at 12:50 PM, Dennis van Dok denni...@nikhef.nl wrote: On 26-05-13 20:02, Bastien ROUCARIES wrote: On Sat, May 25, 2013 at 2:27 PM, Charles Plessy ple...@debian.org wrote: Hi Dennis and everybody, somewhat related to this, I would like to know if there is a package that could host Amazon's EC2 public certificate ? In Ubuntu it is added to the euca2ools package, because a program of this package can use it, but it is not part of the upstream source (which is not Amazon), so I really would prefer to ship the certificate somewhere else. I proposed ca-certificates earlier, but the result was inconclusive. http://bugs.debian.org/573857 Would there be a volunteer to maintain new package from scratch if needed ? Maybe crypto consolidation arround libnss will greatly help here. jessie release goal ? Could you elaborate on what it is you propose exactly, because I could interpret this in many different ways. See also https://fedoraproject.org/wiki/FedoraCryptoConsolidation One of the GSoC project areas that did not go ahead covers this same topic. You can find some of the ideas by reading through the proposal I put up and the responses from three students http://wiki.debian.org/SummerOfCode2013/Projects#Improving_PKI_on_Debian Some of it overlaps with what Fedora are discussing -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a78d41.1070...@pocock.com.au
Re: libnss consolidation (was: X.509 and CA certificates for other purposes (i.e. the IGTF))
On Thu, May 30, 2013 at 04:04:47PM +0200, Bastien ROUCARIES wrote: Cons: - not all crypto libraries are equivalent; choosing one will exclude some functionality provided by others SEE compat layer - we somehow have to deal with legacy systems that can't convert - adoption of new software that uses something else is harder NSS does not support TLS 1.2. Since RC4 is not used securely in TLS, and the only other choice in TLS 1.1 and earlier is block ciphers with CBC, this means that there are no secure choices. I know the lack of TLS 1.2 support has caused customers of $DAYJOB endless heartache with regard to PCI compliance. NSS supports fewer algorithms than either OpenSSL or GnuTLS. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: X.509 and CA certificates for other purposes (i.e. the IGTF)
On 25-05-13 04:04, Christoph Anton Mitterer wrote: On Fri, 2013-05-24 at 12:32 +0200, Dennis van Dok wrote: The point I'd like to raise is that the current model of CA certificates seems to take an all-or-nothing approach: either a CA is trusted (for whatever purpose) or not. For the IGTF CAs, this may not be the right approach. I don't think that's a good idea for ca-certificates either,... but I don't think you can really do anything against it... either the cert is installed in /etc/ssl or not... the problem here lies actually with the clients, when they don't allow you to specify another store location to have more fine grained possibilities... Sure there is what Kurt mentions... but I mean that doesn't make things really better IMHO, as it only allows to set a few roles,... not something like ejabberd should accept this, but apache should not, or does it? No, I don't think so, the feature is quite limited that way. but I think it's very problematic that ca-certificates includes extremely untrustworthy CAs like CNNIC... ...which is included in mozilla. That discussion should be taken there (indeed was[1]) as in Debian it was agreed we're not going to do better than Mozilla at judging CAs[2]. 1. https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.security.policy/F7471-CzPow[1-25-false] 2. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647848 Anyway... good to see you again into bringing the IGTF bundle to Debian :) Thanks! In order to move forward, I really need someone to have a look at my package. I need to know that I'm on the right track. Cheers, Dennis -- D.H. van Dok :: Software Engineer :: www.nikhef.nl/grid :: Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a5d63e.2090...@nikhef.nl
Re: X.509 and CA certificates for other purposes (i.e. the IGTF)
On Sat, May 25, 2013 at 2:27 PM, Charles Plessy ple...@debian.org wrote: Le Fri, May 24, 2013 at 12:32:29PM +0200, Dennis van Dok a écrit : I've seen the Debconf '12 discussion on X.509 certificate stores[1] and the Wiki page that came out of that discussion[2]. 1. http://www.irill.org/videos/debconf-12/895_X.509_Cert_Store_Discussion.mp4 2. http://wiki.debian.org/X.509 As far as I'm aware there aren't many mentions of [2] in the public mailing lists, but I'm very interested to discuss where this is going. My main interest is the use case for certificates from the science grid community. The IGTF[3] has a distribution of accredited CAs that are used world-wide to authenticate both services and users. These are typically not the kind of CAs you'd trust for on-line banking, but services like: - compute clusters - grid storage pools - science clouds - science workflow portals - etc. Hi Dennis and everybody, somewhat related to this, I would like to know if there is a package that could host Amazon's EC2 public certificate ? In Ubuntu it is added to the euca2ools package, because a program of this package can use it, but it is not part of the upstream source (which is not Amazon), so I really would prefer to ship the certificate somewhere else. I proposed ca-certificates earlier, but the result was inconclusive. http://bugs.debian.org/573857 Would there be a volunteer to maintain new package from scratch if needed ? Maybe crypto consolidation arround libnss will greatly help here. jessie release goal ? Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130525122708.ga29...@falafel.plessy.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cae2spazav0px6csdyp1czxhes0qjzbm+mebgztafh6+vc9b...@mail.gmail.com
Re: X.509 and CA certificates for other purposes (i.e. the IGTF)
Le Fri, May 24, 2013 at 12:32:29PM +0200, Dennis van Dok a écrit : I've seen the Debconf '12 discussion on X.509 certificate stores[1] and the Wiki page that came out of that discussion[2]. 1. http://www.irill.org/videos/debconf-12/895_X.509_Cert_Store_Discussion.mp4 2. http://wiki.debian.org/X.509 As far as I'm aware there aren't many mentions of [2] in the public mailing lists, but I'm very interested to discuss where this is going. My main interest is the use case for certificates from the science grid community. The IGTF[3] has a distribution of accredited CAs that are used world-wide to authenticate both services and users. These are typically not the kind of CAs you'd trust for on-line banking, but services like: - compute clusters - grid storage pools - science clouds - science workflow portals - etc. Hi Dennis and everybody, somewhat related to this, I would like to know if there is a package that could host Amazon's EC2 public certificate ? In Ubuntu it is added to the euca2ools package, because a program of this package can use it, but it is not part of the upstream source (which is not Amazon), so I really would prefer to ship the certificate somewhere else. I proposed ca-certificates earlier, but the result was inconclusive. http://bugs.debian.org/573857 Would there be a volunteer to maintain new package from scratch if needed ? Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130525122708.ga29...@falafel.plessy.net
X.509 and CA certificates for other purposes (i.e. the IGTF)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I've seen the Debconf '12 discussion on X.509 certificate stores[1] and the Wiki page that came out of that discussion[2]. 1. http://www.irill.org/videos/debconf-12/895_X.509_Cert_Store_Discussion.mp4 2. http://wiki.debian.org/X.509 As far as I'm aware there aren't many mentions of [2] in the public mailing lists, but I'm very interested to discuss where this is going. My main interest is the use case for certificates from the science grid community. The IGTF[3] has a distribution of accredited CAs that are used world-wide to authenticate both services and users. These are typically not the kind of CAs you'd trust for on-line banking, but services like: - compute clusters - grid storage pools - science clouds - science workflow portals - etc. 3. http://www.igtf.net The point I'd like to raise is that the current model of CA certificates seems to take an all-or-nothing approach: either a CA is trusted (for whatever purpose) or not. For the IGTF CAs, this may not be the right approach. When I started packaging the IGTF distribution for Debian[4], there was some discussion about what the right way of doing this would be. In the light of new(er) ideas raised in[2], it seems more thought and discussion is still needed. I'm offering to help out, either by contributing to the discussion, providing tooling, testing, etc. Thanks, Dennis van Dok - -- D.H. van Dok :: Software Engineer :: www.nikhef.nl/grid :: Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJRn0G3AAoJEN/62Bl2F+8ZOdEQALj/b5f7p18mDD0pJ811qt52 BzuMa7rMT4+6guES3JVZrtyTf5YSu5xUZsrU/PeD6SUew9yIvaSFQIGLj3qZ4psf dq3FEoXDkneag/FV8Sl/MkOOAZh4JH+06p+9L9OQackfn7IRGONQLnbL/jKhkikL Gi1tfN5V2+AlqqDabuJ7mopddndCj1x+WuyvnAs8DEcqrlNDZMB2BCdMS+i3IzfO 1gCtoyctxYbI2tHeq6Hwtmy7RhHqQFJd2ZyNM1/ThSPjKuOgW8SMaT/TH4c5PteD L5PVfvaH31hcZY8l9cniYRaYHnmkuNhoHq0TfOPYmHhuBiIxd4Q0riTAjpOyjQNe yJ7/YUlVruRNnMc9i9iU/gIYWODvtroy8IddBRr+cj1Q75juPl9GIvaVPEYhlQEk okFm7B5+TQcda1aObcUV3mKlrP9rvVqZJPTL9yy/QQaPyw3M/UZz+7cgGTYHSJlt 50s46mNn+PZrtVvIAJyJOTInvcKui7MdPCoeIAPLjpBa9XzwUpHHDSOsQxi6sV3f 4L0XhB1XharMDV7vnHJqgREnqefIMo8ZiWKVq5MEMszs8KZ3OS1TE7SyOIgN8HbS GR4YapIFRaYE3xqVnP/jNLH00TPM3UX5q4+Z1Z8wP9vlxNl3pNwZvLoElz9HdJBz U3eQ5CxYZGwjBUbIVoqO =kqzN -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/519f41bd.10...@nikhef.nl
Re: X.509 and CA certificates for other purposes (i.e. the IGTF)
On Fri, May 24, 2013 at 12:32:29PM +0200, Dennis van Dok wrote: The point I'd like to raise is that the current model of CA certificates seems to take an all-or-nothing approach: either a CA is trusted (for whatever purpose) or not. For the IGTF CAs, this may not be the right approach. One of the things I would like to see is that trust settings are part of a systemwide store. This means that you can say you trust a CA for clients, servers, email, codesigning, ... Certificated in ca-certificates mostly come from mozilla, and they already have such trust settings. However they're lost when imported in ca-certificates, so applications ussing the certificates from ca-certificates can't check that. Openssl can add such trust settings (see x509(1ssl), section TRUST SETTINGS). However it changes the format of the PEM file, and gcrypt can't read this. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130524171833.ga14...@roeckx.be
Re: X.509 and CA certificates for other purposes (i.e. the IGTF)
On 24-05-13 19:18, Kurt Roeckx wrote: On Fri, May 24, 2013 at 12:32:29PM +0200, Dennis van Dok wrote: The point I'd like to raise is that the current model of CA certificates seems to take an all-or-nothing approach: either a CA is trusted (for whatever purpose) or not. For the IGTF CAs, this may not be the right approach. One of the things I would like to see is that trust settings are part of a systemwide store. This means that you can say you trust a CA for clients, servers, email, codesigning, ... This sounds like the model used by libnss, e.g. on Fedora. Certificated in ca-certificates mostly come from mozilla, and they already have such trust settings. However they're lost when imported in ca-certificates, so applications ussing the certificates from ca-certificates can't check that. (I would be interested to have an overview of what the trust settings for Mozilla are; if there are any rejected uses in Mozilla, those should certainly translate to ca-certificates as well. Of course there is also X509v3 Key Usage.) I'm not sure if these trust settings will suffice with respect to the IGTF certificates. The point is that an IGTF CA is typically trusted for servers in the science grid domain, but not for servers in other application domains. (The same the other way around.) The current practice is that these certificates are installed in /etc/grid-security/certificates, but this is generally regarded as a kludge. Openssl can add such trust settings (see x509(1ssl), section TRUST SETTINGS). However it changes the format of the PEM file, and gcrypt can't read this. Is this because it is an experimental feature of OpenSSL, or because of a missing feature in gcrypt? Dennis -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/519fe826.2010...@nikhef.nl
Re: X.509 and CA certificates for other purposes (i.e. the IGTF)
On Fri, 2013-05-24 at 12:32 +0200, Dennis van Dok wrote: The point I'd like to raise is that the current model of CA certificates seems to take an all-or-nothing approach: either a CA is trusted (for whatever purpose) or not. For the IGTF CAs, this may not be the right approach. I don't think that's a good idea for ca-certificates either,... but I don't think you can really do anything against it... either the cert is installed in /etc/ssl or not... the problem here lies actually with the clients, when they don't allow you to specify another store location to have more fine grained possibilities... Sure there is what Kurt mentions... but I mean that doesn't make things really better IMHO, as it only allows to set a few roles,... not something like ejabberd should accept this, but apache should not, or does it? but I think it's very problematic that ca-certificates includes extremely untrustworthy CAs like CNNIC... Anyway... good to see you again into bringing the IGTF bundle to Debian :) Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
