On Mi, 2014-01-08 at 12:32 -0500, Stephen Gallagher wrote: > 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) You are listing yet another scenario that I hadn't considered in my previous message. As I understand it, in your scenario, you intend to dynamically create a new CA at installation time. That CA wouldn't be controlled by someone else, because the packager wouldn't have access to the key that gets generated at install time. You're argueing it shouldn't be a problem to make that locally generated CA trusted for all applications on the system, as nobody else controls it. One could think of tricks to abuse that ability. For example, someone could make a package that implements a dynamic MITM capability, by installing a local proxy that uses the locally trusted CA, which can dynamically generate appropriate server certificates for any site a user wants to visit, and by installing a (localhost) proxy configuration into browser's network configuration, thereby enabling the package to incercept all outgoing connection TLS connections without getting noticed. True, when granting permission to install a package on a system, you're granting that package full control over your computer anyway. However, maybe such a MITM functionality might be difficult to detect, and allowing global CA installation would make such tricks possible. Of course, I'm constructing a hypothetical worst case scenario for brainstorming purposes. I don't know if it's realistic that a clever MITM tool, which only activates itself based on certain condition, that hides inside a game package, would be noticed during package review. In order to find a compromise between the extreme positions "find a solution" and "be careful", maybe it should be a requirement that locally generated CA certificates must contain a domain name constraint extension, that limits for which sites it is valid. Kai -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
