Shared System Certificates followup: Packaging Guidelines?

[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-----