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