RE: TAA definition

[Black_David@xxxxxxx]

Henry,

> > This gets back to the issue I cited earlier, and reiterated several

> > times. Each TAA has to have an ability to associate some scope with

> > it. This scope may have to be imposed on TAs installed "under" each

> > TAA. That way one can use static analysis of TAAs to determine  
> > whether there are overlaps that might cause problems. The same is  
> > true for TAs, if one has a "flatter" TA management arrangement.
> 
> Fully agree.

Could you provide a motivating example for which assigning each
TAA scope to a separate trust store is not a good solution?
Steve's example didn't do it for me, as I think it only requires
4 trust stores, one of which does some extra certificate checks.

To explain where I'm coming from - my default hypothesis (I'm
definitely prepared to be proved wrong) is that most of the
scope, policy, etc. features can be handled via certificates,
possibly cert extensions of some form.  I'd prefer to deal with
this area in that fashion, even to the point of having the TSA
that is used to authorize the TAA include a certificate with
whatever extensions are needed to get the job done.  If
existing certificate technology can be reused, we don't have
to reinvent it, simplifying things for all concerned.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@xxxxxxx        Mobile: +1 (978) 394-7754
----------------------------------------------------