[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
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
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
So am I correct in thinking that this is in some way making a
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
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.