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