[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Does the problem need solving?

At 2:35 PM -0700 6/21/07, Jon Callas wrote:
On Jun 21, 2007, at 2:16 PM, Paul Hoffman wrote:

At 11:29 AM -0700 6/21/07, Jon Callas wrote:
I think I can infer it -- that browsers and other software that have to supply some set of roots do so ad hoc.

I would say it differently: that applications that *need* some set of roots get those roots ad hoc.

I'm reminded of an old joke -- a woman walks into a restaurant in Boston of over a century ago and sees some matrons with amazing hats. She asks one matron, "What a lovely hat! Where did you get it?" The matron sniffed disapprovingly and said, "We didn't *get* our hats, we *have* our hats." In other words, I hear you on need versus have, but is there a difference?

as someone living on Boston, but not owning any hats that merit such attention, I still believe in the need to be accurate in the words we use in this discussion.

Acquiring sets of roots is only ad-hoc if you think of them that way. Internet Explorer gets its from Microsoft, Mozilla gets its roots from its anchors from its makers, and so on. My software has a set of roots, which it gets from me. Why shouldn't it get its roots from me?

In the case of the browsers, enterprise IT administrative staff often want the ability to change the default set of TAs supplied by the browsers, and there is no standard (nor easy) way to do that, short of becoming a surrogate distribution point for the browser software. So, in general, there are situations in which it is appropriate for other than the software vendor to be the supplier of TAs for use by that software.

There's no unified mechanism to specify what the collected set of roots is.

There's no unified mechanism to get a collection of roots from a trusted source.

So am I correct in thinking that this is in some way making a root-of-all-roots?

maybe, if what you mean is a TA that can be used to manage the import of and control the scope of other TAs, and if the single TA may be either locally managed or managed by the supplier of a device.

Let me phrase it another way: if I receive a Trust Anchor object containing a set of roots, how do I know it's trustworthy? How do I know that that replacement root for a given CA really came from them?

this is only part of the problem.

It seems to me that there's an easy answer -- the makers of software bake a Trust Anchor object into their software, and if you need new Trust Anchors you import additional Trust Anchors into a Trust Anchor database.

that would not be sufficient, because it assumes that I never want to replace the TA supplied by the SW vendor, only augment it.

I have many more questions, but they presuppose I understand this.

Before that, the question on the subject line still remains a good one, along with "what problem are we actually solving?"

As a maker of software that supplies roots, will this make my life easier?

viable solutions should make life easier for two classes of folks: those who want to locally manage TAs and those who supply HW (and maybe SW) and want to maintain control over some TAs, but cede some of that control to local TA managers.

It sounds to me like I'm ceding authority to some unspecified party. Would that party be IANA?

not even close.

Alternatively, let's suppose I want to become a CA. Will this make my life easier getting my root into a number of places?

I don't know about your example, but if I am a CA for an enterprise and I want to install a TA in a set of machines in that enterprise, the solution should enable that.