Frank Hecker wrote: > Ian G wrote: >> The goals of Mozo are written somewhere else, and they only speak >> softly to the issue of security from memory. I think it is worth >> revisiting them, perhaps someone has them to hand? > > Are you referring to the high-level goals of the Mozilla Foundation (not > necessarily security-related)? The goals at the highest level are > expressed traditionally by the mission statement "promote choice and > innovation on the Internet". More recently we have the Mozilla Manifesto > as an expanded statement of principles and goals: > > http://www.mozilla.org/about/manifesto > > Note that the Manifesto does address security-related concerns in a > couple of places, most notably principles 4 and 8.
Yes, that's what I was thinking of (I think): 4. Individuals' security on the Internet is fundamental and cannot be treated as optional. 8. Transparent community-based processes promote participation, accountability, and trust. > Going down a level, to my knowledge we (still) don't have a single > authoritative document that addresses the topic of overall security > goals for Firefox or other Mozilla products. However Johnathan > Nightingale has blogged a lot on this topic, and I suspect one could put > together such a document based on what Johnathan and others have written. > > Turning to the question of CAs specifically, the most complete (and > unofficial) take on the question is probably my CA certificate > "meta-policy" document: > > http://hecker.org/mozilla/ca-certificate-metapolicy > > (Though note that I haven't read it in detail for quite a while, and > it's possible that my thinking may have changed in at least one or two > areas.) Hmm, worth a read, yes. >> I would interpolate the policy goals from the following snippets: >> >> "based on the benefits and risks of such inclusion >> to typical users of those product" >> >> "would cause undue risks to users' security" >> >> "might cause technical problems with the operation >> of our software" >> >> "provide some service relevant to typical users of >> our software products;" >> >> These speak to higher level goals. > > That language in the policy was probably my adaption of points 5 and 6 > in the CA certificate metapolicy. My main thinking at the time revolved > around the idea of treating PKI and inclusion of CA certs in the context > of overall product security, with trade-offs made as appropriate to > balance risks and benefits to typical users. I don't find fault in it today. > If I were to rewrite the metapolicy today, I'd probably explore two > additional points: > > * treating the EV case differently than the non-EV case > * not having a "one size fits all" policy for CAs, but looking at CAs in > context, at least to some extent > > (To expand on the latter point, what I mean by "in context" includes > things like whether the CA is government-operated vs. private sector, > which geographic and vertical markets it serves, what its market share > is, etc.) Yes, I agree with those two, together :) Meta-Pt 7 agrees, 8 counters. >> If anything, Frank seems to be implying a goal of "reasonable >> efficiency" but that seems to not need to be stated. If anything, >> he's talking about the efficiency of the tools that meet the higher >> level goals (whatever they are), not the higher level goals. > > I'm not sure what you mean by "reasonable efficiency" in this context. Took a bit of untangling to work it out myself. The context is the suggestion: > Our goal here is to avoid having to evaluate lots and lots of > subordinate CAs, and instead have the roots take care of their > own subordinates and ensure they're compliant to policy. Eddy may have made a claim that this didn't match the goals of Mozilla, to which I responded that an implied goal here is one of being more productive, and that is not normally stated in a missions discussion. Having seen the schedule for CAs, I think we can all appreciate that the workload is too high. Getting the CAs to control their sub-CAs will be a big load off of Mozilla's team, and, assuming it works, increases the number of CAs available and therefore the number of certificates. So, in the end, assuming quality is maintained somehow, the project of "roots look after sub-CAs" meets Mozilla's security leanings, if only by simple productivity improvements. Or something? iang
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
