Shared System Certificates followup: Packaging Guidelines?

Tue Jan 14 13:36:48 UTC 2014

-----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 at redhat.com> 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.