Shared System Certificates followup: Packaging Guidelines?

[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 at gmail.com> 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-----