RE: Multiple TAAs

[Black_David@xxxxxxx]

Russ,

> At 12:11 PM 8/17/2007, Black_David@xxxxxxx wrote:
> >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.
>
> I think we need to think about the degree of delegation that we want 
> to permit.  I can imagine an enterprise permitting a contracted 
> service to provide some support here.  However, the one thing that 
> the do not want the contracted service to do is remove the enterprise 
> from the picture.  That would prevent the enterprise from changing
> providers.

I definitely agree that we need to think about delegation - IMHO,
delegation is second only to policy in its ability to introduce
complexities, subtleties and the concomitant opportunity for
implementation and user mistakes that cause security issues in
practice.

> So, I can imagine the enterprise holding an all-powerful TA, and 
> using this to add and delete TA administration privileges for the 
> trust anchor stores in the devices and software packages that are 
> used in the enterprise.  The TA administration privilege must not
> be sufficient to become the all-powerful TA.

All of the TAs in the above paragraph are the anchors for the trust
stores which in turn contain trust anchors for use by applications.

For clarity, let's use the term Trust Store Anchor (TSA) to refer
to an anchor that confers the ability to manage application trust
anchors in a trust store, and use the term Application Trust Anchors
(ATAs) if/as necessary for clarity.

Using this terminology, the scenario that Russ is concerned about
boils down to controlling which TSAs can manage the TSAs for a trust
store.  Both TSAs can manage all the application TAs, as the enterprise
presumably trusts the contracted service to correctly manage the
enterprise-specific ATAs (and if the enterprise doesn't, I strongly
suggest that it should resort to the "send all your updates through
me" solution described for Microsoft updates in earlier messages).

I think it would be fine for every TSA entry in a trust store to have
a boolean property indicating whether it can manage the TSAs for the
trust store, as long as all the TSAs for a trust store can manage
all of the application trust anchors in that trust store.

Given all of this, Russ's issue is then how the enterprise retains
control over its trust stores (e.g., so it can switch to another
trust anchor management service provider without the existing provider's
cooperation).  With the "can manage TSAs" boolean property, the solution
is reasonably straightforward - each trust store has two Trust Store
Anchors:
	- The (all-powerful) enterprise TSA with its "can manage TSAs"
		property set to True.
	- The contracted service TSA with its "can manage TSAs"
		property set to False.
Both TSAs can manage all the application trust anchors in the trust
store, and if a (contractual) conflict arises, the enterprise TSA is
used to delete the contracted service TSA and clean up whatever mess
it left behind.

One more item.  Russ wrote:

> I see no reason for there to me more than one all-powerful TA as
> long as the all-powerful TA can be used to make updates to the
> all-powerful TA, say when two enterprises merge.

The reason may be dealing with private key compromise in a tractable
fashion - if an all-powerful TA needs to be revoked (e.g., via a CRL),
it would be more than convenient to have another one to use.  Two
should be enough.

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
----------------------------------------------------