Shared System Certificates followup: Packaging Guidelines?

[Toshio Kuratomi]

Last night someone asked me about a package that they were working on that
had a pem file in it.  Looking closer, it seems that the pem file is
a cacert bundle.  Looking around, there's not currently documentation on
what to do with these.  I did find some information on the wiki, though:

  https://fedoraproject.org/wiki/PackagingDrafts/Certificates
  https://fedoraproject.org/wiki/Features/SharedSystemCertificates
  https://fedoraproject.org/wiki/Talk:Features/SharedSystemCertificates

I'm by no means an expert in this area but my impression is that the
PackagingDraft is made obsolete by the Shared System Certificates Feature.
As Killerix and Misc note on the talk page we should probably have some
packaging guidelines added that tell us what the expectations are.

The Guideline should answer the following questions:

* Should packages that ship their own cacerts be patched to use Shared
  System Certificates instead?  [I think the answer to this is yes]
* If the package contains a cacert that is not in our bundle, should those
  be added?
* How does a package add a cacert to our existing bundle?

Is there anyone available to write a draft for this and submit it to the
FPC (and answer questions that come up)?

-Toshio

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/11/2013 12:59 PM, Toshio Kuratomi wrote:


  * Should we allow packages to ship automatically trusted certificates?

We need to be cognizant of the potential risk inherent in allowing
packagers to drop new trusted CA certificates onto the system. It's
worth considering whether such things should require an approval process.



> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlKoqWcACgkQeiVVYja6o6OV4QCgo8tNx+JPvfuGUlx68CDI8iZZ
> hk0An3BfXv38IRNOlrYXBpv9usNZuVTa
> =m/HR
> -----END PGP SIGNATURE-----

[Miloslav Trmač]

On Wed, Dec 11, 2013 at 6:59 PM, Toshio Kuratomi <a.badger(a)gmail.com&gt; wrote:
>  I'm by no means an expert in this area but my impression is that
> the
>  PackagingDraft is made obsolete by the Shared System Certificates Feature. 
Shared
system certificates are unrelated to application-specific
certificates and private keys, and to some extent even to
application-specific (or specifically-per-application-configured) CA
certificates.

>  * Should packages that ship their own cacerts be patched to use
> Shared
>    System Certificates instead?  [I think the answer to this is yes]
>  * If the package contains a cacert that is not in our bundle, should those
>    be added?
>  * How does a package add a cacert to our existing bundle? 
The preference I've heard earlier is to use ca-certificates as the
only authority (and ca-certificates using the Mozilla CA set without
making similar decisions at the Fedora level, because we don't have
any resources to do CA vetting), and disallow other packages from
shipping and installing any other system-wide CA certificate.

I suppose setting up some kind of site-wide mechanism like freeipa
could also install a CA certificate, but it would be a generated
certificate not shipped by a package, and it would have to be an
explicit administrator's action.

This makes sense to me; if there are cases that this can't account
for, please speak up.
     Mirek

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/11/2013 01:07 PM, Miloslav Trmač wrote:
>  On Wed, Dec 11, 2013 at 6:59 PM, Toshio Kuratomi
>  <a.badger(a)gmail.com&gt; wrote:
> > I'm by no means an expert in this area but my impression is that
> > the PackagingDraft is made obsolete by the Shared System
> > Certificates Feature.
>  Shared system certificates are unrelated to application-specific 
>  certificates and private keys, and to some extent even to 
>  application-specific (or specifically-per-application-configured)
>  CA certificates.
>  
> > * Should packages that ship their own cacerts be patched to use
> > Shared System Certificates instead?  [I think the answer to this
> > is yes] * If the package contains a cacert that is not in our
> > bundle, should those be added? * How does a package add a cacert
> > to our existing bundle?
>  
>  The preference I've heard earlier is to use ca-certificates as the 
>  only authority (and ca-certificates using the Mozilla CA set
>  without making similar decisions at the Fedora level, because we
>  don't have any resources to do CA vetting), and disallow other
>  packages from shipping and installing any other system-wide CA
>  certificate.
>  
>  I suppose setting up some kind of site-wide mechanism like freeipa 
>  could also install a CA certificate, but it would be a generated 
>  certificate not shipped by a package, and it would have to be an 
>  explicit administrator's action.
>  
>  This makes sense to me; if there are cases that this can't account 
>  for, please speak up. 

Well, a (hacky) pattern that I am using for OpenPegasus to support
OpenLMI is this:

1) Create a private key file and an x509v3 CA certificate with CA:TRUE
2) Create a new private key and signing request for the service ticket
for Pegasus with a lifetime of 10 years.
3) Sign the service certificate with the CA certificate.
4) *Delete the private key file for the CA certificate*
5) Put the public CA certificate into the trusted store


While this is technically adding a CA certificate into the system-wide
store, by deleting the private key file, it removes the risk that the
key could subsequently be used by anyone else. Granted, there's a
small race condition during the signing process where the key could be
stolen by root on the box doing the installation, but that's probably
negligible risk.

(For the record, the benefit this brings is that users can use tools
like YAWN or pyWBEM against localhost without having to ignore the
certificate validation).
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlKoqvAACgkQeiVVYja6o6PCqACeL2RJI8q2ICGkaq4AUK/V4fi+
> Vk8AniZprSeZ7NRSTs+uWfp2PHBtfS3X
> =Av3l
> -----END PGP SIGNATURE-----

[Christopher Meng]

Can be also extended for Mono snk key file stored in /etc/pki.

We should also let packagers to use the system shipped key file instead of
using the bundled anymore.

[Fred New]

On Wed, Dec 11, 2013 at 8:07 PM, Miloslav Trmač <mitr(a)volny.cz&gt; wrote:
>  On Wed, Dec 11, 2013 at 6:59 PM, Toshio Kuratomi
> <a.badger(a)gmail.com&gt; wrote:
> > * Should packages that ship their own cacerts be patched to use Shared
> >   System Certificates instead?  [I think the answer to this is yes]
> > * If the package contains a cacert that is not in our bundle, should those
> >   be added?
> > * How does a package add a cacert to our existing bundle?
>
>  The preference I've heard earlier is to use ca-certificates as the
>  only authority (and ca-certificates using the Mozilla CA set without
>  making similar decisions at the Fedora level, because we don't have
>  any resources to do CA vetting), and disallow other packages from
>  shipping and installing any other system-wide CA certificate.
>
>  I suppose setting up some kind of site-wide mechanism like freeipa
>  could also install a CA certificate, but it would be a generated
>  certificate not shipped by a package, and it would have to be an
>  explicit administrator's action.
>
>  This makes sense to me; if there are cases that this can't account
>  for, please speak up. 
I have a package that puts certificates into /usr/share/(esteid/certs/). It
isn't part of Fedora yet, but I've been hoping get it accepted into the
Fedora repository and replacing current Fedora (Google Code)
packages for working with Estonian ID (smart) cards. My package,
esteidcerts, is provided by the Estonian Certification Centre, the CA
for Estonia. I'm open to suggestions regarding how I should handle
these certificates. The Centre has told me that the Google Code
packages have known vulnerabilities, and this is why I have an
interest in replacing them.

More details

Latest Estonian Certification Centre source:
https://installer.id.ee/media/sources/

RPMs for F17 (the Centre is no longer building RPMs for Fedora):
https://installer.id.ee/media/fedora/17/RPMS/

Google Code packages include
esteid-browser-plugin, libdigidoc, libdigidocpp,
mozilla-esteid, smartcardpp

Fred

[Kai Engert]

On Mi, 2013-12-11 at 09:59 -0800, Toshio Kuratomi wrote: 
>  Last night someone asked me about a package that they were working on
> that
>  had a pem file in it.  Looking closer, it seems that the pem file is
>  a cacert bundle.  Looking around, there's not currently documentation on
>  what to do with these.  I did find some information on the wiki, though:
>  
>    https://fedoraproject.org/wiki/PackagingDrafts/Certificates
>    https://fedoraproject.org/wiki/Features/SharedSystemCertificates
>    https://fedoraproject.org/wiki/Talk:Features/SharedSystemCertificates
>  
>  I'm by no means an expert in this area but my impression is that the
>  PackagingDraft is made obsolete by the Shared System Certificates Feature.
>  As Killerix and Misc note on the talk page we should probably have some
>  packaging guidelines added that tell us what the expectations are.
>  
>  The Guideline should answer the following questions:
>  
>  * Should packages that ship their own cacerts be patched to use Shared
>    System Certificates instead?  [I think the answer to this is yes] 
Packages, that would like to use a default list of CA certificates,
should be changed to use (consume) the new consolidated data that we
provide as part of SharedSystemCertificates.

Fedora packages that need to trust additional, application specific
CA(s) should install them into a different, applicaton specific
location, and implement loading of those additional trust anchors in
their application code.

Fedora packages other than the ca-certificates.rpm shouldn't install
into the global trusted locations (unless the Fedora decision makes
decide otherwise). The reason is, installating additional CAs has the
side effect that all other applications on the system will trust that
CA, too. (For example, if a game application requires a CA to connect to
a game network, that CA shouldn't be trusted for certifying the
identities of web sites when surfing using Firefox etc. For that, we
want only CAs that have been vetted according to the rules of the
Mozilla CA Certificate Policy).

Besides Fedora packages, there might be deployment specific packages. If
a closed user group, for example the members of an organization, would
like to trust a CA operated by that organization, and make it easy to
add that CA for the members, the organization could create a package
that places an additional CA certificate (or bundle file) into our
global locations. Such an RPM package shouldn't qualify for inclusion in
Fedora's standard repositories, but it should be made available for
download from a separate location.

Another category might be community operated CAs, like the one operated
by http://cacert.org which hasn't been able yet to fulfil the
requirements for inclusion in the Mozilla CA list (but which has some
popularity in the free software and free information world). Someone
could make an RPM package that installs their root certificate into
Fedora's global trust location. I personally would argue, such packages
shouldn't be included in Fedora's repositories either, as another
package could easily pull it in with an dependency, and users might
install it without noticing the impact of installing it.

>  * If the package contains a cacert that is not in our bundle, should
> those
>    be added? 
We shouldn't do that. If any CA would like to get included as a globally
trusted third party, it should follow the rules outlined at
http://www.mozilla.org/en-US/about/governance/policies/security-group/cer...
and we'd eventually include them as part of the regular updates to that
list maintained by Mozilla.


>  * How does a package add a cacert to our existing bundle? 
If it's a global Fedora package, it shouldn't.

If it's a non-Fedora package, outside of Fedora's repositories,
targetted for a closed user group, where people deliberately choose to
trust those CAs, the package can install additional files into
the /etc/pki/ca-trust/ or /usr/share/pki/ca-trust-source/ as explained
in the manual page that you get with
$ man update-ca-trust

Regards
Kai

[Adam Williamson]

On Wed, 2014-01-08 at 18:05 +0100, Kai Engert wrote:
>  On Mi, 2013-12-11 at 09:59 -0800, Toshio Kuratomi wrote: 
>  > Last night someone asked me about a package that they were working on that
>  > had a pem file in it.  Looking closer, it seems that the pem file is
>  > a cacert bundle.  Looking around, there's not currently documentation on
>  > what to do with these.  I did find some information on the wiki, though:
>  > 
>  >   https://fedoraproject.org/wiki/PackagingDrafts/Certificates
>  >   https://fedoraproject.org/wiki/Features/SharedSystemCertificates
>  >   https://fedoraproject.org/wiki/Talk:Features/SharedSystemCertificates
>  > 
>  > I'm by no means an expert in this area but my impression is that the
>  > PackagingDraft is made obsolete by the Shared System Certificates Feature.
>  > As Killerix and Misc note on the talk page we should probably have some
>  > packaging guidelines added that tell us what the expectations are.
>  > 
>  > The Guideline should answer the following questions:
>  > 
>  > * Should packages that ship their own cacerts be patched to use Shared
>  >   System Certificates instead?  [I think the answer to this is yes]
>  
>  Packages, that would like to use a default list of CA certificates,
>  should be changed to use (consume) the new consolidated data that we
>  provide as part of SharedSystemCertificates. 
This could do with some specifics:

[adamw@adam libtorrent (master)]$ rpm -ql ca-certificates | grep -c -e
'pem' -e 'crt'
11
[adamw@adam libtorrent (master)]$ 

which one of those 11 files, exactly, should we have packages use when?
When I came up against this situation recently I threw a dart and
picked /etc/pki/tls/certs/ca-bundle.crt , but I'm hardly certain.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Kai Engert]

On Mi, 2014-01-08 at 09:16 -0800, Adam Williamson wrote: 
>  > Packages, that would like to use a default list of CA
> certificates,
>  > should be changed to use (consume) the new consolidated data that we
>  > provide as part of SharedSystemCertificates.
>  
>  This could do with some specifics:
>  
>  [adamw@adam libtorrent (master)]$ rpm -ql ca-certificates | grep -c -e
>  'pem' -e 'crt'
>  11
>  [adamw@adam libtorrent (master)]$ 
>  
>  which one of those 11 files, exactly, should we have packages use when?
>  When I came up against this situation recently I threw a dart and
>  picked /etc/pki/tls/certs/ca-bundle.crt , but I'm hardly certain. 
The manual page explains which files are intended for which purpose, and
also mentions the availability of a smarter pkcs#11 module for
applications that are able to use it.

$ rpm -ql ca-certificates |grep -w man
/usr/share/man/man8/update-ca-trust.8.gz
$ man update-ca-trust

Kai

[Adam Williamson]

On Wed, 2014-01-08 at 18:56 +0100, Kai Engert wrote:
>  On Mi, 2014-01-08 at 09:16 -0800, Adam Williamson wrote: 
>  > > Packages, that would like to use a default list of CA certificates,
>  > > should be changed to use (consume) the new consolidated data that we
>  > > provide as part of SharedSystemCertificates.
>  > 
>  > This could do with some specifics:
>  > 
>  > [adamw@adam libtorrent (master)]$ rpm -ql ca-certificates | grep -c -e
>  > 'pem' -e 'crt'
>  > 11
>  > [adamw@adam libtorrent (master)]$ 
>  > 
>  > which one of those 11 files, exactly, should we have packages use when?
>  > When I came up against this situation recently I threw a dart and
>  > picked /etc/pki/tls/certs/ca-bundle.crt , but I'm hardly certain.
>  
>  The manual page explains which files are intended for which purpose, and
>  also mentions the availability of a smarter pkcs#11 module for
>  applications that are able to use it.
>  
>  $ rpm -ql ca-certificates |grep -w man
>  /usr/share/man/man8/update-ca-trust.8.gz
>  $ man update-ca-trust 
Thanks. It would probably be useful to have a guidelines section about
this, as it wasn't at all obvious.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Kai Engert]

On Mi, 2014-01-08 at 10:03 -0800, Adam Williamson wrote: 
>  > > which one of those 11 files, exactly, should we have
> packages use when?
>  > > When I came up against this situation recently I threw a dart and
>  > > picked /etc/pki/tls/certs/ca-bundle.crt , but I'm hardly certain.
>  > 
>  > The manual page explains which files are intended for which purpose, and
>  > also mentions the availability of a smarter pkcs#11 module for
>  > applications that are able to use it.
>  > 
>  > $ rpm -ql ca-certificates |grep -w man
>  > /usr/share/man/man8/update-ca-trust.8.gz
>  > $ man update-ca-trust
>  
>  Thanks. It would probably be useful to have a guidelines section about
>  this, as it wasn't at all obvious. 
Are you suggesting a guidelines section in the manual page, or somewhere
else?

[Adam Williamson]

On Wed, 2014-01-08 at 21:05 +0100, Kai Engert wrote:
>  On Mi, 2014-01-08 at 10:03 -0800, Adam Williamson wrote: 
>  > > > which one of those 11 files, exactly, should we have packages use when?
>  > > > When I came up against this situation recently I threw a dart and
>  > > > picked /etc/pki/tls/certs/ca-bundle.crt , but I'm hardly certain.
>  > > 
>  > > The manual page explains which files are intended for which purpose, and
>  > > also mentions the availability of a smarter pkcs#11 module for
>  > > applications that are able to use it.
>  > > 
>  > > $ rpm -ql ca-certificates |grep -w man
>  > > /usr/share/man/man8/update-ca-trust.8.gz
>  > > $ man update-ca-trust
>  > 
>  > Thanks. It would probably be useful to have a guidelines section about
>  > this, as it wasn't at all obvious.
>  
>  Are you suggesting a guidelines section in the manual page, or somewhere
>  else? 
In the Fedora packaging guidelines (and perhaps package review
guidelines too), a section explaining what to do with packages that
bundle CA certs.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/08/2014 12:05 PM, Kai Engert wrote:
>  On Mi, 2013-12-11 at 09:59 -0800, Toshio Kuratomi wrote:
> > Last night someone asked me about a package that they were
> > working on that had a pem file in it.  Looking closer, it seems
> > that the pem file is a cacert bundle.  Looking around, there's
> > not currently documentation on what to do with these.  I did find
> > some information on the wiki, though:
> > 
> > https://fedoraproject.org/wiki/PackagingDrafts/Certificates 
> > https://fedoraproject.org/wiki/Features/SharedSystemCertificates 
> > https://fedoraproject.org/wiki/Talk:Features/SharedSystemCertificates
> >
> >
> >  
I'm by no means an expert in this area but my impression is that the
> > PackagingDraft is made obsolete by the Shared System
> Certificates
> > Feature. As Killerix and Misc note on the talk page we should
> > probably have some packaging guidelines added that tell us what
> > the expectations are.
> > 
> > The Guideline should answer the following questions:
> > 
> > * Should packages that ship their own cacerts be patched to use
> > Shared System Certificates instead?  [I think the answer to this
> > is yes]
>  
>  Packages, that would like to use a default list of CA
>  certificates, should be changed to use (consume) the new
>  consolidated data that we provide as part of
>  SharedSystemCertificates.
>  
>  Fedora packages that need to trust additional, application
>  specific CA(s) should install them into a different, applicaton
>  specific location, and implement loading of those additional trust
>  anchors in their application code.
>  
>  Fedora packages other than the ca-certificates.rpm shouldn't
>  install into the global trusted locations (unless the Fedora
>  decision makes decide otherwise). The reason is, installating
>  additional CAs has the side effect that all other applications on
>  the system will trust that CA, too. (For example, if a game
>  application requires a CA to connect to a game network, that CA
>  shouldn't be trusted for certifying the identities of web sites
>  when surfing using Firefox etc. For that, we want only CAs that
>  have been vetted according to the rules of the Mozilla CA
>  Certificate Policy).
>   

Probably this needs to go to FESCo/FPC, but what about
package-specific CAs? For example, I have a pattern I was thinking
about adding to the tog-pegasus that causes it to do the following:

1. Create an x509v3 certificate and key with the CA extension
2. Create a new service certificate for tog-pegasus locally
3. Sign it with the CA certificate.
4. Store the public CA certificate in the system's trust store.
5. Destroy the private key so that it cannot be used to sign other
certificates.


(The effect here being that a user on the local system can connect to
an SSL socket on localhost without being challenged or having to
ignore the verification)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlLNi7cACgkQeiVVYja6o6ONEQCgqbx04Ws+HaFHJ6PDZfv+c6ea
> tv4AoKW8RfCOCWGI01n88kb0KwjhRaJh
> =37EY
> -----END PGP SIGNATURE-----

[Kai Engert]

On Mi, 2014-01-08 at 12:32 -0500, Stephen Gallagher wrote: 
>  but what about
>  package-specific CAs? For example, I have a pattern I was thinking
>  about adding to the tog-pegasus that causes it to do the following:
>  
>  1. Create an x509v3 certificate and key with the CA extension
>  2. Create a new service certificate for tog-pegasus locally
>  3. Sign it with the CA certificate.
>  4. Store the public CA certificate in the system's trust store.
>  5. Destroy the private key so that it cannot be used to sign other
>  certificates.
>  
>  (The effect here being that a user on the local system can connect to
>  an SSL socket on localhost without being challenged or having to
>  ignore the verification) 
You are listing yet another scenario that I hadn't considered in my
previous message.

As I understand it, in your scenario, you intend to dynamically create a
new CA at installation time. That CA wouldn't be controlled by someone
else, because the packager wouldn't have access to the key that gets
generated at install time.

You're argueing it shouldn't be a problem to make that locally generated
CA trusted for all applications on the system, as nobody else controls
it.

One could think of tricks to abuse that ability.

For example, someone could make a package that implements a dynamic MITM
capability, by installing a local proxy that uses the locally trusted
CA, which can dynamically generate appropriate server certificates for
any site a user wants to visit, and by installing a (localhost) proxy
configuration into browser's network configuration, thereby enabling the
package to incercept all outgoing connection TLS connections without
getting noticed.

True, when granting permission to install a package on a system, you're
granting that package full control over your computer anyway. However,
maybe such a MITM functionality might be difficult to detect, and
allowing global CA installation would make such tricks possible.

Of course, I'm constructing a hypothetical worst case scenario for
brainstorming purposes. I don't know if it's realistic that a clever
MITM tool, which only activates itself based on certain condition, that
hides inside a game package, would be noticed during package review.

In order to find a compromise between the extreme positions "find a
solution" and "be careful", maybe it should be a requirement that
locally generated CA certificates must contain a domain name constraint
extension, that limits for which sites it is valid.

Kai

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/08/2014 12:54 PM, Kai Engert wrote:
>  On Mi, 2014-01-08 at 12:32 -0500, Stephen Gallagher wrote:
> > but what about package-specific CAs? For example, I have a
> > pattern I was thinking about adding to the tog-pegasus that
> > causes it to do the following:
> > 
> > 1. Create an x509v3 certificate and key with the CA extension 2.
> > Create a new service certificate for tog-pegasus locally 3. Sign
> > it with the CA certificate. 4. Store the public CA certificate in
> > the system's trust store. 5. Destroy the private key so that it
> > cannot be used to sign other certificates.
> > 
> > (The effect here being that a user on the local system can
> > connect to an SSL socket on localhost without being challenged or
> > having to ignore the verification)
>  
>  You are listing yet another scenario that I hadn't considered in
>  my previous message.
>  
>  As I understand it, in your scenario, you intend to dynamically
>  create a new CA at installation time. That CA wouldn't be
>  controlled by someone else, because the packager wouldn't have
>  access to the key that gets generated at install time.
>  
>  You're argueing it shouldn't be a problem to make that locally
>  generated CA trusted for all applications on the system, as nobody
>  else controls it.
>  
>  One could think of tricks to abuse that ability.
>  
>  For example, someone could make a package that implements a dynamic
>  MITM capability, by installing a local proxy that uses the locally
>  trusted CA, which can dynamically generate appropriate server
>  certificates for any site a user wants to visit, and by installing
>  a (localhost) proxy configuration into browser's network
>  configuration, thereby enabling the package to incercept all
>  outgoing connection TLS connections without getting noticed.
>  
>  True, when granting permission to install a package on a system,
>  you're granting that package full control over your computer
>  anyway. However, maybe such a MITM functionality might be difficult
>  to detect, and allowing global CA installation would make such
>  tricks possible.
>  
>  Of course, I'm constructing a hypothetical worst case scenario for 
>  brainstorming purposes. I don't know if it's realistic that a
>  clever MITM tool, which only activates itself based on certain
>  condition, that hides inside a game package, would be noticed
>  during package review.
>  
>  In order to find a compromise between the extreme positions "find
>  a solution" and "be careful", maybe it should be a requirement
>  that locally generated CA certificates must contain a domain name
>  constraint extension, that limits for which sites it is valid. 
I don't really see this being more likely than an existing application
just bundling a wrapper script for certificate generation and
'update-ca-extract' and quietly running that as part of %post. Just as
easy to miss and equally effective (with much less trouble).

I don't think that we can really write policy that eliminates the risk
of a determined abuse of the available technology.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlLNmzgACgkQeiVVYja6o6MgeQCeKjtocZ//P0ATt17fM/3OMq4R
> qZwAn3n9qUcOboZcwwUSYlgxtopv2KEA
> =+yxY
> -----END PGP SIGNATURE-----

[Kai Engert]

On Mi, 2014-01-08 at 13:38 -0500, Stephen Gallagher wrote: 
>  I don't really see this being more likely than an existing
> application
>  just bundling a wrapper script for certificate generation and
>  'update-ca-extract' and quietly running that as part of %post. Just as
>  easy to miss and equally effective (with much less trouble). 
true

>  I don't think that we can really write policy that eliminates the
> risk
>  of a determined abuse of the available technology. 
Probably. What do you think about adding a section to package reviewing
guidelines, which says that packages that add files to the global CA
directories should provide reasoning, and have someone check that
reasoning. It might at least make people aware this is something to be
careful with.

Kai

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/08/2014 02:57 PM, Kai Engert wrote:
>  On Mi, 2014-01-08 at 13:38 -0500, Stephen Gallagher wrote:
> > I don't really see this being more likely than an existing
> > application just bundling a wrapper script for certificate
> > generation and 'update-ca-extract' and quietly running that as
> > part of %post. Just as easy to miss and equally effective (with
> > much less trouble).
>  
>  true
>  
> > I don't think that we can really write policy that eliminates the
> > risk of a determined abuse of the available technology.
>  
>  Probably. What do you think about adding a section to package
>  reviewing guidelines, which says that packages that add files to
>  the global CA directories should provide reasoning, and have
>  someone check that reasoning. It might at least make people aware
>  this is something to be careful with.
>   
That seems perfectly reasonable to me.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlLNrsEACgkQeiVVYja6o6MNFwCgnEsvPTGHq7sP4/X6egK5ezRm
> o+4AoK56OXwUSWVnExN6E6aBJf/krG2m
> =bPGB
> -----END PGP SIGNATURE-----

[Miloslav Trmač]

On Wed, Jan 8, 2014 at 6:32 PM, Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  Probably this needs to go to FESCo/FPC, but what about
>  package-specific CAs? For example, I have a pattern I was thinking
>  about adding to the tog-pegasus that causes it to do the following:
>
>  1. Create an x509v3 certificate and key with the CA extension
>  2. Create a new service certificate for tog-pegasus locally
>  3. Sign it with the CA certificate.
>  4. Store the public CA certificate in the system's trust store.
>  5. Destroy the private key so that it cannot be used to sign other
>  certificates.
>
>  (The effect here being that a user on the local system can connect to
>  an SSL socket on localhost without being challenged or having to
>  ignore the verification) 
In general, I probably wouldn't want the FPC guidelines to be
specifically describing such a complicated scenario, they would have
to be insanely long.

Personal opinion on the above scheme:
0. AFAICS it's generally secure and I can't find a strong reason to
prohibit it.  That said:
1. It is unverifiable that the private key has been destroyed; an
attacker could regenerate a CA and the tog-pegasus key, and then
continue the use the CA private key to sign MITM certificates, and
there would be nothing "out of the ordinary" in the systems' CA
configuration.
2. This only solves the SSL configuration for clients running on the
same host, not for connecting from another host.  Wouldn't it be more
general to allow the pegasus client to add pegasus-client-specific
roots of trust (either CAs, ideally with name constraints, or
individual self-signed certificates)?  Then it would make sense to
install a system-wide configuration for the pegasus client on the
local host that accepts the server's certificate from the same host.
     Mirek

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/13/2014 12:50 PM, Miloslav Trmač wrote:
>  On Wed, Jan 8, 2014 at 6:32 PM, Stephen Gallagher
>  <sgallagh(a)redhat.com&gt; wrote:
> > Probably this needs to go to FESCo/FPC, but what about 
> > package-specific CAs? For example, I have a pattern I was
> > thinking about adding to the tog-pegasus that causes it to do the
> > following:
> > 
> > 1. Create an x509v3 certificate and key with the CA extension 2.
> > Create a new service certificate for tog-pegasus locally 3. Sign
> > it with the CA certificate. 4. Store the public CA certificate in
> > the system's trust store. 5. Destroy the private key so that it
> > cannot be used to sign other certificates.
> > 
> > (The effect here being that a user on the local system can
> > connect to an SSL socket on localhost without being challenged or
> > having to ignore the verification)
>  
>  In general, I probably wouldn't want the FPC guidelines to be 
>  specifically describing such a complicated scenario, they would
>  have to be insanely long.
>  
>  Personal opinion on the above scheme: 0. AFAICS it's generally
>  secure and I can't find a strong reason to prohibit it.  That
>  said: 1. It is unverifiable that the private key has been
>  destroyed; an attacker could regenerate a CA and the tog-pegasus
>  key, and then continue the use the CA private key to sign MITM
>  certificates, and there would be nothing "out of the ordinary" in
>  the systems' CA configuration. 
How exactly would they regenerate the key? Even if we assume that the
key is not destroyed, it was still only ever readable by root, which
implies that the attacker already has sufficient privilege to do
whatever he wants, including dropping a new trusted CA into the system.

>  2. This only solves the SSL configuration for clients running on
>  the same host, not for connecting from another host.  Wouldn't it
>  be more 
Yes, this is just a bootstrapping mechanism to make it easier for
people who just want to try out OpenLMI on their machine. It is
certainly not a recommended practice for production (as self-signed
certificates should *never* be). And that's really all this is; a
special case of a self-signed certificate that doesn't need to be run
with --noverify if you're on the local system.

>  general to allow the pegasus client to add pegasus-client-specific 
>  roots of trust (either CAs, ideally with name constraints, or 
>  individual self-signed certificates)?  Then it would make sense to 
>  install a system-wide configuration for the pegasus client on the 
>  local host that accepts the server's certificate from the same
>  host. 
The recommended solution here is for systems to enroll in a domain
(ideally FreeIPA, but Active Directory is also supported) in which
case the public certificate for the domain would be loaded into the
trust store and used for Pegasus.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlLVPXAACgkQeiVVYja6o6N9/QCeP8sQzE/oEOTwHYEsedN993k3
> WfsAn2tVwL+SiniTvPjMBZiLDJielD9D
> =PTR9
> -----END PGP SIGNATURE-----

[Miloslav Trmač]

On Tue, Jan 14, 2014 at 2:36 PM, Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  On 01/13/2014 12:50 PM, Miloslav Trmač wrote:
> > On Wed, Jan 8, 2014 at 6:32 PM, Stephen Gallagher
> > <sgallagh(a)redhat.com&gt; wrote:
> >> Probably this needs to go to FESCo/FPC, but what about
> >> package-specific CAs? For example, I have a pattern I was
> >> thinking about adding to the tog-pegasus that causes it to do the
> >> following:
> >>
> >> 1. Create an x509v3 certificate and key with the CA extension 2.
> >> Create a new service certificate for tog-pegasus locally 3. Sign
> >> it with the CA certificate. 4. Store the public CA certificate in
> >> the system's trust store. 5. Destroy the private key so that it
> >> cannot be used to sign other certificates.
> >>
> >> (The effect here being that a user on the local system can
> >> connect to an SSL socket on localhost without being challenged or
> >> having to ignore the verification)
> >
> > In general, I probably wouldn't want the FPC guidelines to be
> > specifically describing such a complicated scenario, they would
> > have to be insanely long.
> >
> > Personal opinion on the above scheme: 0. AFAICS it's generally
> > secure and I can't find a strong reason to prohibit it.  That
> > said: 1. It is unverifiable that the private key has been
> > destroyed; an attacker could regenerate a CA and the tog-pegasus
> > key, and then continue the use the CA private key to sign MITM
> > certificates, and there would be nothing "out of the ordinary" in
> > the systems' CA configuration.
>
>  How exactly would they regenerate the key? Even if we assume that the
>  key is not destroyed, it was still only ever readable by root, which
>  implies that the attacker already has sufficient privilege to do
>  whatever he wants, including dropping a new trusted CA into the system. 
Yes, this story was assuming root access by the attacker[1].  The only
interesting aspect is that it this attack is undetectable: if you take
a pristine image of a VM and a subverted image, you can't tell the
difference.
    Mirek

[1] http://article.gmane.org/gmane.comp.encryption.general/16128 , my fault.