On Monday 23 February 2015 18:55:34 Richard Barnes wrote: > On Mon, Feb 23, 2015 at 5:28 PM, Matt Palmer <mpal...@hezmatt.org> wrote: > > On Mon, Feb 23, 2015 at 02:14:13PM -0800, Clint Wilson wrote: > > > Lots of Enterprises and organizations have very legitimate requirements > > > > to > > > > > add their own internal root CA to the NSS store. > > > > I suspect John's point is that lots of enterprises and organisations (I > > remember a time when those were the same thing...) have very legitimate > > requirements to add their own internal add-ons to Firefox, and he is > > simply > > calling out an apparent inconsistency in Mozilla's policies on these two > > object types. (John, if I'm misrepresenting your position, please feel > > free > > to correct me). > > If I understand correctly (dveditz CC'ed to correct me), the current add-on > signing tool has a provision for signing add-ons that are not published > through AMO. They still need to be submitted to AMO to be scanned and > signed, but they're not published. > > > However, the two situations aren't the same, and thus can't be compared so > > simplistically. Mozilla's signature on an add-on says, "we're reasonably > > sure this add-on isn't going to do Bad Things to your browser", because > > they > > can wave automated scanning tools over the code to look for dodgy stuff. > > > > The closest thing I can think of for CA certificates would be if Mozilla > > OK'd only technically-constrained CA certs -- say, only for domains and IP > > ranges which the applicant was known to own. However, that is exactly the > > sort of thing that existing trusted root CAs do. I suspect that existing > > trusted root CAs would be unhappy if Mozilla took on this task. It would > > also be a significant cost to Mozilla, because determining authority to > > issue certs for an entire portion of the DNS space is a lot more manual > > effort than running a code analysis tool over an add-on. > > I think the benefit here would be more transparency than quality. If we > only allowed changes to the root store by signed add-ons, then (1) Mozilla > would at least have internal visibility into all the MitM roots being > deployed, and (2) we could use the add-on blacklist facility to block > things like Superfish once they were detected. These both seem beneficial > in terms of mitigating risk due to MitM. > > However, it could be challenging to implement this control. In addition to > the in-browser UI for adding roots (which could easily be disabled), certs > can also be added to the NSS databases directly, even while the browser > isn't active. To counter this risk, we would have to periodically snapshot > the database and check that nothing else had changed it. I'm not sure the > incremental benefit merits the level of development required. Nonetheless, > if we can reinforce the idea that addons are the way to install roots by > simply turning off the UI that exists, that could be beneficial. > > (Also, this is more of a Firefox discussion than a CA program discussion, > so it might be more appropriate for dev.tech.crypto.)
This is doubly problematic, as some people may want to preserve roots that were removed (see the recent removals of 1024 bit roots)... It's a big can of worms no matter how you approach it. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
