Shared System Certificates followup: Packaging Guidelines?

[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/certs/policy/
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