RE: Multiple TAAs

[Black_David@xxxxxxx]

Carl,
 
> Why limit the arrangement such that the contracted service can manage
everything?

Why not?  In particular, I see profound contractual difficulties if the
enterprise
can't trust the contracted service to manage all the trust anchors - if
it's not
trusted for that, what else is it not trusted for, and how are we going
to express
that?

> It doesn't seem like much of a stretch to use constraints similar to
those we've
> discussed for application TAs, i.e., name constraints or usage
constraints.
 
The proverbial road to <bleep> (complexity) is paved with exactly these
sorts of
good intentions (e.g., "nice to have" features).  The moment TSAs have
to be
configured with name and usage constraints, the administrative problems
of managing
trust anchor management have gone up significantly (the trust anchors
are already
hard enough to manage - we should strive to avoid making that problem
significantly
worse).  I'm interested in "must have" arguments, but my response to
"nice to have"
arguments about features for managing trust anchor management is going
to be to
complain (whine if necessary) about administrative complexity - i.e., if
in doubt,
leave it out.  I have use cases in mind in which this is used by
non-security-
experts (i.e., people trying to accomplish something else) to centralize
trust
anchor management - I don't want this "cure" to be worse than the
"disease".
 
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
----------------------------------------------------

________________________________

	From: Carl Wallace [mailto:CWallace@xxxxxxxxxxxx] 
	Sent: Saturday, August 18, 2007 2:36 PM
	To: housley@xxxxxxxxxxxx; Black, David
	Cc: ietf-trust-anchor@xxxxxxxx
	Subject: RE: Multiple TAAs
	
	

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

	Requiring separate trust stores to accommodate multiple trust
anchor managers with different privileges is one approach, but it might
not be the easiest to manage.  Depending on how it is supported, routine
rekey may be one example for allowing multiple TAAs with different
privileges.  For example, a TA that is authoritative for namespace X
could generate a management message that could be used to add its new
key to a trust store and remove its old key.  Assuming the trust store
has multiple TAs for different namespaces, there would be multiple TAAs
with different privileges.

	<snip> 
	> > 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). 

	Why limit the arrangement such that the contracted service can
manage everything?  It doesn't seem like much of a stretch to use
constraints similar to those we've discussed for application TAs, i.e.,
name constraints or usage constraints.

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

	This suggests we need to be able to represent: a pair all
powerful TSAs, if for no other reason than recovery from compromise or
loss; one or more(?) less-powerful TSAs; and a set of ATAs.