https://fedoraproject.org/wiki/FedoraCryptoConsolidation
While I understand the reasons for this idea of Consolidation I have a concern that very valid use cases are being ignored or unknown. As an example I have a use case supported with curl and OpenSSL like this:
curl --cacert truststore.pem --cert example.com.pem:test https://example.com
This is where I have a private truststore that I don't want shared with any other applications and client certificate that I don't want to install for usage by any other application. With curl and stunnel for example, how is this use case supported with NSS? The paradigm of having certs in db form is fine for shared resources but not appropriate for resources that are never intended to be shared. curl with OpenSSL uses a file paradigm, defaulting to /usr/local/share/certs/ca-root-nss.crt in the nominal case and whatever you specify in the explicit case. If there is something similar that allows you to create a non-shared "file" in berkeley db format and a non-shared instance of a client certificate in some format that could work. However given that use case is already supported with OpenSSL curl and stunnel, I'm skeptical of all the work to port NSS which was never designed for these use cases.
Another problem I see is the case where the global certificates are no longer valid for whatever reason. These decisions can be made by the OS (CRL's), the user/admin OR the application(s). With the NSS, the application seems left out of the decision making process. In many cases the user/admin cannot be relied upon for proper management and the OS's notions of what is valid and the application's notion are different. This situation coalesces to my first use case but I could see it being a more general case of certificate management.
r
On 2013-05-07, 04:10 GMT, Richard Levenberg wrote:
https://fedoraproject.org/wiki/FedoraCryptoConsolidation
While I understand the reasons for this idea of Consolidation I have a concern that very valid use cases are being ignored or unknown. As an example I have a use case supported with curl and OpenSSL like this:
I wouldn't be much worried about that project. See the date of that page and state of the (non-)consolidation in the current Fedora.
Matěj
On Tue, 7 May 2013, Matej Cepl wrote:
Subject: Re: Concern about FedoraCryptoConsolidation
On 2013-05-07, 04:10 GMT, Richard Levenberg wrote:
https://fedoraproject.org/wiki/FedoraCryptoConsolidation
While I understand the reasons for this idea of Consolidation I have a concern that very valid use cases are being ignored or unknown. As an example I have a use case supported with curl and OpenSSL like this:
I wouldn't be much worried about that project. See the date of that page and state of the (non-)consolidation in the current Fedora.
We should be worried. The proliferance of basement crypto is a real problem.
If you want your package to get into RHEL, you will need to ensure your package has no home grown crypto, and uses either nss, openssl or libgcrypt. This will also allow FIPS mode to work.
Also note that some things listed in the above url are actively worked on, eg:
http://fedoraproject.org/wiki/Features/SharedSystemCertificates
It would be great if we had the resources to start making an inventory of the problem, let alone the resources to resolve these.
Instead, we seem to be seeing an increase in new library use, such as nacl and botan.
Look at how many bugs there have been found in openssl and nss. And those packages have seen many many eye balls, both acedemic and commercial.
Paul
On Tue, 2013-05-07 at 11:16 -0400, Paul Wouters wrote:
On Tue, 7 May 2013, Matej Cepl wrote:
Subject: Re: Concern about FedoraCryptoConsolidation
On 2013-05-07, 04:10 GMT, Richard Levenberg wrote:
https://fedoraproject.org/wiki/FedoraCryptoConsolidation
While I understand the reasons for this idea of Consolidation I have a concern that very valid use cases are being ignored or unknown. As an example I have a use case supported with curl and OpenSSL like this:
I wouldn't be much worried about that project. See the date of that page and state of the (non-)consolidation in the current Fedora.
We should be worried. The proliferance of basement crypto is a real problem.
If you want your package to get into RHEL, you will need to ensure your package has no home grown crypto, and uses either nss, openssl or libgcrypt.
Or gnutls (but not nettle directly!).
On Tue, May 07, 2013 at 05:24:29PM +0200, Tomas Mraz wrote:
On Tue, 2013-05-07 at 11:16 -0400, Paul Wouters wrote:
On Tue, 7 May 2013, Matej Cepl wrote:
Subject: Re: Concern about FedoraCryptoConsolidation
On 2013-05-07, 04:10 GMT, Richard Levenberg wrote:
https://fedoraproject.org/wiki/FedoraCryptoConsolidation
While I understand the reasons for this idea of Consolidation I have a concern that very valid use cases are being ignored or unknown. As an example I have a use case supported with curl and OpenSSL like this:
I wouldn't be much worried about that project. See the date of that page and state of the (non-)consolidation in the current Fedora.
We should be worried. The proliferance of basement crypto is a real problem.
If you want your package to get into RHEL, you will need to ensure your package has no home grown crypto, and uses either nss, openssl or libgcrypt.
Or gnutls (but not nettle directly!).
Could the FedoraCryptoConsolidation page be updated with these additional packages? Some upstreams are resistant to a specific package and some others have reduced functionality when used with a specific package. Knowing which choices are favoured over other-random-library-with-active-upstream could help to persuade upstreams to switch to one of the favoured libraries.
-Toshio
On 2013-05-07, 15:16 GMT, Paul Wouters wrote:
I wouldn't be much worried about that project. See the date of that page and state of the (non-)consolidation in the current Fedora.
We should be worried. The proliferance of basement crypto is a real problem.
I haven't said or meant that the state of crypto (non-)consolidation in Fedora is not pitiful. It is. I was just (sadly and bit ironically) commenting on the original worry about the consequences of this program. There are (almost) none.
Matěj
Richard Levenberg wrote:
https://fedoraproject.org/wiki/FedoraCryptoConsolidation
While I understand the reasons for this idea of Consolidation I have a concern that very valid use cases are being ignored or unknown. As an example I have a use case supported with curl and OpenSSL like this:
curl --cacert truststore.pem --cert example.com.pem:test https://example.com
This is where I have a private truststore that I don't want shared with any other applications and client certificate that I don't want to install for usage by any other application. With curl and stunnel for example, how is this use case supported with NSS? The paradigm of having certs in db form is fine for shared resources but not appropriate for resources that are never intended to be shared. curl with OpenSSL uses a file paradigm, defaulting to /usr/local/share/certs/ca-root-nss.crt in the nominal case and whatever you specify in the explicit case. If there is something similar that allows you to create a non-shared "file" in berkeley db format and a non-shared instance of a client certificate in some format that could work. However given that use case is already supported with OpenSSL curl and stunnel, I'm skeptical of all the work to port NSS which was never designed for these use cases.
NSS has a PKCS#11 module that can load PEM certificates, so it should work the same way as with OpenSSL. You shouldn't have to change your cli at all. If you do it's a bug.
Another problem I see is the case where the global certificates are no longer valid for whatever reason. These decisions can be made by the OS (CRL's), the user/admin OR the application(s). With the NSS, the application seems left out of the decision making process. In many cases the user/admin cannot be relied upon for proper management and the OS's notions of what is valid and the application's notion are different. This situation coalesces to my first use case but I could see it being a more general case of certificate management.
This is a long-standing problem only tangentially related to Crypto Consolidation. http://fedoraproject.org/wiki/Features/SharedSystemCertificates should help address this somewhat, but it doesn't address per-app CRL or OCSP enforcement.
rob
-
Matej Cepl -
Paul Wouters -
Richard Levenberg -
Rob Crittenden -
Tomas Mraz -
Toshio Kuratomi