-----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@xxxxxxxxxx> 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----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
