I want to expand on something I said at the microphone in Chicago - I think the easiest (and likely to be the most common) solution to multiple TAAs that don't have the same management privileges is separate trust anchor stores and that an operational model of all TAAs for a trust anchor store having the same management privileges is the easiest to cope with. I think any use case that postulates different TAAs with different privileges for the *same* trust anchor store needs to have a strong justification for the difference in privileges. Let me start by applying this to Yoav's enterprise browser example:
> >I think what's typical for an Enterprise depends on the application. > >If we're talking about browsers, then I think it's perfectly > >acceptable to have two TAAs - one from the browser vendor (it > >shouldn't be my employer's task to tell me that Verisign has a new > >root CA certificate - that's Microsoft's job) and the other being > >the corporate IT department. That's why I think each TAA should be > >able to manage its own (and only its own) trust anchors. > > Even in this case I can see problems, I think several folks have > noted that the default TAs currently installed in browsers ought to > be subject to local management, especially deletion! So, as a browser > user in an enterprise context, I would not want a TAA installed by MS > (or, in my case, Apple) to be able to maintain the presence of TAs > even if my IT dept wants to remove them. I agree with Steve, and my employer behaves in exactly this way with respect to *all* MS updates, not just browser trust anchors - all of MS's automatic updates flow through a server maintained by the corporate IT folks, hence there's only one TAA. I do not see the need for multiple TAAs with different privileges - either the IT folks trust MS to do whatever MS wants to (both TAAs have the same privileges) or they don't (MS updates redirected through IT, IT is the only TAA). > >In your consumer space example, I again don't think SalesForce.com > >should be able to delete bankofamerica.com's trust anchor. Perhaps > >there should be exception, such as if Microsoft learns that the > >bankofamerica.com TA really belongs to a phishing company, but I > >think each TAA should manage its own as a general rule, and this > >should be enforced. If SalesForce.com needs to manage browser trust anchors, then it needs its own trust anchor store (perhaps even its own copy of the browser) on the end user's system, and then SalesForce.com can do whatever it wants with those anchors. I suspect SalesForce.com is unlikely to want to do this, and probably has limited in managing trust anchors of its customers/users, as it's very easy to break things this way. One specific point is that trust anchor changes don't strike me as a good way to deal with phishing - encouraging or forcing an updated CRL into the browser before allowing site access is likely to be considerably more effective. My preference is that managing different privileges for multiple TAAs administering the same trust anchor store ought to be out of scope, unless someone has a compelling use case with which to argue otherwise. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED] Mobile: +1 (978) 394-7754 ----------------------------------------------------
